> > > On 11/7/07, can you guess? > > [EMAIL PROTECTED] > > > wrote: > > However, ZFS is not the *only* open-source > approach > > which may allow that to happen, so the real > question > > becomes just how it compares with equally > inexpensive > > current and potential alternatives (and that would > > make for an interesting discussion that I'm not > sure > > I have time to initiate tonight). > > > > - bill > > Hi bill, only a question: > I'm an ex linux user migrated to solaris for zfs and > its checksumming;
So the question is: do you really need that feature (please quantify that need if you think you do), or do you just like it because it makes you feel all warm and safe? Warm and safe is definitely a nice feeling, of course, but out in the real world of corporate purchasing it's just one feature out of many 'nice to haves' - and not necessarily the most important. In particular, if the *actual* risk reduction turns out to be relatively minor, that nice 'feeling' doesn't carry all that much weight. you say there are other open-source > alternatives but, for a linux end user, I'm aware > only of Oracle btrfs > (http://oss.oracle.com/projects/btrfs/), who is a > Checksumming Copy on Write Filesystem not in a final > state. > > what *real* alternatives are you referring to??? As I said in the post to which you responded, I consider ZFS's ease of management to be more important (given that even in high-end installations storage management costs dwarf storage equipment costs) than its real but relatively marginal reliability edge, and that's the context in which I made my comment about alternatives (though even there if ZFS continues to require definition of mirror pairs and parity groups for redundancy that reduces its ease-of-management edge, as does its limitation to a single host system in terms of ease-of-scaling). Specifically, features like snapshots, disk scrubbing (to improve reliability by dramatically reducing the likelihood of encountering an unreadable sector during a RAID rebuild), and software RAID (to reduce hardware costs) have been available for some time in Linux and FreeBSD, and canned management aids would not be difficult to develop if they don't exist already. The dreaded 'write hole' in software RAID is a relatively minor exposure (since it only compromises data if a system crash or UPS failure - both rare events in an enterprise setting - sneaks in between a data write and the corresponding parity update and then, before the array has restored parity consistency in the background, a disk dies) - and that exposure can be reduced to seconds by a minuscule amount of NVRAM that remembers which writes were active (or to zero with somewhat more NVRAM to remember the updates themselves in an inexpensive hardware solution). The real question is usually what level of risk an enterprise storage user is willing to tolerate. At the paranoid end of the scale reside the users who will accept nothing less than z-series or Tandem-/Stratus-style end-to-end hardware checking from the processor traces on out - which rules out most environments that ZFS runs in (unless Sun's N-series telco products might fill the bill: I'm not very familiar with them). And once you get down into users of commodity processors, the risk level of using stable and robust file systems that lack ZFS's additional integrity checks is comparable to the risk inherent in the rest of the system (at least if the systems are carefully constructed, which should be a given in an enterprise setting) - so other open-source solutions are definitely in play there. All things being equal, of course users would opt for even marginally higher reliability - but all things are never equal. If using ZFS would require changing platforms or changing code, that's almost certainly a show-stopper for enterprise users. If using ZFS would compromise performance or require changes in management practices (e.g., to accommodate file-system-level quotas), those are at least significant impediments. In other words, ZFS has its pluses and minuses just as other open-source file systems do, and they *all* have the potential to start edging out expensive proprietary solutions in *some* applications (and in fact have already started to do so). When we move from 'current' to 'potential' alternatives, the scope for competition widens. Because it's certainly possible to create a file system that has all of ZFS's added reliability but runs faster, scales better, incorporates additional useful features, and is easier to manage. That discussion is the one that would take a lot of time to delve into adequately (and might be considered off topic for this forum - which is why I've tried to concentrate here on improvements that ZFS could actually incorporate without turning it upside down). - bill This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
