Re: [GIT PULL] overlayfs update for 4.14

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Sep 15, 2017 at 9:32 AM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
> On Thu, Sep 14, 2017 at 01:24:22PM -0700, Linus Torvalds wrote:
>
>> I just don't see any reason why those two "flags" arguments are separate.
>
> Fine.  Here's a patch reverting the new flags and adding O_UPPER.

And, btw. I also hate all the hacks we need to do in the VFS for the
sake of overlayfs.  It may actually end up all being removed and all
the stacking moved to overlayfs; that's something I'd really like to
look at.   All of these hacks are there because overlayfs lets the
open file be owned by the underlying filesystem, which is good for
performance and results in simpler code in overlayfs, but may not
actually be worth it.

The whole overlayfs thing started because I was looking at the union
mounts patches and seeing all the horrid vfs impacts and deciding,
that surely some of this can go into a filesystem without major loss
of performance.   The first versions had really minimal vfs impact,
but it turned out that that wasn't enough for a bunch of things to
work correctly so d_real() evolved into the beast it is now.

And we still have that issue with an fd opened for read-only and then
one opened for write, resulting in a copy-up, modification, and the
read-only fd still seeing the old data (union mounts had the same
issue, BTW).   So we need more hacks or some way to have a shared page
cache that's breakable on copy up, which does not look trivial at all.

Thanks,
Miklos



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux