Re: Is stability a joke? (wiki updated)

["Austin S. Hemmelgarn" <ahferroin7@gmail.com>]

On 2016-09-12 16:08, Chris Murphy wrote:
> On Mon, Sep 12, 2016 at 10:56 AM, Austin S. Hemmelgarn
> <ahferroin7@gmail.com> wrote:
>
>>
>> Things listed as TBD status:
>> 1. Seeding: Seems to work fine the couple of times I've tested it, however
>> I've only done very light testing, and the whole feature is pretty much
>> undocumented.
>
> Mostly OK.
>
> Odd behaviors:
> - mount seed (ro), add device, remount mountpoint: this just changed
> the mounted fs volume UUID
> - if two sprouts for a seed exist, ambiguous which is remounted rw,
> you'd have to check
> - remount should probably be disallowed in this case somehow; require
> explicit mount of the sprout
>
> btrfs fi usage crash when multiple device volume contains seed device
> https://bugzilla.kernel.org/show_bug.cgi?id=115851
Yeah, like I said, I've only done very light testing.  I kind of lost 
interest in seeding when overlayfs went mainline, as it offers pretty 
much everything I care about that seeding does, and it's filesystem 
agnostic.
>
>
>> 2. Device Replace: Works perfectly as long as the filesystem itself is not
>> corrupted, all the component devices are working, and the FS isn't using any
>> raid56 profiles.  Works fine if only the device being replaced is failing.
>> I've not done much testing WRT replacement when multiple devices are
>> suspect, but what I've done seems to suggest that it might be possible to
>> make it work, but it doesn't currently.  On raid56 it sometimes works fine,
>> sometimes corrupts data, and sometimes takes an insanely long time to
>> complete (putting data at risk from subsequent failures while the replace is
>> running).
>> 3. Balance: Works perfectly as long as the filesystem is not corrupted and
>> nothing throws any read or write errors.  IOW, only run this on a generally
>> healthy filesystem.  Similar caveats to those for replace with raid56 apply
>> here too.
>> 4. File Range Cloning and Out-of-band Dedupe: Similarly, work fine if the FS
>> is healthy.
>
> Concur.
>
>
> Missing from the matrix:
>
> - default file system for distros recommendation
> e.g. between enospc and btrfsck status, I'd say in general this is not
> currently recommended by upstream (short of having a Btrfs kernel
> developer on staff)
I'd add the whole UUID issue to that too.
>
> - enospc status
> e.g. there's new stuff in 4.8 that probably still needs to shake out,
> and Jeff's found some metadata accounting problem resulting in enospc
> where there's tons of unallocated space available.
> e.g. I have empty block groups, and they are not being deallocated,
> they just stick around, and this is with 4.7 and 4.8 kernels; so
> whatever was at one time automatically removing totally empty bg's
> isn't happening anymore.
FWIW, that's still working on my systems.
>
> - btrfsck status
> e.g. btrfs-progs 4.7.2 still warns against using --repair, and lists
> it under dangerous options also;  while that's true, Btrfs can't be
> considered stable or recommended by default
> e.g. There's still way too many separate repair tools for Btrfs.
> Depending on how you count there's at least 4, and more realistically
> 8 ways, scattered across multiple commands. This excludes btrfs
> check's -E, -r, and -s flags. And it ignores sequence in the success
> rate. The permutations are just excessive. It's definitely not easy to
> know how to fix a Btrfs volume should things go wrong.
I assume you're counting balance and scrub in that, plus check gives 3, 
what are you considering the 4th?

In the case of just balance, scrub, and check, the differentiation there 
makes more sense IMHO than combining them, check only runs on offline 
filesystems (and as much as we want online fsck, I doubt that that will 
happen any time soon), while scrub and balance operate on online 
filesystems and do two semantically different things.