From: Goffredo Baroncelli <kreijack@inwind.it>
To: linux-btrfs@vger.kernel.org
Cc: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
Subject: Re: overlay file to test btrfs repairs
Date: Wed, 23 Mar 2016 20:45:54 +0100 [thread overview]
Message-ID: <56F2F272.5000001@inwind.it> (raw)
In-Reply-To: <56EFD981.7020606@gmail.com>
On 2016-03-21 12:22, Austin S. Hemmelgarn wrote:
[...]
> 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.
In the past I proposed (and implemented a prototype) of a mount.btrfs
helper [1]. The idea behind it was to collect all the action of
preparing a filesystem in only one place:
- collecting info about all the devices involved/needed
- taking the decision if a degraded filesystem has to be mounted
as degraded or an error has to be raised or continuing to wait for a new
device
- raising an error in case of conflicting uuid
Also it would be more simple to implement a logic to use an
"overlay device(s)": it could be done as option ! :-)
Now to implement these point we have to change several place (kernel, udev rules, btrfs scan utility) to got it... Not to mention that between the
first device discovery and the filesystem mount, there would be several
seconds due to boot process.
BR
G.Baroncelli
[1]http://marc.info/?l=linux-btrfs&m=141736989508243&w=2
--
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
next prev parent reply other threads:[~2016-03-23 19:45 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-21 3:43 overlay file to test btrfs repairs Chris Murphy
2016-03-21 9:55 ` Duncan
2016-03-21 11:22 ` Austin S. Hemmelgarn
2016-03-21 17:13 ` Chris Murphy
2016-03-22 14:21 ` Austin S. Hemmelgarn
2016-03-22 17:34 ` Duncan
2016-03-23 19:45 ` Goffredo Baroncelli [this message]
2016-03-22 20:42 ` Henk Slager
2016-03-23 11:17 ` Austin S. Hemmelgarn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56F2F272.5000001@inwind.it \
--to=kreijack@inwind.it \
--cc=ahferroin7@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.