XFS Sees A Lot Of Cleanups For Linux 5.14

[phoronix]

Phoronix: XFS Sees A Lot Of Cleanups For Linux 5.14

The XFS file-system continues seeing a lot of work cleaning up the kernel driver code as well as some minor feature improvements heading into Linux 5.14...

https://www.phoronix.com/scan.php?page=news_item&px=XFS-Linux-5.14

[stormcrow]

I wish these fixes would end up in Ubuntu 20.04. I keep getting a silent reboot every time I use XFS on (K)Ubuntu + AMD + XFS on /. No actionable errors in the logs, just a silent reboot. Ext4 for / and everything is fine. Using OpenSUSE + XFS on / and everything is fine on the same system! I don't know what it is with Ubuntu, because I can't get any logs to figure it out, but something screwy is going on there with XFS support, at least when it comes to my hardware - and I don't think my hardware is all that uncommon. AMD Ryzen 5 3600, Intel 660 & 665 NVME SSDs (it doesn't matter which one has root - if it's XFS it'll eventually start rebooting), 32 GB RAM, AMD 5500XT, AMD x570 MSI motherboard. ¯\_(ツ)_/¯

Yes I know .. "don't use Ubuntu"

[waxhead]

I wish these fixes would end up in Ubuntu 20.04. I keep getting a silent reboot every time I use XFS on (K)Ubuntu + AMD + XFS on /. No actionable errors in the logs, just a silent reboot. Ext4 for / and everything is fine. Using OpenSUSE + XFS on / and everything is fine on the same system! I don't know what it is with Ubuntu, because I can't get any logs to figure it out, but something screwy is going on there with XFS support, at least when it comes to my hardware - and I don't think my hardware is all that uncommon. AMD Ryzen 5 3600, Intel 660 & 665 NVME SSDs (it doesn't matter which one has root - if it's XFS it'll eventually start rebooting), 32 GB RAM, AMD 5500XT, AMD x570 MSI motherboard. ¯\_(ツ)_/¯

Yes I know .. "don't use Ubuntu"

So since you know have you considered other things like testing your memory recently?!

[stormcrow]

So since you know have you considered other things like testing your memory recently?!

It's not a hardware failure issue of that sort. I've checked. It may be some hardware bug being triggered, but it's not a RAM failure problem. Lord knows there's enough bugs in the AMD video driver to fill a cricket cage at the local bait store. But for whatever reason, it's XFS that appears to be the only obvious connecting issue.

[piorunz]

It's not a hardware failure issue of that sort. I've checked. It may be some hardware bug being triggered, but it's not a RAM failure problem. Lord knows there's enough bugs in the AMD video driver to fill a cricket cage at the local bait store. But for whatever reason, it's XFS that appears to be the only obvious connecting issue.

Just use Debian, not Ubuntu. For me, Debian worked where many have failed. Manjaro silent reboots were a plague just like in your case. Every day. Since I reinstalled to Debian, not even one single reboot.

[Lanz]

I haven't been following too closely - why would I use XFS instead of say ext4 as a general desktop user running on an M.2 SSD?

[avem]

I haven't been following too closely - why would I use XFS instead of say ext4 as a general desktop user running on an M.2 SSD?

If $something works fine for you, why would you want to replace it with something else? To be honest ext4 in my experience has been the most reliable native Linux filesystem ever. I'm only really sad to see this Linux 5.13 change in the name of security: https://www.spinics.net/lists/kernel/msg3995488.html

[Snaipersky]

If $something works fine for you, why would you want to replace it with something else? To be honest ext4 in my experience has been the most reliable native Linux filesystem ever. I'm only really sad to see this Linux 5.13 change in the name of security: https://www.spinics.net/lists/kernel/msg3995488.html

As I understand it, looks like between initial delete and the the dirty period you could previously recover ownership/permissions, and timestamps, which is usually a 3-15 minute window. While anything that reduces failure recovery is a negative, It seems like a small window for users but fairly large for malware. It'd be best if it wasn't needed, but touching 2 decade old code sounds like someone was at least shown a PoC attack.

[stormcrow]

As I understand it, looks like between initial delete and the the dirty period you could previously recover ownership/permissions, and timestamps, which is usually a 3-15 minute window. While anything that reduces failure recovery is a negative, It seems like a small window for users but fairly large for malware. It'd be best if it wasn't needed, but touching 2 decade old code sounds like someone was at least shown a PoC attack.

I'm not so convinced this is a security patch as it is a operational guarantee fix from what I'm reading. "Operation X is supposed to complete in 1 transaction, but in reality it completes in N transactions." That can lead to issues. It's just amusing that it's never lead to any issues obvious enough to be fixed before now (the bug is 20 years old). Put another way, there was never a guarantee you could ever undelete on ext3/4 filesystems. You really shouldn't have been able to on any filesystems, but a file space zeroing on older hardware was always way too expensive for any but the smallest files, so unlinking files from directory trees was the best compromise.

From a regulatory compliance and forensics point of view, there's a lot of back and forth about metadata in the file systems, data areas, etc, but from a strictly user's perspective, it should have always been the case that a deleted file was gone forever.

[cynic]

I haven't been following too closely - why would I use XFS instead of say ext4 as a general desktop user running on an M.2 SSD?

for general purpouse desktop you probably won't notice any difference in term of performance between differents FS, so I'd look for features.
one feature that would make me prefer ext4 against xfs is the ability to shrink the filesystem, that might be handy.