On Fri, Dec 25, 2009 at 9:56 PM, Tim Cook <t...@cook.ms> wrote: > > > On Fri, Dec 25, 2009 at 11:43 PM, Brent Jones <br...@servuhome.net> wrote: >> >> >> >> >> >> > >> > >> > Hang on... if you've got 77 concurrent threads going, I don't see how >> > that's >> > a "sequential" I/O load. To the backend storage it's going to look like >> > the >> > equivalent of random I/O. I'd also be surprised to see 12 1TB disks >> > supporting 600MB/sec throughput and would be interested in hearing where >> > you >> > got those numbers from. >> > >> > Is your video capture doing 430MB or 430Mbit? >> > >> > -- >> > --Tim >> > >> > >> >> Think he said 430Mbit/sec, which if these are security cameras, would >> be a good sized installation (30+ cameras). >> We have a similar system, albeit running on Windows. Writing about >> 400Mbit/sec using just 6, 1TB SATA drives is entirely possible, and >> working quite well on our system without any frame loss or much >> latency. > > Once again, Mb or MB? They're two completely different numbers. As for > getting 400Mbit out of 6 SATA drive, that's not really impressive at all. > If you're saying you got 400MB, that's a different story entirely, and while > possible with sequential I/O and a proper raid setup, it isn't happening > with random. >
Mb, megabit. 400 megabit is not terribly high, a single SATA drive could write that 24/7 without a sweat. Which is why he is reporting his issue. Sequential or random, any modern system should be able to perform that task without causing disruption to other processes running on the system (if Windows can, Solaris/ZFS most definitely should be able to). I have similar workload on my X4540's, streaming backups from multiple systems at a time. These are very high end machines, dual quadcore opterons and 64GB RAM, 48x 1TB drives in 5-6 disk RAIDZ vdevs. The "write stalls" have been a significant problem since ZFS came out, and hasn't really been addressed in an acceptable fashion yet, though work has been done to improve it. I'm still trying to find the case number I have open with Sunsolve or whatever, it was for exactly this issue, and I believe the fix was to add dozens more "classes" to the scheduler, to allow more fair disk I/O and overall "niceness" on the system when ZFS commits a transaction group. -- Brent Jones br...@servuhome.net _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
