Unresponsive system after upgrade to 13.3

[jb_fvwm2]

I would really like to avoid using a workaround for rsync. It's really a big part of my backup strategy. Unfortunately, thunar is not providing any info on what it was doing, but I think it being stuck was related to the rsync process running in the background.

I believe usb disks are poor targets for rsync because the program runs many instances of itself, if you want it to continue being responsive [ but the backup will take much longer ] use the --bwlimit= parameter. For USB I would use 900 and see if the lockups are fixed, and bump it up if so until you find its practical limit there. 9000 is almost full speed. [ Not certain to be a fix, but worth trying ]

 

[blackhaz]

If you're bored, you might try an old trick of mine to get ZFS to behave: significantly lower kern.maxvnodes. This will cost performance, and I don't know if it helps in this case, but it might.
I didn't try that, I just installed the patches from Seigo Tanimuro, and I'm fine.

Thanks for the suggestion, PMc, I think I'll just wait for the patches to appear in 13.3.

3. That screenshot of yours is pretty funky, fvwm(1?). What's the window bg color? I'm needing a change.

Thanks! This is Xfce with sgi-enhanced theme.

I believe usb disks are poor targets for rsync because the program runs many instances of itself, if you want it to continue being responsive [ but the backup will take much longer ] use the --bwlimit= parameter. For USB I would use 900 and see if the lockups are fixed, and bump it up if so until you find its practical limit there. 9000 is almost full speed. [ Not certain to be a fix, but worth trying ]

I have rsync running with bwlimit via ssh to a server and it doesn't freeze things, so yeah, it looks like related to the intensity of I/O operations. Hopefully 13.3 will be patched soon. Note the same rsync to USB worked absolutely fine in FreeBSD 13.2 without bwlimit.

 

[cracauer@]

I believe usb disks are poor targets for rsync because the program runs many instances of itself,

That's not true. It forks a single process on the remote side.

 

[blackhaz]

This is now https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277717
Hopefully a patch coming soon.

 

[blackhaz]

By the way, as per the last errata (FreeBSD-EN-24:09.zfs) this has been fixed. I have updated the system via binary patch and the rsync from ZFS to an external UFS USB drive works fine now.