Recent content by Mashie

I am the OP and the MDADM issues are resolved for me so no problems discussing alternatives from now on.

Can you expand volumes in ZFS with random number of disks yet or do you still need to add full vdevs?

Glad to hear things have improved. It was an update for MDADM to improve the performance in one of the recent kernel versions (which accidentally fixed the freezing bug).

That is indeed one of the kernel versions that caused this problem for me. I'm now on 22.04.01 LTS and the stock kernel is working fine with MDADM.

It was always the first write to the array after reboot that got stuck for up to 10 minutes. After that it would behave until next reboot.

The only thing to change in my system between today and the last reboot a week ago is that the kernel went from 5.11 to 5.13. 5.13 had work done to the mdadm implementation so whatever they did fixed this by accident.

Just to give an update on this, today kernel 5.13.0-25 was pushed out to this system and the issue is finally gone. :D

What is the easiest way to disable Thunar?

Hi @UhClem I didn't see you had replied here, I guess the email notification was lost in the ether. That command will happily trigger the stalling. mashie@IONE:~$ dd if=/dev/zero of=/mnt/storage/60MBzero bs=12M count=5 oflag=direct 5+0 records in 5+0 records out 62914560 bytes (63 MB, 60 MiB)...

I grew successfully from 10 -> 12 and expanded the file system which took quite a while. At this stage the stall would still happen after reboot, something had changed though as it no longer did the heavy reading/seeking on just 5 specific drives, it was now doing reading of all 12 drives and...

Thanks, any info about MDADM issues is welcome. I'm already on workstation hardware (E5-1650 v3 Xeon, ECC RAM and LSI 3905-24i controller).

And off we go, the reshaping should be done by Sunday evening at the current speed: mashie@IONE:~$ sudo mdadm /dev/md0 --add /dev/sdh1 mdadm: added /dev/sdh1 mashie@IONE:~$ sudo mdadm /dev/md0 --add /dev/sdk1 mdadm: added /dev/sdk1 mashie@IONE:~$ sudo mdadm --detail /dev/md0 /dev/md0...

This worked perfectly fine to trigger the stall with.

I originally had the array use the on-board SATA controllers and moving to the LSI 3905 was one attempt to rule the motherboard out. I don't have a spare motherboard/cpu to try with. The most important bits I have on Google Drive already so if the rest is lost it is mainly a massive inconvenience.

E4defrag started to speed up with many files tankfully not fragmented, it just finished: Success: [ 22324/24054 ] Failure: [ 1730/24054 ] Total extents: 256096->242202 Fragmented percentage: 26%->22% And it made no difference at all as...