On 2016-03-21 13:13, Chris Murphy wrote:
On Mon, Mar 21, 2016 at 5:22 AM, Austin S. Hemmelgarn
<ahferro...@gmail.com> wrote:
On 2016-03-21 05:55, Duncan wrote:
Chris Murphy posted on Sun, 20 Mar 2016 21:43:52 -0600 as excerpted:
Hi folks,
So I just ran into this:
https://raid.wiki.kernel.org/index.php/
Recovering_a_failed_software_RAID#Making_the_harddisks_read-
only_using_an_overlay_file
[That's a single link, wrapped by my client.]
This is a device mapper overlay file - not overlayfs.
For the repairs that are sometimes uncertain what's next, maybe this is
a viable option to avoid changing the file system? I'm thinking
chunk-recover might take up too much space, I'm not sure how that one
works, if chunks are just being read or if they have to be rewritten or
if it's just the chunk tree? But for 'btrfs check' and 'btrfs rescue
super-recover/zero-log' there should be very little being written so the
overlay idea might be a good step?
Opinions?
That's a creative and potentially quite useful possible solution to an
often hairy problem. Thanks for bringing it up. =:^)
Provided Hugo and the devs don't find major fault with the idea, linking
that from appropriate locations (as a possible solution in the Problem
FAQ is the first one that occurs to me) in the btrfs wiki could be quite
useful, to many.
If we could find some way to have the programs themselves do this if the
system supports it (and the user opts in of course), it would be really
helpful. That said, I can see this possibly causing issues due to duplicate
device UUID's.
I thought of this. Btrfs seed device. The problem is it has some
minimal requirements (that I don't understand) for file system
integrity, probably starting out with the superblocks all being in a
good state. So literal leveraging of seed device is not possible, and
it's also non-obvious. Any repairs should be fail safe or they're
arguably broken. But if there were a way to effectively setup a seed +
ram or file based device behind the scene so that repairs can be
tested, that might be useful. And it would be mountable, even rw, and
that too would be reversible.
OTOH, if we could add some way to tell the code (both userspace and
in-kernel) to explicitly ignore specific devices when trying to assemble
filesystems, that would allow us to use DM snapshots (or something
similar) to do this, and would also allow people to work around the UUID
issues when dealing with LVM snapshots (or similar situations).
--
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
