Re: Corrupted system due to imbalanced metadata chunks

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

 



On 5/18/16, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote:
> On Tue, May 17, 2016 at 2:27 PM, Goni Zahavy <goni1993@xxxxxxxxx> wrote:
>> Guys, just remember that this crappy-installer behavior works
>> "as-expected"
>> on every other filesystem.
>
> It also fails as expected on every other file system if the upgrade is
> interrupted for reasons that have nothing to do with the file system;
> what's in common is the lack of a fail safe upgrade design. And this
> is not a ding on Ubuntu, it's a widespread and well recognized risk.
> All that's happening here is Btrfs has one more vector to expose that
> deficiency.

I fully agree, but I talked about the "many small files unpacked to
temp on disk location then copied.." which is just plain badness

>
>> I think we need to treat this as a trigger to unwanted/unexpected
>> behavior
>> on btrfs's part, especially in this "dead-simple" setup, in order for us
>> to
>> gain a bug/behavior fix in the near future.
>
> There are work arounds:
>
> use -M when creating the file system, accepting some loss of
> performance and inline small file packing efficiency;
>
> run a preemptive filtered balance on a timer.
>
> Fixing it in the kernel is a great idea, but if that were trivial I
> think it'd have been done by now. It's not like this problem is
> unknown on this list.
>
>> In my opinion, we simply cannot "blame" the user/installer code in the
>> current state of btrfs especially in the "considered stable enough"
>> feature
>> sets.
>
>
> OK blame was the wrong word for me to use, but the root cause of the
> problem is shared.
>
> I agree the user is least to blame, but so long as the status of the
> fs overall is benchmarking and review it's difficult to say the user
> has no role whatsoever in helping prevent it, as tedious as that is.
>
> --
> Chris Murphy
>

It's great that we have workarounds for the user/distribution to
apply. And If this is a known issue, I would expect that Peter Kese
would be answered here with "it's a known issue, here is how you can
work around it the next time. And it was written in underlined bold
warning on this wiki page. Stay tuned.".

In addition, I would expect bugs like this one that hit even simple
single-mode setups to be prioritized way way higher then any new
feature or even some existing advanced feature enhancements..

Just to clarify, I think that your work is devine and I'm glad for it.
I'm just trying to contribute here since I'm unable to contribute in
code/tests :)

Goni Zahavy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[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