On 5-Dec-07, at 4:19 AM, can you guess? wrote: >>>> 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.
On the other hand, it's hard to argue for risk *increase* (using something else)... --Toby > > 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 _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
