Hello Pol. On Thu, Jun 9, 2011 at 6:02 AM, Pol Hallen <raid2@xxxxxxxxxxxxxx> wrote: > > > What benchmark program did you use for the test? Also, was there any other > > programs running at the same time? Was the machine in single-user (init 1) > > state? > > hello :-) > > dd if=/dev/zero of=/share/raid6/1Gb bs=1024 count=1000000 > 1000000+0 records in > 1000000+0 records out > 1024000000 bytes (1.0 GB) copied, 12.1632 s, 84.2 MB/s > > dd if=/dev/zero of=/share/raid6/10Gb bs=1024 count=10000000 > 10000000+0 records in > 10000000+0 records out > 10240000000 bytes (10 GB) copied, 142.021 s, 72.1 MB/s The above dd's seem much more consistent than the graph. > That graphic with palimptest (gnome-disk-utility). I'm not familiar with this program (BTW, you mean "palimpsest", right?), and I've run it for the first time on my system (M4A785-M with Phenon-II X6 1055T, 4GB RAM, with 3 x ST31500541AS 1.5TB 3.5" 5900RPM HDs plugged directly onto the motherboard's SB700 SATA controller, running Ubuntu Lucid Lynx 10.04.1 LTS, kernel 2.6.32-32-generic; the 3 HDs are mounted as a RAID5 md device and dedicated to user data-only storage and mounted as /usr2, the root filesystem runs on a separate SSD disk). Here's my palimpsest graph: http://durval.com/felwithe_raid5_palimpsest_ro_20110609.jpg Note that it shows much less "jitter" (local variation) than your graph. > No other applications uses raid (I'm on init 2 but samba, ftp, and other > daemons are off) > > iostat not show me any activity by raid, so I think there is not programs that > runs on array. This is very strange... concurrent access by other programs would certainly explain the variation on your graph. I would try running some other benchmark that can be run on single-user state to see if the variation remains. If it does, then I would conclude that there's something wrong (possibly on your hardware, like a failing disk doing retries/reseeks). Cheers, -- Durval Menezes. > > thanks :-) > > Pol -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
