* [PATCH v4 00/25] Overlayfs inodes index
@ 2017-06-21 12:28 Amir Goldstein
2017-06-21 17:02 ` Amir Goldstein
2017-06-22 10:18 ` [PATCH v4 26/25] ovl: document copying layers restrictions with " Amir Goldstein
0 siblings, 2 replies; 4+ messages in thread
From: Amir Goldstein @ 2017-06-21 12:28 UTC (permalink / raw)
To: Miklos Szeredi; +Cc: linux-unionfs, linux-fsdevel
Miklos,
This is it.
All done on my end, so unless you have any rejects that you want me
to fix, you may start mangling.
I've added another xfstest for nlink accounting and may add another
one that mangles with lower hardlinks to get negative overlay nlink.
It's a behavior I observed with lower/upper stress xfstest overlay/019
and fixed in patch 25.
Given the state of affairs with consistent d_ino patches, I suggest that
we focus on herding the inode index patches towards linux-next before
anything else.
Thanks,
Amir.
This work introduces the inodes index opt-in feature, which provides:
- Hardlinks are not broken on copy up
- Infrastructure for overlayfs NFS export
The work is available on my ovl-hardlinks.v4 branch [1].
For the curious, documentation about how overlay NFS export would work
with the inodes index is available in the linked commit [2].
The most significant change w.r.t. vfs is that with inodes index,
overlay inodes are hashed and unique throughout the lifecycle of an
overlay object (i.e. across copy up). This is required for not breaking
hardlinks on copy up.
Hardlink copy up tests including coverage for concurrent copy up of
lower hardlinks, lower/upper hardlinks consistency and union nlink
accounting are available on my xfstests dev branch [3].
This work also fixes constant st_ino for samefs case for lower hardlinks,
so the few constant st_ino tests that fail on v4.12-rc1 due to copy up of
lower hardlinks now pass [3][4].
Changes since v3:
- Persistent overlay nlink accounting
- Cleanup index when overlay nlink drops to zero
- Cleanup stale and orphan index entries on mount
- Update documentation w.r.t inodes index feature
Changes v1..v2:
- Introduce ovl_inode and ovl_inode mutex
- Synchronize copy up with ovl_inode mutex
- Don't store index dentry in overlay dentry
- Consistency of lower/upper hardlinks by link-up on lookup
- Preemptive copy up before lower hardlink unlink
[1] https://github.com/amir73il/linux/commits/ovl-hardlinks.v4
[2] https://github.com/amir73il/linux/commits/ovl-nfs-export
[3] https://github.com/amir73il/xfstests/commits/overlayfs-devel
[4] https://github.com/amir73il/unionmount-testsuite/commits/overlayfs-devel
Amir Goldstein (25):
vfs: introduce inode 'inuse' lock
ovl: get exclusive ownership on upper/work dirs
ovl: relax same fs constrain for ovl_check_origin()
ovl: generalize ovl_create_workdir()
ovl: introduce the inodes index dir feature
ovl: verify upper root dir matches lower root dir
ovl: verify index dir matches upper dir
ovl: store path type in dentry
ovl: cram dentry state booleans into type flags
ovl: lookup index entry for copy up origin
ovl: cleanup bad and stale index entries on mount
ovl: allocate an ovl_inode struct
ovl: store upper/lower real inode in ovl_inode_info
ovl: use ovl_inode_init() for initializing new inode
ovl: hash overlay non-dir inodes by copy up origin inode
ovl: defer upper dir lock to tempfile link
ovl: factor out ovl_copy_up_inode() helper
ovl: generalize ovl_copy_up_locked() using actors
ovl: generalize ovl_copy_up_one() using actors
ovl: use ovl_inode mutex to synchronize concurrent copy up
ovl: implement index dir copy up method
ovl: link up indexed lower hardlink on lookup
ovl: fix nlink leak in ovl_rename()
ovl: persistent overlay inode nlink for indexed inodes
ovl: cleanup orphan index entries
Documentation/filesystems/overlayfs.txt | 6 +-
fs/inode.c | 50 +++
fs/overlayfs/Kconfig | 20 +
fs/overlayfs/copy_up.c | 625 +++++++++++++++++++++++++-------
fs/overlayfs/dir.c | 164 ++++++++-
fs/overlayfs/inode.c | 160 +++++++-
fs/overlayfs/namei.c | 382 ++++++++++++++++---
fs/overlayfs/overlayfs.h | 47 ++-
fs/overlayfs/ovl_entry.h | 37 +-
fs/overlayfs/readdir.c | 50 +++
fs/overlayfs/super.c | 286 +++++++++++++--
fs/overlayfs/util.c | 164 +++++++--
include/linux/fs.h | 14 +
13 files changed, 1723 insertions(+), 282 deletions(-)
--
2.7.4
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v4 00/25] Overlayfs inodes index
2017-06-21 12:28 [PATCH v4 00/25] Overlayfs inodes index Amir Goldstein
@ 2017-06-21 17:02 ` Amir Goldstein
2017-06-21 20:03 ` Amir Goldstein
2017-06-22 10:18 ` [PATCH v4 26/25] ovl: document copying layers restrictions with " Amir Goldstein
1 sibling, 1 reply; 4+ messages in thread
From: Amir Goldstein @ 2017-06-21 17:02 UTC (permalink / raw)
To: Miklos Szeredi; +Cc: overlayfs, linux-fsdevel
On Wed, Jun 21, 2017 at 3:28 PM, Amir Goldstein <amir73il@gmail.com> wrote:
> Miklos,
>
> This is it.
> All done on my end, so unless you have any rejects that you want me
> to fix, you may start mangling.
>
> I've added another xfstest for nlink accounting and may add another
> one that mangles with lower hardlinks to get negative overlay nlink.
> It's a behavior I observed with lower/upper stress xfstest overlay/019
> and fixed in patch 25.
FYI1: I wrote that test and pushed to my xfstests dev branch.
The test found another corner case of lower hardlinks mangling.
I fixed that other case and re-posted patch 25 and force pushed
ovl-hardlinks.v4.
FYI2: Occasionally, I get the WARN_ON from drop_nlink() when
running the generic xfstest fsstress test generic/013:
generic/013 [16:50:00]run fstests generic/013 at 2017-06-21 16:50:00
------------[ cut here ]------------
WARNING: CPU: 0 PID: 10920 at
/home/amir/build/src/linux/fs/inode.c:282 drop_nlink+0x10/0x29
Call Trace:
ovl_do_remove.part.2+0x353/0x3bd
ovl_unlink+0x23/0x26
vfs_unlink+0xde/0x17d
do_unlinkat+0x10a/0x215
Since this is not an overlay specific test, all fsstress operation
are on pure upper, so I'm not sure how my patches could break
this test case. Because it happens rarely, its going to take me time
to bisect the problem.
My only immediate suspect is "ovl: fix nlink leak in ovl_rename()",
which is a generic change that drops nlink. Could you please take
a closer look at this patch to see if I missed something.
I will try to reproduce the issue with just this one patch.
Thanks,
Amir.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v4 00/25] Overlayfs inodes index
2017-06-21 17:02 ` Amir Goldstein
@ 2017-06-21 20:03 ` Amir Goldstein
0 siblings, 0 replies; 4+ messages in thread
From: Amir Goldstein @ 2017-06-21 20:03 UTC (permalink / raw)
To: Miklos Szeredi; +Cc: overlayfs, linux-fsdevel
On Wed, Jun 21, 2017 at 8:02 PM, Amir Goldstein <amir73il@gmail.com> wrote:
> On Wed, Jun 21, 2017 at 3:28 PM, Amir Goldstein <amir73il@gmail.com> wrote:
>> Miklos,
>>
>> This is it.
>> All done on my end, so unless you have any rejects that you want me
>> to fix, you may start mangling.
>>
>> I've added another xfstest for nlink accounting and may add another
>> one that mangles with lower hardlinks to get negative overlay nlink.
>> It's a behavior I observed with lower/upper stress xfstest overlay/019
>> and fixed in patch 25.
>
> FYI1: I wrote that test and pushed to my xfstests dev branch.
> The test found another corner case of lower hardlinks mangling.
> I fixed that other case and re-posted patch 25 and force pushed
> ovl-hardlinks.v4.
>
> FYI2: Occasionally, I get the WARN_ON from drop_nlink() when
> running the generic xfstest fsstress test generic/013:
>
> generic/013 [16:50:00]run fstests generic/013 at 2017-06-21 16:50:00
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 10920 at
> /home/amir/build/src/linux/fs/inode.c:282 drop_nlink+0x10/0x29
> Call Trace:
> ovl_do_remove.part.2+0x353/0x3bd
> ovl_unlink+0x23/0x26
> vfs_unlink+0xde/0x17d
> do_unlinkat+0x10a/0x215
>
> Since this is not an overlay specific test, all fsstress operation
> are on pure upper, so I'm not sure how my patches could break
> this test case. Because it happens rarely, its going to take me time
> to bisect the problem.
>
> My only immediate suspect is "ovl: fix nlink leak in ovl_rename()",
> which is a generic change that drops nlink. Could you please take
> a closer look at this patch to see if I missed something.
> I will try to reproduce the issue with just this one patch.
>
This patch is not to blame, nor are any of the other patches.
The problem goes back at least as far as kernel v4.10.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [PATCH v4 26/25] ovl: document copying layers restrictions with inodes index
2017-06-21 12:28 [PATCH v4 00/25] Overlayfs inodes index Amir Goldstein
2017-06-21 17:02 ` Amir Goldstein
@ 2017-06-22 10:18 ` Amir Goldstein
1 sibling, 0 replies; 4+ messages in thread
From: Amir Goldstein @ 2017-06-22 10:18 UTC (permalink / raw)
To: Miklos Szeredi; +Cc: linux-unionfs, linux-fsdevel
The inodes index feature introduces a behavior change - on mount,
upper root origin file handle is verified to match the lower root dir.
This implies that copied layers cannot be mounted with the inodes index
feature enabled, without explicitly removing the upper dir origin xattr
and the index dir.
The inodes index feature is required to support:
- Prevent breaking hardlinks on copy up
- NFS export support (upcoming)
- Overlayfs snapshots (POC)
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
---
Documentation/filesystems/overlayfs.txt | 34 +++++++++++++++++++++++++++++++++
1 file changed, 34 insertions(+)
Miklos,
I wrote in v4 posting that I updated the documentation, but forgot to send
out the documentation patch, so here goes.
There is one more behavior change that is related to indexing of directories
in v4.14, which we should consider including in v4.13, so v4.14 won't change
behavior of index enabled lookup.
The change is to verify lower of merge dir by origin and is available
on the following commit along with updated documentation [1]. I will post
this extra patch for your consideration after I am done running some more
tests.
Thanks,
Amir.
[1] https://github.com/amir73il/linux/commits/ovl-verify-dir
diff --git a/Documentation/filesystems/overlayfs.txt b/Documentation/filesystems/overlayfs.txt
index 8599fc9addbb..f63a8552bb81 100644
--- a/Documentation/filesystems/overlayfs.txt
+++ b/Documentation/filesystems/overlayfs.txt
@@ -201,6 +201,40 @@ rightmost one and going left. In the above example lower1 will be the
top, lower2 the middle and lower3 the bottom layer.
+Sharing and copying layers
+--------------------------
+
+Lower layers may be shared among several overlay mounts and that is indeed
+a very common practice. An overlay mount may use the same lower layer
+path as another overlay mount and it may use a lower layer path that is
+beneath or above the path of another overlay lower layer path.
+
+Using an upper layer path and/or a workdir path that are already used by
+another overlay mount is not allowed and will fail with EBUSY. Using
+partially overlapping paths is not allowed but will not fail with EBUSY.
+
+Mounting an overlay using an upper layer path, where the upper layer path
+was previously used by another mounted overlay in combination with a
+different lower layer path, is allowed, unless the "inodes index" feature
+is enabled.
+
+With the "inodes index" feature, on the first time mount, an NFS file
+handle of the lower layer root directory, along with the UUID of the lower
+filesystem, are encoded and stored in the "trusted.overlay.origin" extended
+attribute on the upper layer root directory. On subsequent mount attempts,
+the lower root directory file handle and lower filesystem UUID are compared
+to the stored origin in upper root directory. On failure to verify the
+lower root origin, mount will fail with ESTALE. An overlayfs mount with
+"inodes index" enabled will fail with EOPNOTSUPP if the lower filesystem
+does not support NFS export, lower filesystem does not have a valid UUID or
+if the upper filesystem does not support extended attributes.
+
+It is quite a common practice to copy overlay layers to a different
+directory tree on the same or different underlying filesystem, and even
+to a different machine. With the "inodes index" feature, trying to mount
+the copied layers will fail the verification of the lower root file handle.
+
+
Non-standard behavior
---------------------
--
2.7.4
^ permalink raw reply related [flat|nested] 4+ messages in thread
end of thread, other threads:[~2017-06-22 10:18 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-06-21 12:28 [PATCH v4 00/25] Overlayfs inodes index Amir Goldstein
2017-06-21 17:02 ` Amir Goldstein
2017-06-21 20:03 ` Amir Goldstein
2017-06-22 10:18 ` [PATCH v4 26/25] ovl: document copying layers restrictions with " Amir Goldstein
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).