Ian Murdock wrote: > Shawn Walker wrote: > > However, initially the most sane appraoch is to pick one filesystem > > so that the initial effort can be focused on a great experience and > > take advantage of that filesystem's features. > > Agreed. This is all about keeping the focus tight. In terms of "bang for > the buck", we can't go far wrong with ZFS, since it's what the industry > is abuzz over, and we can do all kinds of neat things with it from an > end user point of view (as is currently being explored in this thread). > For other workloads we care about, such as HPC, other file systems > might make more sense.
It's not only about "HPC" and high-end scenarious. There are other examples like virtualised hardware (like VMware or XEN) where ZFS's checksumming eats lots of CPU cycles without any benefits since the underlying host OS may already do the same (for example in a typical VMware installation with 384MB ZFS drains so many resources (e.g. CPU and memory) that normal development work becomes painfull). IMO a two-way solution based on ZFS _and_ QFS from the beginning may be better than starting with a completely ZFS-only design which is then later "bend" to fit on QFS (small reminder: QFS delivers significantly more "bang for the buck" when you need performance/throughput per CPU cycle (if Sun marketing would be allowed to rename the product it may become something like "EcoFS" ... =:-) )) - that can only go wrong... ;-( ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) _______________________________________________ indiana-discuss mailing list [email protected] http://opensolaris.org/mailman/listinfo/indiana-discuss
