#Btrfs wipefs full#
#Btrfs wipefs free#

: Red Hat has recently announced that they are giving up on btrfs.

: Not a personal experience but these kind of threads bring tears to my eyes.

: An eye-opener post by a btrfs developer on recommended practices to keep your btrfs stable.

For posterity, here is a pastebin with the errors.

The fs has single profile data, so I cannot mount without the failing drive in rw mode and go from there, losing the scraps that remain in the bad device (it's scraps, because btrfs dev del moves everything out except the last metadata block, which furthermore is raid1!).

It seems replace is dutifully copying whatever error is encroached in the metadata to the replacement drive.

The drive can be btrfs replaced, but the new pristine drive cannot be then removed anyway, with the same errors.

btrfs check says the roots contain errors (that's more like it).

Scrub says the fs is clean (oh sweet summer child).

There were a couple of files with I/O errors on the bad sectors that I could delete without issue by mapping the inode reported by scrub on dmesg.

The filesystem was created on May 2017 (snapshot info says this).

dmesg info points to corrupted data in the metadata (not unable to read sectors with metadata). When doing the remove (I had plenty of space to spare), at the time of moving out the metadata blocks, btrfs falls on its sword. Time for btrfs to shine! I was ready, being this disk part of a two disks filesystem. After a long time not being bitten by any surprises, yesterday had an HDD start announcing bad sectors via SMART. And, since I'm daring that way, I'm still using the same filesystem without recreating it. After that, I could remove the devices without trouble. It did what your regular fsck used to do in FAT times: found a bunch of dangling files and put them in lost+found. Not as solidly as one would want: the first time it found and fixed things, the second time it found and fixed more things, and thereafter it was silent and happy.

: As closing to the previous entry: after trying all I could think of and backing up the data, I dared to use btrfsck -rescue and guess what, it worked.

#Btrfs wipefs full#

Using -repair can be destructive, and there is no warning unlike for full balancesДЇailure may give you only one chance at mounting read-write for rebuild TBD, but experienced as recently as 2018-10 A balance, or deletion of files + balance, should fix it

#Btrfs wipefs free#

You can get 'no free space left' even with plenty (many GBs) of it. Interrupting a balance might leave the system unmountableДifferent features/bugs between normal/lowmemory, can use large amounts of RAM Incomplete balances may cause unescapable read-only mountДЎ (personally bitten when reshaping a single to RAID1, IIRC) May eat lots of RAM/CPU, hang computer because of OOM.Дў0175024 ('it is now commomn knowledge', yet 'mostly OK' in official assesment), 20170131 (This happened to me once, had to use a live 4.9 USB to disable quotas, took many hours) Read-only snapshots are writable during receiveДata corruption likely on transient device failure

FeatureДon't count on having lots (>1k?) of them Only features where I disagree with the official assessment. And that is my main gripe with btrfs at present. Run 'old' kernels with known bugs or recent ones with unknown ones. However, that's not the problem, but that when you obey and use the bleeding edge kernels, you better be ready to find new bugs and possibly have to compile patched kernels. That's fine, I can understand why developers say so and too why users may not able to follow the recommendation. Since the official recommendation is to use the 'most modern kernel possible', be ready to be friendly scolded when you report a problem while not using it. This list is likely to become outdated as btrfs evolves since I'm not 100% on top of it. Also note that, despite the apparent criticism, I do use btrfs in my systems when I consider the advantages outweight the risks. Sure, this is my subjective interpretation I may be wrong or unfairly critical, refer to btrfs experts if in doubt. I have come to have a personal idea of what stable means in the btrfs world, which I offer here to any interested party. ForewordДЄfter some years of using btrfs and following the official mailing list, I still see weekly horror stories posted there from unsuspecting users. Take it as a peek into the past (but don'tДЇorget to check the official status page, as things like raid5/6ДЄnd quotas are still rife with caveats). My personal assessment on the btrfs stability/maturity status vs the official one at Foreword to the foreword Btrfs stability/maturity status - btrfs-status