> > > > On 11/7/07, can you guess? > > > [EMAIL PROTECTED] > > > > wrote: > 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
my personal-professional data are important (this is my valuation, and it's an assumption you can't dispute). my data are only digital and rapidly changing, and than I cannot print them. I have budget constraints then I can use only user-level storage. until I discovered zfs I used subversion and git, but none of them is designed to manage gigabytes of data, some to be versioned, some to be unversioned. I can't afford silent data corruption and, if the final response is "*now* there is no *real* opensource software alternative to zfs automatic checksumming and simple snapshotting" I'll be an happy solaris user (for data storage), an happy linux user (for everyday work), and an unhappy offline windows user (for some video-related activity I can't do with linux). PS I think for every fully digital people own data are vital, and almost everyone would reply "NONE" at your question "what level of risk user is willing to tolerate". bye --- Stefano Spinucci This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
