[EMAIL PROTECTED] wrote: > >UNIX admin wrote: > >> > There's still an opening in the shared filesystem > >> > space (multi-reader > >> > and multi-writer). Fix QFS, or extend ZFS? > >> > >> That one's a no-brainer, innit? Extend ZFS and plough on. > > > >Uhm... I think this is not that easy. Based on IRC feedback I think it > >may be difficult to implement the intended features, e.g. storing inodes > >and data on sepeate disks. We had several projects in the past where > >this was the only way to gurantee good performace for realtime data > >collection and processing and due lack of such a feature in ZFS we still > >need QFS... > > I'm assuming this means you've measured the performance and found ZFS > wanting?
No, I didn not test ZFS yet, I only discussed the matter on IRC yet. But based on the original problems (see below) I do not think that ZFS can deliver something (without the inode+data seperation) what neither IBM nor QFS without inode+data split could not deliver a few years ago (even when backed with a giant RAID+caches (which caused more trouble than expected, see below, too)). > I don't get it; zfs is a copy-on-write filesystem, so there should > be no hotspotting of disks and, theoretically, write performance > could be maxed out. What about read performace ? And interactive users who are MAD and run their stuff during data capture ? > The requirement is not that inodes and data are separate; the requirement > is a specific upperbound to disk transactions. The question therefor > is not "when will ZFS be able to separate inods and data"; the question > is when ZFS will meet the QoS criteria. Uhm... that's the point where you are IMO slightly wrong. The exact requirement is that inodes and data need to be seperated. In this specific case (and the setup was copied several times so Sun made a considerable amount of money with it :-) ) the inode data+log were put on a seperate solid-state disks on seperate SCSI controllers (which have nearly zero seek time). The problem was that a high amount of inode activity could starve the data recoding and playback, something which was inacceptable since running the matching experiment just costs around >=40000Euro/Minute. Similar proposed setups provided by IBM failed (even with giant RAID caches (which mainly were able to flat the problems out, but sometimes suffered from second-long "hiccups" where read and writes were stalled)) to deliver the requested performance (much data and much inode traffic and tons of scripts and (to make it worse and even more unpredictable) interactive users). The only working solution in this case was to move inodes+log to the seperate solid-state disks with it's own path (e.g. SCSI controller) for these data, freeing the data RAID from such operations. The only alternative was to move everything to solid-state disks - but that was considered to be far to expensive (or better: we already wasted too much money elsewhere... ;-( ). ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) _______________________________________________ opensolaris-discuss mailing list [email protected]
