All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.