Erik Trimble wrote:
That is, start out with adding the ability to differentiate between access policy in a vdev. Generally, we're talking only about mirror vdevs right now. Later on, we can consider the ability to migrate data based on performance, but a lot of this has to take into consideration snapshot capability and such, so is a bit less straightforward.
The policy is implemented on the read side, since you still need to commit writes to all mirrors. The implementation shouldn't be difficult, deciding on the administrative interface will be the hardest part.
Oh, and the newest thing in the consumer market is called "hybrid drives", which is a melding of a Flash drive with a Winchester drive. It's originally targetted at the laptop market - think a 1GB flash memory welded to a 40GB 2.5" hard drive in the same form-factor. You don't replace the DRAM cache on the HD - it's still there for fast-write response. But all the "frequently used" blocks get scheduled to be placed on the Flash part of the drive, while the mechanical part actually holds a copy of everything. The Flash portion is there for power efficiency as well as performance.
Flash is (can be) a bit more sophisticated. The problem is that they have a limited write endurance -- typically spec'ed at 100k writes to any single bit. The good flash drives use block relocation, spares, and write spreading to avoid write hot spots. For many file systems, the place to worry is the block(s) containing your metadata. ZFS inherently spreads and mirrors its metadata, so it should be more appropriate for flash devices than FAT or UFS. Similarly, the disk drive manufacturers make extensive use of block sparing, so applying that technique to the hybrid drives is expected. -- richard _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
