Re: Horrendous RAIDframe reconstruction performance
On 6/28/20 7:31 PM, John Klos wrote: Any thoughts about what's going on here? Is this because the drives are 512e drives? Three weeks is a LONG time to reconstruct. So this turns out to be a failing drive. SMART doesn't show it's failing, but the one that's failing defaults to having the write cache off, and turning it on doesn't change the speed. Yep, that will do it. I guess it's still usable, in a limited way - I can only write at 5 or 6 MB/sec, but I can read at 200 MB/sec. Maybe I'll use it in an m68k Mac. Also, the autoconfigure works, but the forcing of root FS status didn't because I was testing it on a system that already had a RAIDframe with forced root. However, it still doesn't work on aarch64, but I'll recheck this after trying Jared's boot.cfg support. Thanks, Greg, Michael and Edgar. I learned something :) I am still curious about whether I was seeing both good read and write speeds because writes weren't going to both drives. I suppose I assumed that all writes would go to both drives even while reconstructing, but I suppose that only happens when the writes are inside of the area which has already been reconstructed, yes? Correct. Writes will go to both on stripes where reconstruction has completed, but will only go to the 'good' device if reconstruction hasn't reached that stripe yet. Later... Greg Oster
Re: Horrendous RAIDframe reconstruction performance
Any thoughts about what's going on here? Is this because the drives are 512e drives? Three weeks is a LONG time to reconstruct. So this turns out to be a failing drive. SMART doesn't show it's failing, but the one that's failing defaults to having the write cache off, and turning it on doesn't change the speed. I guess it's still usable, in a limited way - I can only write at 5 or 6 MB/sec, but I can read at 200 MB/sec. Maybe I'll use it in an m68k Mac. Also, the autoconfigure works, but the forcing of root FS status didn't because I was testing it on a system that already had a RAIDframe with forced root. However, it still doesn't work on aarch64, but I'll recheck this after trying Jared's boot.cfg support. Thanks, Greg, Michael and Edgar. I learned something :) I am still curious about whether I was seeing both good read and write speeds because writes weren't going to both drives. I suppose I assumed that all writes would go to both drives even while reconstructing, but I suppose that only happens when the writes are inside of the area which has already been reconstructed, yes? John
Re: Horrendous RAIDframe reconstruction performance
On 6/28/20 12:29 PM, Edgar Fuß wrote: That's the reconstruction algorithm. It reads each stripe and if it has a bad parity, the parity data gets rewritten. That's the way parity re-write works. I thought reconstruction worked differently. oster@? Reconstruction does not do the "read", "compare", "write" operation like parity checking. It just does "read", "compute", "write". In the case of RAID 1, "compute" does nothing ,and it's basically read from one component and write to the other. Later... Greg Oster
Re: Horrendous RAIDframe reconstruction performance
> That's the reconstruction algorithm. It reads each stripe and if it > has a bad parity, the parity data gets rewritten. That's the way parity re-write works. I thought reconstruction worked differently. oster@?
Re: Horrendous RAIDframe reconstruction performance
j...@ziaspace.com (John Klos) writes: >Next, raidctl doesn't handle NAME= for device yet: >raidctl -v -a NAME=raid8tb1 raid0 >raidctl: ioctl (RAIDFRAME_ADD_HOT_SPARE) failed: No such file or directory Yes, so far, only the config file knows about NAME= syntax. >Finally, even though these are absolutely not SMR drives, rebuild is >running at 3.5 to 4 MB/sec, whether attached via USB-3 or directly >attached via SATA: That's the reconstruction algorithm. It reads each stripe and if it has a bad parity, the parity data gets rewritten. This is very good for repairing a few missed writes e.g. after a power loss. It is abysmally slow when a drive gets replaced as every stripe is read, validated and then the parity is rewritten. If you don't have very smart drives, that needs one rotation of the media per stripe. For a raid mirror it is usually faster to copy the component manually and then trigger a parity check. The check then just reads all disks at high speed. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: Horrendous RAIDframe reconstruction performance
What is your stripe size? > [ 2.859768] dk0 at wd2: "raid8tb0", 15611274240 blocks at 1024, type: > raidframe At least the components seem to be properly aligned on the disc.
Horrendous RAIDframe reconstruction performance
Hello, I'm setting up two helium, non-SMR, 512e 8 TB disks (HGST HUH728080ALE604) in a RAIDframe mirror: [ 2.829768] wd2 at atabus2 drive 0 [ 2.829768] wd2: [ 2.829768] wd2: drive supports 16-sector PIO transfers, LBA48 addressing [ 2.829768] wd2: 7452 GB, 15504021 cyl, 16 head, 63 sec, 512 bytes/sect x 15628053168 sectors (0 bytes/physsect; first aligned sector: 8) [ 2.859768] wd2: GPT GUID: 4086e8f6-0ddd-4689-a942-80bf1b598539 [ 2.859768] dk0 at wd2: "raid8tb0", 15611274240 blocks at 1024, type: raidframe [ 2.859768] dk1 at wd2: "swap8tb0", 16777216 blocks at 15611275264, type: swap [ 2.869768] wd2: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133), WRITE DMA FUA, NCQ (32 tags) w/PRIO [ 2.869768] wd2(ahcisata0:4:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133) (using DMA), NCQ (31 tags) w/PRIO (Strange that it says "0 bytes/physsect") First, it seems that autoconfigure doesn't allow forcing the root filesystem. I'm guessing because this is using GPT: Autoconfig: Yes Root partition: Force Next, raidctl doesn't handle NAME= for device yet: raidctl -v -a NAME=raid8tb1 raid0 raidctl: ioctl (RAIDFRAME_ADD_HOT_SPARE) failed: No such file or directory Finally, even though these are absolutely not SMR drives, rebuild is running at 3.5 to 4 MB/sec, whether attached via USB-3 or directly attached via SATA: # raidctl -v -S raid0 Reconstruction is 0% complete. Parity Re-write is 100% complete. Copyback is 100% complete. Reconstruction status: 0% | | ETA: 485:13:54 - Interestingly, a bonnie++ run shows 80+ megabytes per second in block writes and 160+ megabytes per second on block read, and 185 random seeks per second, while reconstructing. Any thoughts about what's going on here? Is this because the drives are 512e drives? Three weeks is a LONG time to reconstruct. This is observed on NetBSD 9.99.68 on both i386 and on aarch64. Thanks, John Klos
