public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Lennart Poettering <lennart@poettering.net>
To: kreijack@inwind.it
Cc: Anand Jain <anand.jain@oracle.com>,
	Andrei Borzenkov <arvidjaar@gmail.com>,
	systemd-devel@lists.freedesktop.org, dsterba@suse.cz,
	"linux-btrfs@vger.kernel.org >> linux-btrfs"
	<linux-btrfs@vger.kernel.org>
Subject: Re: [systemd-devel] [survey] BTRFS_IOC_DEVICES_READY return status
Date: Mon, 15 Jun 2015 12:46:18 +0200	[thread overview]
Message-ID: <20150615104618.GB25616@gardel-login> (raw)
In-Reply-To: <557C479F.2070403@libero.it>

On Sat, 13.06.15 17:09, Goffredo Baroncelli (kreijack@libero.it) wrote:

> > Further, the problem will be more intense in this eg. if you use dd
> > and copy device A to device B. After you mount device A, by just
> > providing device B in the above two commands you could let kernel
> > update the device path, again all the IO (since device is mounted)
> > are still going to the device A (not B), but /proc/self/mounts and
> > 'btrfs fi show' shows it as device B (not A).
> > 
> > Its a bug. very tricky to fix.
> 
> In the past [*] I proposed a mount.btrfs helper . I tried to move the logic outside the kernel.
> I think that the problem is that we try to manage all these cases
> from a device point of view: when a device appears, we register the
> device and we try to mount the filesystem... This works very well
> when there is 1-volume filesystem. For the other cases there is a
> mess between the different layers:

> - kernel
> - udev/systemd
> - initrd logic
> 
> My attempt followed a different idea: the mount helper waits the
> devices if needed, or if it is the case it mounts the filesystem in
> degraded mode. All devices are passed as mount arguments
> (--device=/dev/sdX), there is no a device registration: this avoids
> all these problems.

Hmm, no. /bin/mount should not block for devices. That's generally
incompatible with how the tool is used, and in particular from
systemd. We would not make use for such a scheme in
systemd. /bin/mount should always be short-running.

I am pretty sure that if such automatic degraded mounting should be
supported, then this should be done with some background storage
daemon that alters the effect of the READY ioctl somehow after the
timeout, and then retriggers the devcies so that systemd takes
note. (or, alternatively: such a scheme could even be implemented all
in kernel, based on some configurable kernel setting...)

Lennart

-- 
Lennart Poettering, Red Hat

  parent reply	other threads:[~2015-06-15 10:46 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-12 13:16 [survey] BTRFS_IOC_DEVICES_READY return status Anand Jain
2015-06-12 18:04 ` [systemd-devel] " Andrei Borzenkov
2015-06-12 20:08   ` Goffredo Baroncelli
2015-06-13  9:35     ` Anand Jain
2015-06-13 15:09       ` Goffredo Baroncelli
     [not found]         ` <pan$63061$a3cdf5f6$a390adbd$e6097ad9@cox.net>
2015-06-14 19:44           ` Goffredo Baroncelli
2015-06-15 10:46         ` Lennart Poettering [this message]
2015-06-15 17:23           ` Goffredo Baroncelli
2015-06-15 17:38             ` Lennart Poettering
2015-06-17 19:10               ` Goffredo Baroncelli
2015-06-17 21:02                 ` Lennart Poettering
2015-06-18  2:40                   ` Andrei Borzenkov
2015-06-14  5:48       ` Andrei Borzenkov
2015-06-15 10:41       ` Lennart Poettering
2015-06-13  7:20 ` btrfs filesystem show confused when label is same as mountpoint Sjoerd
2015-06-13  9:51   ` Duncan
2015-06-25 16:37     ` David Sterba
2015-06-15 10:27 ` [survey] BTRFS_IOC_DEVICES_READY return status Lennart Poettering
2015-06-15 15:01 ` David Sterba

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=20150615104618.GB25616@gardel-login \
    --to=lennart@poettering.net \
    --cc=anand.jain@oracle.com \
    --cc=arvidjaar@gmail.com \
    --cc=dsterba@suse.cz \
    --cc=kreijack@inwind.it \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=systemd-devel@lists.freedesktop.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