All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stanislav Brabec <sbrabec@suse.cz>
To: Karel Zak <kzak@redhat.com>
Cc: util-linux@vger.kernel.org, "David Štěrba" <dsterba@suse.cz>
Subject: Re: [PATCH] libmount: handle btrfs default subvolume mount
Date: Thu, 28 Jan 2016 15:22:07 +0100	[thread overview]
Message-ID: <56AA240F.5010900@suse.cz> (raw)
In-Reply-To: <56A15487.8020500@suse.cz>

Stanislav Brabec wrote:
> Known problems not covered by this patch:
>
> - Use of subvolid= in fstab is not yet handled.

Patch already created, see mails:
[PATCH 1/2] libmount: run btrfs subvol checks for "subvolid" option
[PATCH 2/2] libmount: code re-indentation

> - Use of type auto in combination with subvol= in fstab is not yet
>    handled.

Patch already created, see:
[PATCH] libmount: run btrfs subvol checks for "auto" fs type

> - Use of btrfs in loop devices, where image file is specified in fstab is
>    not yet handled (use of /dev/loop0 in fstab works).

With all patches above, I cannot reproduce any more.
Tested situations:
- with and without "loop" option
- with "subvol" or "subvolid" options referring to non-default subvolume
- without "subvol" or "subvolid" referring to default subvolume
- with "btrfs" and "auto" fs type
=> I think that it is now fixed as well.

> - If fstab uses subvol=, and subvol path changes since last "mount -a",
>    subsequent "mount -a" will not recognize that it is already mounted,
>    and it will attempt to mount it second time. To fix it, libmount should
>    remember subvolid in time of mount (subvolid is unique for the
>    subvolume, subvol is not).

I have no plans to write a fix for that now. Too obscure situation.

> - mountinfo contains subvol and subvolid since kernel 4.2. Before kernel
>    4.2, there is no reasonable way to solve this situation. (One would
>    create temporary mount point, mount the default, call needed ioctl() to
>    determine what was mounted, deduce the default subvolume, compare it
>    with subvolume of mounted volume, unmount and return result.)

There is no reasonable way to detect whether default subvolume was mounted.

In case of mounting with subvolid, there is a way to detect subvolume 
path even before kernel 4.2: If mountinfo lookup fails, then use 
btrfs_get_default_subvolume_path(). (See my mail dated
Thu, 21 Jan 2016 18:24:59 +0100 in this thread.) However fix is possible 
here, I have no plan to extent
[PATCH 1/2] libmount: run btrfs subvol checks for "subvolid" option
and implement it. It would be a fix of obscure situation in a kernel 
with unfixable issues of more common cases.


Summary: After applying of all patches mentioned here, I consider btrfs 
support as fixed in new kernels.

I strongly discourage advanced use of btrfs in fstab before kernel 4.2.

-- 
Best Regards / S pozdravem,

Stanislav Brabec
software developer
---------------------------------------------------------------------
SUSE LINUX, s. r. o.                         e-mail: sbrabec@suse.com
Lihovarská 1060/12                            tel: +49 911 7405384547
190 00 Praha 9                                 fax:  +420 284 084 001
Czech Republic                                    http://www.suse.cz/
PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76

  parent reply	other threads:[~2016-01-28 14:22 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-20 20:34 [PATCH] libmount: handle btrfs default subvolume mount Stanislav Brabec
2016-01-20 21:51 ` Stanislav Brabec
2016-01-20 21:57   ` Stanislav Brabec
2016-01-21  9:48     ` Karel Zak
2016-01-21 15:24       ` Stanislav Brabec
2016-01-21 15:37         ` Karel Zak
2016-01-21 15:45           ` Karel Zak
2016-01-21 17:24             ` Stanislav Brabec
2016-01-22  8:42             ` David Sterba
2016-01-21 21:58       ` Stanislav Brabec
2016-01-26 10:15         ` Karel Zak
2016-01-28 14:22         ` Stanislav Brabec [this message]
2016-02-01 12:18           ` Karel Zak
2016-02-01 15:38             ` Stanislav Brabec
2016-02-02 10:11               ` Karel Zak
2016-02-02 15:04                 ` Stanislav Brabec
2016-02-02 18:43                   ` Karel Zak
2016-02-02 19:36                     ` Stanislav Brabec

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=56AA240F.5010900@suse.cz \
    --to=sbrabec@suse.cz \
    --cc=dsterba@suse.cz \
    --cc=kzak@redhat.com \
    --cc=util-linux@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.