linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrei Borzenkov <arvidjaar@gmail.com>
To: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>,
	kreijack@inwind.it, Adam Borowski <kilobyte@angband.pl>
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 21:12:54 +0300	[thread overview]
Message-ID: <56861b10-fb38-518c-0448-58a329839093@gmail.com> (raw)
In-Reply-To: <dd909c77-5014-3ec8-a976-7290145ad46d@gmail.com>

03.05.2017 14:26, Austin S. Hemmelgarn пишет:
> 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.

My understanding is that before kernel mount can succeed for
multi-device btrfs, kernel must be made aware of devices that comprise
this filesystem. This is done by using (equivalent of) "btrfs device
scan" or "btrfs device ready". Am I wrong here?

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

So do you suggest that mount will succeed even if kernel is not made
aware of all devices? If not, could you elaborate how btrfs should be
mounted on boot - we must give mount command some device, right? How
should we chose this device?


  reply	other threads:[~2017-05-03 18:12 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
2017-05-03 18:12           ` Andrei Borzenkov [this message]
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=56861b10-fb38-518c-0448-58a329839093@gmail.com \
    --to=arvidjaar@gmail.com \
    --cc=ahferroin7@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).