Re: [zfs-discuss] ZFS questions
On 6/17/06, Dale Ghent <[EMAIL PROTECTED]> wrote: The concept of shifting blocks in a zpool around in the background as part of a scrubbing process and/or on the order of a explicit command to populate newly added devices seems like it could be right up ZFS's alley. Perhaps it could also be done with volume-level granularity. Off the top of my head, an area where this would be useful is performance management - e.g. relieving load on a particular FC interconnect or an overburdened RAID array controller/cache thus allowing total no-downtime-to-cp-data-around flexibility when one is horizontally scaling storage performance. Another good use would be to migrate blocks that are rarely accessed to slow storage (750 GB drives with RAID-Z) while very active blocks are kept on fast storage (solid state disk). Presumably writes would go to relatively fast storage and use idle IO cycles to migrate those that don't have "a lot" of reads to slower storage. Blocks that are very active and reside on slow storage could be migrated (mirrored?) to fast storage. Presumably fast storage vs. slow storage is based upon measurement of performance, leading to automatic balancing across the disks. Mike -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS questions
Mike Gerdts wrote: On 6/17/06, Dale Ghent <[EMAIL PROTECTED]> wrote: The concept of shifting blocks in a zpool around in the background as part of a scrubbing process and/or on the order of a explicit command to populate newly added devices seems like it could be right up ZFS's alley. Perhaps it could also be done with volume-level granularity. Off the top of my head, an area where this would be useful is performance management - e.g. relieving load on a particular FC interconnect or an overburdened RAID array controller/cache thus allowing total no-downtime-to-cp-data-around flexibility when one is horizontally scaling storage performance. Another good use would be to migrate blocks that are rarely accessed to slow storage (750 GB drives with RAID-Z) while very active blocks are kept on fast storage (solid state disk). Presumably writes would go to relatively fast storage and use idle IO cycles to migrate those that don't have "a lot" of reads to slower storage. Blocks that are very active and reside on slow storage could be migrated (mirrored?) to fast storage. Solid state disk often has a higher failure rate than normal disk and a limited write cycle. Hence it is often desirable to try and redesign the filesystem to do fewer writes when it is on (for example) compact flash, so moving "hot blocks" to fast storage can have consequences. But then there is also this new storage paradigm in the e-rags where a hard drive also has some amount of solid state storage to speed up the boot time. It'll be interesting to see how that plays out, but I suspect the idea is that in the relevant market (PCs), it'll be used for things like drivers and OS core image files that do not change very often. Darren ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS questions
Darren Reed wrote: Solid state disk often has a higher failure rate than normal disk and a limited write cycle. Hence it is often desirable to try and redesign the filesystem to do fewer writes when it is on (for example) compact flash, so moving "hot blocks" to fast storage can have consequences. Solid state storage does not necessarily mean flash. For example, I have recently performed some testing of Sun's Directory Server in conjunction with solid state disks from two different vendors. Both of these used standard DRAM, so there's no real limit to the number of writes that can be performed. They have lots of internal redundancy features (e.g., ECC memory with chipkill, redundant power supplies, internal UPSes, and internal hard drives to protect against extended power outages), but both vendors said that customers often use other forms of redundancy (e.g., mirror to traditional disk, or RAID across multiple solid-state devices). One of the vendors mentioned that both SVM and VxVM have the ability to designate one disk in a mirror as "write only" (unless the other has failed) which can be good for providing redundancy with cheaper, traditional storage. All reads would still come from the solid state storage so they would be very fast, and as long as the write rate doesn't exceed that of the traditional disk then there wouldn't be much adverse performance impact from the slower disk in the mirror. I don't believe that ZFS has this capability, but it could be something worth looking into. The original suggestion provided in this thread would potentially work well in that kind of setup. ZFS with compression can also provide a notable win because the compression can significantly reduce the amount of storage required, which can help cut down on the costs. Solid state disks like this are expensive (both of the 32GB disks that I tested list at around $60K), so controlling costs is important. Neil ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS questions
On 6/17/06, Neil A. Wilson <[EMAIL PROTECTED]> wrote: Darren Reed wrote: > Solid state disk often has a higher failure rate than normal disk and a > limited write cycle. Hence it is often desirable to try and redesign the > filesystem to do fewer writes when it is on (for example) compact flash, > so moving "hot blocks" to fast storage can have consequences. I mentioned solid state (assuming DRAM-based) and 750 GB drives as the two ends of the spectrum available. Most people will find their extremes that are each closer to the middle of the spectrum. Possibly a multi-tier approach including 73 GB FC, 300 GB FC, and 500 GB SATA would be more likely in most shops. Solid state disks like this are expensive (both of the 32GB disks that I tested list at around $60K), so controlling costs is important. If you remove "enterprise" from the solid state disk equation, consider this at $150 + the cost of 4 1 GB DDR DIMMs. I suppose you could mirror across a pair of them and still have a pretty fast small 4GB of space for less than $1k. http://www.anandtech.com/storage/showdoc.aspx?i=2480 FWIW, google gives plenty of hits for "solid state disk terabyte". Mike -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS questions
Saying "Solid State disk" in the storage arena means battery-backed DRAM (or, rarely, NVRAM). It does NOT include the various forms of solid-state memory (compact flash, SD, MMC, etc.);"Flash disk" is reserved for those kind of devices. This is historical, since Flash disk hasn't been functionally usable in the Enterprise Storage arena until the last year or so. Battery-backed DRAM as a "disk" has been around for a very long time, though. :-) We've all talked about adding the ability to change read/write policy on a pool's vdevs for awhile. There are a lot of good reasons that this is desirable. However, I'd like to try to separate this request from HSM, and not immediately muddy the waters by trying to lump too many things together. 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. And, on not a completely tangential side note: WTF is up with the costs for Solid State disks? I mean, prices well over $1k per GB are typical, which is absolutely ludicrous. The DRAM itself is under $100/GB, and these devices are idiot-simple to make. In the minimalist case, it's simply DIMM slots, a NiCad battery and trickle charger, and a SCSI/SATA/FC interface chip. Even in the fancy case, were you provide a backup drive to copy the DRAM contents to in case of power failure, it's a trivial engineering exercise. I realize there is (currently) a small demand for these devices, but honestly, I'm pretty sure that if they reduced the price by a factor of 3, they'd see 10x or maybe even 100x the volume, cause these little buggers are just so damned useful. 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. -Erik ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
