Re: NetBSD Raid5, slow write speeds, using big disks?!
smurfd <[email protected]> Tue, 30 Jun 2026 14:31:52 +0200
| Newsgroups | gmane.os.netbsd.general |
|---|---|
| Message-ID | <[email protected]> |
On 6/23/26 8:30 PM, Robert Elz wrote: > Date: Tue, 23 Jun 2026 16:03:42 +0200 > From: smurfd <[email protected]> > Message-ID: <[email protected]> > > | Its tiresome though, doing a change then waiting 8 to 72 hours and > | seeing that the change had no effect. > > While you're experimenting, make a much smaller raid array, one that is > just 10GB or so (ok, at least a couple of multiples of the amount of RAM > in the system) which will init, newfs, ... all very quickly, and is big > enough to test performance. You don't need to do the whole thing for that. > (Doing it just on the hope that this will be the last time, will almost > certainly have Murphy intervene, and once you have the basics correct, > just making the number of blocks bigger won't change anything except its > size.) So for the raid partitions on wd0 (etc) use 1/2 of the size you > want (for testing) for each (for a 3 drive raid5). > > | My raid experience is, as you have guessed, small... coming from zfs, > | where it was kind of plug and play, i expected some push back here... > | not this much though. > > Beyond what you seem to be doing, just make sure that the filesystems > inside the raid are correctly aligned on raid stripes (which will be > 64 blocks, 32KB, assuming you used the same params as before, except > with a 3 drive set instead of 4). That is, everything should be aligned > on (and sized to be) a multiple of 64 blocks within the raid, and your > filesystem block size (-b to newfs) should be 32768 or 65536 (you can set > a smaller frag size, -f, any binary fraction of the block size, down to 1/8, > ie: 4096 for 32K blocksize, is OK, and uses less space for small files, > including directories.) You could also use SectPerSU as 16 if you're > needing to conserve space (at the expense of some speed) - if you do that > all the numbers (bigger than 4) above (in this paragraph) can be halved > as well. You'd use less RAM for the raidset, and with a smaller blocksize > potentially have less wasted space in the filesystem (though that is a > complex thing to evaluate.) I wouldn't recommend < 16 though, the performance > loss then is likely to be more noticeable, but you can certainly test it, > it needs to be a power of 2, and is a number of blocks - the actual raidset > stripe size is then the number of data drives (don't count the parity) > multiplied by that number. [Yes, I know, with raid5, all drives are data > drives technically, all are also parity drives, but it is simpler to forget > that optimisation, and just say that 1 of the drives is parity, the remainder > are data .. just don't try and speculate which drive is which, as they > really aren't.] > > kre > A bit of an update. I did not see any big difference in raid5, if i use 3 or 4 drives. Not either if i use like 64k blocks / align or 1m... this has me worried... So, Tried to do a raid10, and got blazing speeds! with these parameters, cutting away some parts... and yes i know i can remove the -s 1g for the log, if im not going ot use it... and yes labels are incorrectly named raid5 even with the raid10... Tried to do a raid5 with these parameters aswell, but no real difference, i think it is the speed i pasted below for raid5... gpt add -t raid -l raid5@wd0 -b 1m -a 1m -s 1000g wd0 **** gpt add -a 1m -b 1m -t ffs -l island raid1 gpt add -a 1m -b 1m -t ffs -l island raid2 newfs -O2 -a 1m -b 64k -s -1g /dev/dk7 newfs -O2 -a 1m -b 64k -s -1g /dev/dk8 gpt add -a 1m -b 1m -t ffs -l island raid0 dkctl raid0 addwedge island3 1048576 4191152128 ffs newfs -O2 -a 1m -b 64k -s -1g /dev/dk9 Where for both raid1 and raid0 i used # sectPerSU SUsPerParityUnit SUsPerReconUnit RAID_level_0 128 1 1 0/1 depeding on raid type START queue fifo 127 4194304000 bytes transferred in 8.255 secs (508092549 bytes/sec) CHAZAAAM! The best i got for raid5 so far, is: 4194304000 bytes transferred in 107.170 secs (39136922 bytes/sec) So raid10 is the backup plan :) after re-reading your mail, i will try raid5 a few more attempts... In raid5.conf you suggest: 16 1 1 5 that would have me use these commands while doing the disks and raid gpt add -t raid -l raid5@wd0 -b 64k -a 32k -s 1000g wd0 **** gpt add -a 32k -b 64k -t ffs -l island raid5 newfs -O2 -a 32k -b 64k -s -1g /dev/dk7 or did i missunderstand something? Many many thanks again, for bearing with me!! br smurfd