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