Some Users Have Been Hitting EXT4 File-System Corruption On Linux 4.19

[elvenbone]

Ext4 is stable. old/broken ssds, 1000Hz timer kernels with other buggy drivers are not stable. Read the bug discussion. I am testing kernels with the latest amdgpu driver and it is a very violent event for the ssd when the system freezes to some X desktop incompatibility vsync bug. Sure btrfs would not work any better when the whole kernel goes crazy.

You are having freezes on Debian with XFCE? I thought it was stable.

[Ardje]

ALRBP : yup, I am also feeling funny when the Btrfs that I am using everywhere (laptop, workstation, server, phone, pi...) happens to be the stable one, compared to venerable ext4. That's some irony.

I have yet to see corruption on my desktop use of btrfs, but in any environment with real I/O load btrfs has always managed to kill itself. I even went so far as to have a btrfs.fsck running for over 6 months on a $10k machine before it ate up all the swapspace we could give it (450GB of swap) to have it parse it's 250GB metadata. As a test of course, and it failed.
That was some time ago. The way it could handle snapshots did outweigh the amount of do-over work, as it was a backup of a backup of a backup.
To be clear: I had my fair share of ext4 bugs, but they never lead to filesystem corruption, just to OOMs. Out of all filesystems I've tested it was the most stable one.
Still I hope to switch more and more to f2fs, btrfs and bcachefs.
f2fs gave me my fair share of problems, but they were 100% attributable to the bad shape of the sdhc-pci for the SoC in the WIN1. In all other cases (running it on eMMC and on uSD on decent hardware like odroids: 100% trustworthy).
sdhc-pci still has bugs when it comes to the WIN2, but it doesn't seem to lose writes anymore.

[elvenbone]

Xfce is stable but my custom kernels are not when I am testing them. Debian has nothing to do with my GPU drivers, I use Oibaf ppa too.

Ok, I see. Sorry for the trolling, I couldn't resist.

---

Is there any way to check for corruptions on mounted file-systems? I reverted to 4.18 due to other issues, but would like to check whether 4.19 did any damage...

[birdie]

Is there any way to check for corruptions on mounted file-systems? I reverted to 4.18 due to other issues, but would like to check whether 4.19 did any damage...

As far as I know only Windows 10 allows to check mounted NTFS. As for Linux reboot into single mode and run `e2fsck -v -C 0 -t -D`

I've already done that since I lost a couple of file to 4.19. :-(

[aufkrawall]

I'm having a weird issue with an ext4 data partition which sometimes is unmountable. Highly annoying, but at least not data corruption.

Huh, false alarm. It turned out that mounting via fstab was confused by Windows' MSR partition, it somehow mistook it for my ext4 data partition which is mounted via a unique label. So, apparently some weird bug, but not filesystem related.

[Vistaus]

Huh. I'm sure it varies from one setup to another, but I've been running 4.19 on a couple of machines without any issues.

Same here.

[stingray454]

I had my first ever ext4 disk crash just after moving to 4.19 a while ago.. One day when bootin up the file system was just completely broken. Chalked it up to not being shut down correctly (might have had a power outage while I was gone), but it's fine after a reformat / reinstall. Might very well have been this.

[AndyChow]

I almost lost hundreds of gigabytes of video (wedding camera footage) to btrfs and wasted 2 weeks attempting to repair or recover through the tools. I eventually was able to start the process of manually coping every not-broken-thing to some other hard drives. The problem is that when my 12TB btrfs RAID10 pool did that, I needed another 12TB, so I had to delete my several terabyte steam library, and I've already been redownloading it since a week ago. My internet max speed is 1MB/s down...

Luckily, when originally transferring those video files, I remembered how technology tries to screw me over, so I copied the files in two other places.

Similar here. I had a situation last February I had help from two of the btrfs, including a genius one from Poland which spent maybe 5-8 hours debugging my situation. In the end, I was able to dump all the data over another array, but the partitions themselves remained unmountable. It was impossible to fix, but my issue allowed a patch to be contributed to the project. Afterwards I had the drives tested by four runs of badblocks, then scandisk, and no issues were found. So, I switched to ext4, because hey, what could go wrong? Now this... At least I used hashdeep to keep an integrity audit.

Can't trust btrfs, can't trust ext4... Things are pretty bad. Now I'm to the point that I think I need to keep backups on ext4, on btrfs, and on xfs, just in case.

[birdie]

Can't trust btrfs, can't trust ext4... Things are pretty bad. Now I'm to the point that I think I need to keep backups on ext4, on btrfs, and on xfs, just in case.

You cannot trust the kernels coming from the kernel devs - that's the issue. If you want a resemblance of stability - use RHEL or its clones.

[IlDonn]

I ran into that problem only on kde neon (based on 18.04), but not a single problem with ubuntu 18.04 unity or budgie (all of these with ext4 and kernel 4.19) and that's wired. first I ran into a "not writable directory" during updates installation and then when I restarted I saw the initramfs console