2017-07-16 18:06 GMT+02:00 Marc MERLIN <m...@merlins.org>:
> On Sun, Jul 16, 2017 at 04:01:53PM +0200, Giuseppe Della Bianca wrote:
>> > On Fri, Jul 14, 2017 at 06:22:16PM -0700, Marc MERLIN wrote:
>> > > Dear Chris and other developers,
>> ]zac[
>> > Others on this thread with the same error: did anyone recover from this
>> > without wiping the filesystem?
>> >
>> > Is there a chance a balance might work around the bug so that whatever
>> > layout I have, changes, and stops the bug from occuring?
>> ]zac[
>>
>> Any attempt, even just delete files, has worsened the situation.
>> I advise not to waste time in repairs, and directly recreate the filesystem.
>
> I see. So, this is a condition where the filesystem is clear as far as:
> - check
> - check lowmem
> - scrub
> are all concerned (at least in my case), but it's in a state where
> touching something around a sensitive area causes the bug.
> If so, this blows, and I'm not really wanting to recreate a clean 12TB
> filesystem "just because", especially since this could just happen
> again after I've rebuilt it.
>
IMHO, rebuild from scratch, 1-2 times a year, the snapshot receive
filesystem is inevitable.
For this reason, my snapshot receive filesystems have only this
purpose and are not bigger than 1-2 TB.
>> while read proc; do
>> if [ $progResult == 0 ]; then
>> echo -e \nbtrfs tools already running
>>
>> progResult=222
>> fi
>>
>> echo $proc"
>> done < <(ps -ef | grep -e "btrfs
>> \{1,\}\(subvolume\|send\|receive\|delete\)")
>
> Yeah, I probably hit that. I think you can also add scrub to that list.
>
Yes.
I did not add scrubs because my scrub are always read-only.
And I think that race condition is between snapshot receive and
subvolume delete.
I also suggest:
- Use btrfs subvolume delete with -c
- Try to add a sleep after subvolume delete and receive.
> Marc
Gdb
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
