Robert Elz <[email protected]> wrote: > | Do you have recommendations for tuning the filesystem? > > Ideally the file system block size matches the raid stripe size, so > a block write doesn't require reading from the drive to complete the > data in the stripe - but whether that matters much depends upon just > how the raid is implemented. Certainly you don't want to split > blocks between multiple stripes, and you want the stripes to be > multiples of the drive hardware blocksize (not the blocksize exposed by > the drive for addressing purposes, but the one it actually uses).
Makes sense. Then I just have to find that information, besides a way to tune it. > | Not sure if 8 seconds is to be expected for such a RAID. > > It depends just how much data is in your /etc - use du and find out > how many blocks it occupies, and work out the actual write speed from > that. Mine is of the order of 16MB, 8 secs to write 16MB (2MBps) would > be quite slow. Yes. It's only 14MB on my freshly installed system. Did the same test on my old server with a software RAID partition, and umount takes just 1.3 seconds. Then I took the chance to compare hardware RAID with software RAID speed on my old server (which has an older HP Smart Array generation): the hardware RAID only seems a few percent faster than the software RAID for copying and syncing /etc. So, for some reason this is still faster than the new server. > Since you have the junk filesystem available temporarily > you could just do a dd of /dev/zero to the raw device I had already changed my disklabel again. So I disabled swap and wrote to /dev/rsd0b instead: # dd if=/dev/zero of=/dev/rsd0b bs=1m count=1024 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 17.348 secs (61894271 bytes/sec) This looks normal. So the problem is not in ciss(4)? -- Frank Wille
