Re: (One more) BTRFS damaged FS... Any hope ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi again Chris,

Le 11/03/2020 à 00:12, Chris Murphy a écrit :
> 
> Maybe some extent tree corruption. I'm thinking that the older kernel
> without an extensive tree checker won't care, and eventually things
> may get worse and unworkable again. But it might work for a while?

> What kernel version was it at the time of the problem? I see btrfs-progs 4.15.1

Actually I checked and the kernel itself was 5.3, only the tools are
4.15 - Yes that's Mint, you can install a newer kernel but the toolchain
is the distro's... The same goes for Ubuntu or Debian...

But a 5.3 kernel is actually pretty recent.

>> You could change fstab to include these two mount options:
> 
> flushoncommit,notreelog
> 
> The first probably won't slow things down, might help improve
> consistency if there's a crash; where the second will likely make
> certain things slower because it turns off fsync optimization and
> requires full sync each time.

Uh... The kid's got an old computer and I cannot consider anything that
would slow things down more than they already are...

As I could, thanks to you, mount the FS, I rsync'd it completely to
another one and saw that only 2 files from the python3 package and a
couple dozens from a flatpak cache were corrupt or missing. No big deal.

So I reformatted the original disk with its original uuid, recreated the
subvols, restored everything back into place, put the disk in another
laptop and it booted like a charm.

I then just reinstalled python3, ran system updates and voilà.

Now I only need to drop the SSD back into the little girl's ole PC.

Thanks again, without your kind assistance I would have been doomed to a
full reinstall and the kid would had lost her files - being a kid's
machine, no regular backups...

However a FS that badly dies is an issue anyway.

Not for a rant, but I've considered BRFS to be « slow but extremely
reliable » for at least 6 years.
And I certainly wouldn't have expected it to die because of a system
crash or power fail.

With time it became faster BUT in the past year I've already completely
lost 4 BTRFS filesystems on different machines, most from the 5.2 kernel
bugs and I don't consider this acceptable from an FS anybody would deem
“reliable”.

This plus the ugly “zero free space” bug in 5.3... I actually wonder
what's going on with BTRFS development...

Kind regards and thanks again.

ॐ

-- 
Swâmi Petaramesh <swami@xxxxxxxxxxxxxx> PGP 9076E32E



[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux