linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: kreijack@inwind.it, Adam Borowski <kilobyte@angband.pl>,
	Andrei Borzenkov <arvidjaar@gmail.com>
Cc: "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: Can I see what device was used to mount btrfs?
Date: Wed, 3 May 2017 07:26:51 -0400	[thread overview]
Message-ID: <dd909c77-5014-3ec8-a976-7290145ad46d@gmail.com> (raw)
In-Reply-To: <c7f3c9fe-2f28-e102-9df7-273dc5a6ca8e@inwind.it>

On 2017-05-02 15:50, Goffredo Baroncelli wrote:
> On 2017-05-02 20:49, Adam Borowski wrote:
>>> It could be some daemon that waits for btrfs to become complete.  Do we
>>> have something?
>> Such a daemon would also have to read the chunk tree.
>
> I don't think that a daemon is necessary. As proof of concept, in the past I developed a mount helper [1] which handled the mount of a btrfs filesystem:
> this handler first checks if the filesystem is a multivolume devices, if so it waits that all the devices are appeared. Finally mount the filesystem.
>
>> It's not so simple -- such a btrfs device would have THREE states:
>>
>> 1. not mountable yet (multi-device with not enough disks present)
>> 2. mountable ro / rw-degraded
>> 3. healthy
>
> My mount.btrfs could be "programmed" to wait a timeout, then it mounts the filesystem as degraded if not all devices are present. This is a very simple strategy, but this could be expanded.
>
> I am inclined to think that the current approach doesn't fit well the btrfs requirements.  The roles and responsibilities are spread to too much layer (udev, systemd, mount)... I hoped that my helper could be adopted in order to concentrate all the responsibility to only one binary; this would reduce the interface number with the other subsystem (eg systemd, udev).
The primary problem is that systemd treats BTRFS like a block-layer 
instead of a filesystem (so it assumes all devices need to be present), 
and that it doesn't trust the kernel's mount function to work correctly. 
  As a result, it assumes that the mount operation will fail if it 
doesn't see all the devices instead of just trying it like it should.
>
> For example, it would be possible to implement a sane check that prevent to mount a btrfs filesystem if two devices exposes the same UUID...
>
>
> BR
> G.Baroncelli
>
> [1] See "[RFC][PATCH v2] mount.btrfs helper" thread ( https://marc.info/?l=linux-btrfs&m=141736989508243&w=2 )
>


  parent reply	other threads:[~2017-05-03 11:26 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-30  5:47 Can I see what device was used to mount btrfs? Andrei Borzenkov
2017-05-02  3:26 ` Anand Jain
2017-05-02 13:58 ` Adam Borowski
2017-05-02 14:19   ` Andrei Borzenkov
2017-05-02 18:49     ` Adam Borowski
2017-05-02 19:50       ` Goffredo Baroncelli
2017-05-02 20:15         ` Kai Krakow
2017-05-02 20:34           ` Adam Borowski
2017-05-03 11:32           ` Austin S. Hemmelgarn
2017-05-03 17:05           ` Goffredo Baroncelli
2017-05-03 18:43             ` Chris Murphy
2017-05-03 21:19               ` Duncan
2017-05-04  2:15                 ` Chris Murphy
2017-05-04  3:48               ` Andrei Borzenkov
2017-05-03 11:26         ` Austin S. Hemmelgarn [this message]
2017-05-03 18:12           ` Andrei Borzenkov
2017-05-03 18:53             ` 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=dd909c77-5014-3ec8-a976-7290145ad46d@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=arvidjaar@gmail.com \
    --cc=kilobyte@angband.pl \
    --cc=kreijack@inwind.it \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).