Re: evidence of persistent state, despite device disconnects

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

 



Chris Murphy posted on Tue, 05 Jan 2016 14:47:52 -0700 as excerpted:

> On Tue, Jan 5, 2016 at 7:50 AM, Duncan <1i5t5.duncan@xxxxxxx> wrote:
> 
> 
>> If however you mounted it degraded,rw at some point, then I'd say the
>> bug is in wetware, as in that case, based on my understanding, it's
>> working as intended.  I was inclined to believe that was what happened
>> based on the obviously partial sequence in the earlier post, but if you
>> say you didn't... then it's all down to duplication and finding why
>> it's suddenly reverting to single mode on non-degraded mounts, which
>> indeed /is/ a bug.
> 
> Clearly I will have to retest.
> 
> But even as rw,degraded, it doesn't matter, that'd still be a huge bug.
> There's no possible way you'll convince me this is a user
> misunderstanding. No where is this documented.
> 
> I made the fs using mfks.btrfs -draid1 -mraid1. There is no way the fs,
> under any circumstance, legitimately creates and uses any other profile
> for any chunk type, ever. Let alone silently.

If you're mounting degraded,rw, and you're down to a single device on a 
raid1, then once the existing chunks fill up, it /has/ to create single 
chunks, because it can't create them raid1 as there's not enough devices 
(a minimum of two devices are required to create raid1 chunks, since two 
copies are required and they can't be on the same device).

And by mounting degraded,rw you've given it permission to create those 
single mode chunks if it has to, so it's not "silent", as you've 
explicitly mounted it degraded,rw, and single is what raid1 degrades to 
when there's only one device.

And with automatic empty-chunk deletion, existing chunks can fill up 
pretty fast...

Further, NOT letting it write single chunks when an otherwise raid1 btrfs 
is mounted in degraded,rw mode, would very possibly prevent you from 
repairing the filesystem with a btrfs replace or btrfs device add and 
delete.  And we've been there, done that, except slightly differently, 
with the can only mount degraded,rw until a single mode chunk is written, 
after which you can only mount degraded,ro, and then can't repair, which 
is the problem that the per-chunk check patches, vs. the old filesystem-
scope check, were designed to eliminate.

But as I said, if it's creating single chunks when you did /not/ have it 
mounted degraded, then you indeed have found a bug, and figuring out how 
to replicate it so it can be properly traced and fixed is where we're 
left, as I can't see how anyone would find that not a bug.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

--
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