lkml.org 
[lkml]   [2014]   [May]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH 00/13] overlay filesystem v22
    Date

    Thanks for CC-ing me.

    Here are some comments.

    - I have no objection about the 0:0 char-dev whiteout, but you don't
    have to have the inode for each whiteout. The hardlink is better.
    In this version, you have <workdir> now. How about creating a "base"
    whiteout under workdir at the mount-time? Maybe it is possible by
    user-space "mount.overlayfs" or kernel-space. When the whiteout meets
    EMLINK, create a non-hardlink for that target synchronously and
    re-create the "base" asynchronously.

    - Is <workdir>/work always visible to users? If a user accidentally
    removes it or its children, then some operations will fail. And he
    cannot recover it anymore. I know it cannot easily happen since its
    mode is 0. But I am afraid it will be a source of troubles. For
    example, find(1) or "ls -R /overlayfs" will almost always fail.

    - If I remember correctly, the length of the dir mutex is held time has
    been pointed out. This version has still a long mutex held time, a whole
    copy-up operation includeing lookup, create, copy filedata, copy
    xattr/attr, and then rename. How about unlock the dir before copying
    filedata and re-lock and confirm after copying attr?

    - When two processes copy-up a similar dir hierarcy, for example
    /dirA/dirB/fileC and /dirA/dirB/dirC/fileD, may a race condition
    happen? Two processes begin copying-up dirA, first processA succeeds
    it and second processB fails and returns EIO?

    - All copy-up operations will be serialized due to <workdir> lock.

    - In fstat(2) for a dir, is nlink set to 1 even it is removed?

    - In readdir, it lookup or getattr to determine whether the found char
    dev entry is a whiteout or not. I know a char dev is not so many, so
    this overhead won't be large. But if its name represented "I am a
    whiteout", then the extra lookup or getattr would be unnecessary.


    My personal impression for overall is overlayfs starts growing.
    Also several parts look like towarding aufs. For example,
    - a <workdir> means an overlayfs specific work. Aufs has such special
    dir for copying-up an unlinked file and a pseudo-link. Both are
    unnecessary for overlayfs because overlayfs copies-up a file in
    open(2) time, and doesn't support the hardlink between layers.
    - many small wrapper functions for VFS helpers resemble to aufs
    too. In aufs, all they have lockdep_off/on.
    - the internal cache for readdir allocating extra memory. Aufs adopts
    a simple hashing, while overlayfs uses rbtree.

    But of course the fundamental design differences between overlayfs and
    aufs are kept, such as
    - a name-based union .vs. an inode-aware union
    - multiple layers
    - allow users to access the layers directly
    - etc...

    If LKML people consider merging overlayfs, then I'd ask to consier aufs
    too. The basic design is unchanged since when I posted a few years ago.
    http://marc.info/?l=linux-kernel&m=123934927611907&w=2

    And latest one is
    http://aufs.sourceforge.net


    J. R. Okajima


    \
     
     \ /
      Last update: 2014-05-26 04:41    [W:4.411 / U:0.364 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site