This is a v4 of:
ovl: introduce new "index=nouuid" option for inodes index feature
Changes in v3: rebase to overlayfs-next, replace uuid with null in file
handles, propagate ovl_fs to needed functions in a separate patch, add
separate bool "uuid=on/off" option, fix numfs check fallback, add a note
to docs.
Changes in v4: get rid of double negatives, remove nouuid leftower
comment, fix missprint in kernel config name.
CC: Amir Goldstein <[email protected]>
CC: Vivek Goyal <[email protected]>
CC: Miklos Szeredi <[email protected]>
CC: [email protected]
CC: [email protected]
Signed-off-by: Pavel Tikhomirov <[email protected]>
Pavel Tikhomirov (2):
ovl: propagate ovl_fs to ovl_decode_real_fh and ovl_encode_real_fh
ovl: introduce new "uuid=off" option for inodes index feature
Documentation/filesystems/overlayfs.rst | 6 ++++++
fs/overlayfs/Kconfig | 19 +++++++++++++++++++
fs/overlayfs/copy_up.c | 25 ++++++++++++++-----------
fs/overlayfs/export.c | 10 ++++++----
fs/overlayfs/namei.c | 23 +++++++++++++----------
fs/overlayfs/overlayfs.h | 14 ++++++++------
fs/overlayfs/ovl_entry.h | 1 +
fs/overlayfs/super.c | 25 +++++++++++++++++++++++++
fs/overlayfs/util.c | 3 ++-
9 files changed, 94 insertions(+), 32 deletions(-)
--
2.26.2
This replaces uuid with null in overelayfs file handles and thus relaxes
uuid checks for overlay index feature. It is only possible in case there
is only one filesystem for all the work/upper/lower directories and bare
file handles from this backing filesystem are uniq. In other case when
we have multiple filesystems lets just fallback to "uuid=on" which is
and equivalent of how it worked before with all uuid checks.
This is needed when overlayfs is/was mounted in a container with index
enabled (e.g.: to be able to resolve inotify watch file handles on it to
paths in CRIU), and this container is copied and started alongside with
the original one. This way the "copy" container can't have the same uuid
on the superblock and mounting the overlayfs from it later would fail.
Note: In our (Virtuozzo) use case users inside a container can create
"regular" overlayfs mounts without any "index=" option, but we still
want to migrate this containers with CRIU so we set "index=on" as kernel
default so that all the container overlayfs mounts get support of file
handles automatically. With "uuid=off" we want the same thing (to be
able to "copy" container with uuid change) - we would set kernel default
so that all the container overlayfs mounts get "uuid=off" automatically.
That is an example of the problem on top of loop+ext4:
dd if=/dev/zero of=loopbackfile.img bs=100M count=10
losetup -fP loopbackfile.img
losetup -a
#/dev/loop0: [64768]:35 (/loop-test/loopbackfile.img)
mkfs.ext4 loopbackfile.img
mkdir loop-mp
mount -o loop /dev/loop0 loop-mp
mkdir loop-mp/{lower,upper,work,merged}
mount -t overlay overlay -oindex=on,lowerdir=loop-mp/lower,\
upperdir=loop-mp/upper,workdir=loop-mp/work loop-mp/merged
umount loop-mp/merged
umount loop-mp
e2fsck -f /dev/loop0
tune2fs -U random /dev/loop0
mount -o loop /dev/loop0 loop-mp
mount -t overlay overlay -oindex=on,lowerdir=loop-mp/lower,\
upperdir=loop-mp/upper,workdir=loop-mp/work loop-mp/merged
#mount: /loop-test/loop-mp/merged:
#mount(2) system call failed: Stale file handle.
If you just change the uuid of the backing filesystem, overlay is not
mounting any more. In Virtuozzo we copy container disks (ploops) when
crate the copy of container and we require fs uuid to be uniq for a new
container.
CC: Amir Goldstein <[email protected]>
CC: Vivek Goyal <[email protected]>
CC: Miklos Szeredi <[email protected]>
CC: [email protected]
CC: [email protected]
Signed-off-by: Pavel Tikhomirov <[email protected]>
---
v2: in v1 I missed actual uuid check skip
v3: rebase to overlayfs-next, replace uuid with null in file handles,
split ovl_fs propagation to function arguments to separate patch, add
separate bool "uuid=on/off" option, move numfs check up, add doc note.
v4: get rid of double negatives, remove nouuid leftower comment, fix
missprint in kernel config name
Documentation/filesystems/overlayfs.rst | 6 ++++++
fs/overlayfs/Kconfig | 19 +++++++++++++++++++
fs/overlayfs/copy_up.c | 3 ++-
fs/overlayfs/namei.c | 4 +++-
fs/overlayfs/ovl_entry.h | 1 +
fs/overlayfs/super.c | 25 +++++++++++++++++++++++++
6 files changed, 56 insertions(+), 2 deletions(-)
diff --git a/Documentation/filesystems/overlayfs.rst b/Documentation/filesystems/overlayfs.rst
index 580ab9a0fe31..4f9cc20f255c 100644
--- a/Documentation/filesystems/overlayfs.rst
+++ b/Documentation/filesystems/overlayfs.rst
@@ -563,6 +563,12 @@ This verification may cause significant overhead in some cases.
Note: the mount options index=off,nfs_export=on are conflicting for a
read-write mount and will result in an error.
+Note: the mount option uuid=off (or corresponding module param, or kernel
+config) can be used to replace UUID of the underlying filesystem in file
+handles with null, and effectively disable UUID checks. This can be useful in
+case the underlying disk is copied and the UUID of this copy is changed. This
+is only applicable if all lower/upper/work directories are on the same
+filesystem, otherwise it will fallback to normal behaviour.
Volatile mount
--------------
diff --git a/fs/overlayfs/Kconfig b/fs/overlayfs/Kconfig
index dd188c7996b3..c21abdb43206 100644
--- a/fs/overlayfs/Kconfig
+++ b/fs/overlayfs/Kconfig
@@ -61,6 +61,25 @@ config OVERLAY_FS_INDEX
If unsure, say N.
+config OVERLAY_FS_INDEX_UUID
+ bool "Overlayfs: export uuid in file handles"
+ default y
+ depends on OVERLAY_FS
+ help
+ If this config option is disabled then overlay will replace uuid with
+ null in overlayfs file handles, effectively disabling uuid checks for
+ them. This affects overlayfs mounted with "index=on". This only can be
+ done if all upper and lower directories are on the same filesystem
+ where basic fhandles are uniq. In case the latter is not true
+ overlayfs would fallback to normal uuid checking mode.
+
+ Disabling it is needed to overcome possible change of uuid on
+ superblock of the backing filesystem, e.g. when you copied the
+ virtual disk and mount both the copy of the disk and the original one
+ at the same time.
+
+ If unsure, say Y.
+
config OVERLAY_FS_NFS_EXPORT
bool "Overlayfs: turn on NFS export feature by default"
depends on OVERLAY_FS
diff --git a/fs/overlayfs/copy_up.c b/fs/overlayfs/copy_up.c
index 3380039036d6..0b7e7a90a435 100644
--- a/fs/overlayfs/copy_up.c
+++ b/fs/overlayfs/copy_up.c
@@ -320,7 +320,8 @@ struct ovl_fh *ovl_encode_real_fh(struct ovl_fs *ofs, struct dentry *real,
if (is_upper)
fh->fb.flags |= OVL_FH_FLAG_PATH_UPPER;
fh->fb.len = sizeof(fh->fb) + buflen;
- fh->fb.uuid = *uuid;
+ if (ofs->config.uuid)
+ fh->fb.uuid = *uuid;
return fh;
diff --git a/fs/overlayfs/namei.c b/fs/overlayfs/namei.c
index f058bf8e8b87..f731eb4d35f9 100644
--- a/fs/overlayfs/namei.c
+++ b/fs/overlayfs/namei.c
@@ -159,8 +159,10 @@ struct dentry *ovl_decode_real_fh(struct ovl_fs *ofs, struct ovl_fh *fh,
/*
* Make sure that the stored uuid matches the uuid of the lower
* layer where file handle will be decoded.
+ * In case of uuid=off option just make sure that stored uuid is null.
*/
- if (!uuid_equal(&fh->fb.uuid, &mnt->mnt_sb->s_uuid))
+ if (ofs->config.uuid ? !uuid_equal(&fh->fb.uuid, &mnt->mnt_sb->s_uuid) :
+ !uuid_is_null(&fh->fb.uuid))
return NULL;
bytes = (fh->fb.len - offsetof(struct ovl_fb, fid));
diff --git a/fs/overlayfs/ovl_entry.h b/fs/overlayfs/ovl_entry.h
index 1b5a2094df8e..b7a73ea147b8 100644
--- a/fs/overlayfs/ovl_entry.h
+++ b/fs/overlayfs/ovl_entry.h
@@ -14,6 +14,7 @@ struct ovl_config {
bool redirect_follow;
const char *redirect_mode;
bool index;
+ bool uuid;
bool nfs_export;
int xino;
bool metacopy;
diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c
index 290983bcfbb3..a37995138b0d 100644
--- a/fs/overlayfs/super.c
+++ b/fs/overlayfs/super.c
@@ -43,6 +43,11 @@ module_param_named(index, ovl_index_def, bool, 0644);
MODULE_PARM_DESC(index,
"Default to on or off for the inodes index feature");
+static bool ovl_uuid_def = IS_ENABLED(CONFIG_OVERLAY_FS_INDEX_UUID);
+module_param_named(uuid, ovl_uuid_def, bool, 0644);
+MODULE_PARM_DESC(uuid,
+ "Export null uuid in file handles of inodes index feature");
+
static bool ovl_nfs_export_def = IS_ENABLED(CONFIG_OVERLAY_FS_NFS_EXPORT);
module_param_named(nfs_export, ovl_nfs_export_def, bool, 0644);
MODULE_PARM_DESC(nfs_export,
@@ -356,6 +361,8 @@ static int ovl_show_options(struct seq_file *m, struct dentry *dentry)
seq_printf(m, ",redirect_dir=%s", ofs->config.redirect_mode);
if (ofs->config.index != ovl_index_def)
seq_printf(m, ",index=%s", ofs->config.index ? "on" : "off");
+ if (ofs->config.uuid != ovl_uuid_def)
+ seq_printf(m, ",uuid=%s", ofs->config.uuid ? "on" : "off");
if (ofs->config.nfs_export != ovl_nfs_export_def)
seq_printf(m, ",nfs_export=%s", ofs->config.nfs_export ?
"on" : "off");
@@ -410,6 +417,8 @@ enum {
OPT_REDIRECT_DIR,
OPT_INDEX_ON,
OPT_INDEX_OFF,
+ OPT_UUID_ON,
+ OPT_UUID_OFF,
OPT_NFS_EXPORT_ON,
OPT_NFS_EXPORT_OFF,
OPT_XINO_ON,
@@ -429,6 +438,8 @@ static const match_table_t ovl_tokens = {
{OPT_REDIRECT_DIR, "redirect_dir=%s"},
{OPT_INDEX_ON, "index=on"},
{OPT_INDEX_OFF, "index=off"},
+ {OPT_UUID_ON, "uuid=on"},
+ {OPT_UUID_OFF, "uuid=off"},
{OPT_NFS_EXPORT_ON, "nfs_export=on"},
{OPT_NFS_EXPORT_OFF, "nfs_export=off"},
{OPT_XINO_ON, "xino=on"},
@@ -549,6 +560,14 @@ static int ovl_parse_opt(char *opt, struct ovl_config *config)
index_opt = true;
break;
+ case OPT_UUID_ON:
+ config->uuid = true;
+ break;
+
+ case OPT_UUID_OFF:
+ config->uuid = false;
+ break;
+
case OPT_NFS_EXPORT_ON:
config->nfs_export = true;
nfs_export_opt = true;
@@ -1877,6 +1896,7 @@ static int ovl_fill_super(struct super_block *sb, void *data, int silent)
ofs->share_whiteout = true;
ofs->config.index = ovl_index_def;
+ ofs->config.uuid = ovl_uuid_def;
ofs->config.nfs_export = ovl_nfs_export_def;
ofs->config.xino = ovl_xino_def();
ofs->config.metacopy = ovl_metacopy_def;
@@ -1956,6 +1976,11 @@ static int ovl_fill_super(struct super_block *sb, void *data, int silent)
if (!ovl_upper_mnt(ofs))
sb->s_flags |= SB_RDONLY;
+ if (!ofs->config.uuid && ofs->numfs > 1) {
+ pr_warn("The uuid=off requires a single fs for lower and upper, falling back to uuid=on.\n");
+ ofs->config.uuid = true;
+ }
+
if (!ovl_force_readonly(ofs) && ofs->config.index) {
err = ovl_get_indexdir(sb, ofs, oe, &upperpath);
if (err)
--
2.26.2
On Fri, Sep 25, 2020 at 11:35 AM Pavel Tikhomirov
<[email protected]> wrote:
>
> This replaces uuid with null in overelayfs file handles and thus relaxes
typo: overelayfs
> uuid checks for overlay index feature. It is only possible in case there
> is only one filesystem for all the work/upper/lower directories and bare
> file handles from this backing filesystem are uniq. In other case when
> we have multiple filesystems lets just fallback to "uuid=on" which is
> and equivalent of how it worked before with all uuid checks.
>
typo: uniq
> This is needed when overlayfs is/was mounted in a container with index
> enabled (e.g.: to be able to resolve inotify watch file handles on it to
> paths in CRIU), and this container is copied and started alongside with
> the original one. This way the "copy" container can't have the same uuid
> on the superblock and mounting the overlayfs from it later would fail.
>
> Note: In our (Virtuozzo) use case users inside a container can create
> "regular" overlayfs mounts without any "index=" option, but we still
> want to migrate this containers with CRIU so we set "index=on" as kernel
this container
> default so that all the container overlayfs mounts get support of file
> handles automatically. With "uuid=off" we want the same thing (to be
> able to "copy" container with uuid change) - we would set kernel default
> so that all the container overlayfs mounts get "uuid=off" automatically.
>
> That is an example of the problem on top of loop+ext4:
>
> dd if=/dev/zero of=loopbackfile.img bs=100M count=10
> losetup -fP loopbackfile.img
> losetup -a
> #/dev/loop0: [64768]:35 (/loop-test/loopbackfile.img)
> mkfs.ext4 loopbackfile.img
> mkdir loop-mp
> mount -o loop /dev/loop0 loop-mp
> mkdir loop-mp/{lower,upper,work,merged}
> mount -t overlay overlay -oindex=on,lowerdir=loop-mp/lower,\
> upperdir=loop-mp/upper,workdir=loop-mp/work loop-mp/merged
> umount loop-mp/merged
> umount loop-mp
> e2fsck -f /dev/loop0
> tune2fs -U random /dev/loop0
>
> mount -o loop /dev/loop0 loop-mp
> mount -t overlay overlay -oindex=on,lowerdir=loop-mp/lower,\
> upperdir=loop-mp/upper,workdir=loop-mp/work loop-mp/merged
> #mount: /loop-test/loop-mp/merged:
> #mount(2) system call failed: Stale file handle.
>
> If you just change the uuid of the backing filesystem, overlay is not
> mounting any more. In Virtuozzo we copy container disks (ploops) when
> crate the copy of container and we require fs uuid to be uniq for a new
typos: crat, uniq
> container.
>
> CC: Amir Goldstein <[email protected]>
> CC: Vivek Goyal <[email protected]>
> CC: Miklos Szeredi <[email protected]>
> CC: [email protected]
> CC: [email protected]
> Signed-off-by: Pavel Tikhomirov <[email protected]>
>
Apart from some typos, looks good to me.
You may add:
Reviewed-by: Amir Goldstein <[email protected]>
Please do not post v5. you should wait for more feedback from others.
> ---
> v2: in v1 I missed actual uuid check skip
> v3: rebase to overlayfs-next, replace uuid with null in file handles,
> split ovl_fs propagation to function arguments to separate patch, add
> separate bool "uuid=on/off" option, move numfs check up, add doc note.
> v4: get rid of double negatives, remove nouuid leftower comment, fix
> missprint in kernel config name
>
> Documentation/filesystems/overlayfs.rst | 6 ++++++
> fs/overlayfs/Kconfig | 19 +++++++++++++++++++
> fs/overlayfs/copy_up.c | 3 ++-
> fs/overlayfs/namei.c | 4 +++-
> fs/overlayfs/ovl_entry.h | 1 +
> fs/overlayfs/super.c | 25 +++++++++++++++++++++++++
> 6 files changed, 56 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/filesystems/overlayfs.rst b/Documentation/filesystems/overlayfs.rst
> index 580ab9a0fe31..4f9cc20f255c 100644
> --- a/Documentation/filesystems/overlayfs.rst
> +++ b/Documentation/filesystems/overlayfs.rst
> @@ -563,6 +563,12 @@ This verification may cause significant overhead in some cases.
> Note: the mount options index=off,nfs_export=on are conflicting for a
> read-write mount and will result in an error.
>
> +Note: the mount option uuid=off (or corresponding module param, or kernel
> +config) can be used to replace UUID of the underlying filesystem in file
> +handles with null, and effectively disable UUID checks. This can be useful in
> +case the underlying disk is copied and the UUID of this copy is changed. This
> +is only applicable if all lower/upper/work directories are on the same
> +filesystem, otherwise it will fallback to normal behaviour.
>
> Volatile mount
> --------------
> diff --git a/fs/overlayfs/Kconfig b/fs/overlayfs/Kconfig
> index dd188c7996b3..c21abdb43206 100644
> --- a/fs/overlayfs/Kconfig
> +++ b/fs/overlayfs/Kconfig
> @@ -61,6 +61,25 @@ config OVERLAY_FS_INDEX
>
> If unsure, say N.
>
> +config OVERLAY_FS_INDEX_UUID
> + bool "Overlayfs: export uuid in file handles"
> + default y
> + depends on OVERLAY_FS
> + help
> + If this config option is disabled then overlay will replace uuid with
> + null in overlayfs file handles, effectively disabling uuid checks for
> + them. This affects overlayfs mounted with "index=on". This only can be
> + done if all upper and lower directories are on the same filesystem
> + where basic fhandles are uniq. In case the latter is not true
There are some typos in it, but I think this phrase can be dropped:
"where basic fhandles are uniq"
Thanks,
Amir.
On 9/25/20 7:42 PM, Amir Goldstein wrote:
> Apart from some typos, looks good to me.
Amir, Thanks a lot for your review!
> you should wait for more feedback from others
Sure, will wait.
--
Best regards, Tikhomirov Pavel
Software Developer, Virtuozzo.
On Fri, Sep 25, 2020 at 10:35 AM Pavel Tikhomirov
<[email protected]> wrote:
> Note: In our (Virtuozzo) use case users inside a container can create
> "regular" overlayfs mounts without any "index=" option, but we still
> want to migrate this containers with CRIU so we set "index=on" as kernel
> default so that all the container overlayfs mounts get support of file
> handles automatically. With "uuid=off" we want the same thing (to be
> able to "copy" container with uuid change) - we would set kernel default
> so that all the container overlayfs mounts get "uuid=off" automatically.
I'm not sure I buy that argument for a kernel option. It should
rather be a "container" option in that case, but AFAIK the kernel
doesn't have a concept of a container. I think this needs to be
discussed on the relevant mailing lists.
As of now mainline kernel doesn't support unprivileged overlay mounts,
so I guess this is not an issue. Let's just merge this without the
kernel and the module options.
Thanks,
Miklos
On 10/6/20 6:13 PM, Miklos Szeredi wrote:
> On Fri, Sep 25, 2020 at 10:35 AM Pavel Tikhomirov
> <[email protected]> wrote:
>
>> Note: In our (Virtuozzo) use case users inside a container can create
>> "regular" overlayfs mounts without any "index=" option, but we still
>> want to migrate this containers with CRIU so we set "index=on" as kernel
>> default so that all the container overlayfs mounts get support of file
>> handles automatically. With "uuid=off" we want the same thing (to be
>> able to "copy" container with uuid change) - we would set kernel default
>> so that all the container overlayfs mounts get "uuid=off" automatically.
>
> I'm not sure I buy that argument for a kernel option. It should
> rather be a "container" option in that case, but AFAIK the kernel
> doesn't have a concept of a container. I think this needs to be
> discussed on the relevant mailing lists.
>
> As of now mainline kernel doesn't support unprivileged overlay mounts,
> so I guess this is not an issue. Let's just merge this without the
> kernel and the module options.
Virtuozzo kernel does have a "container" concept and we do have
unprivileged overlay mounts to support docker inside Virtuozzo
containers. We don't face any major issues with it. But you are right
it's not mainstream.
Probably a normal user of mainstream kernel also might want to set
index=on+uuid=off by default, so that all their docker containters
automatically support inotifies and survive backing disk uuid change
automaticaly.
I will prepare next patchset version without default.
>
> Thanks,
> Miklos
>
--
Best regards, Tikhomirov Pavel
Software Developer, Virtuozzo.