1. 09 Mar, 2019 8 commits
    • J. R. Okajima's avatar
      aufs: xino 1/2, core · 6fe05098
      J. R. Okajima authored
      
      
      XINO and XIB files are to maintain the inode numbers in aufs
      (cf. struct.txt and aufs manual in aufs-util.git).
      
      XINO file contains just a sequence of the inode numbers, and their
      offset in the file is real_inum x sizeof(inum).  So the size is limited
      by s_maxbytes of the filesystem where XINO file is located.  In order to
      support the larger inum, aufs stores XINO files as an internal array.
      
      Sometimes the size of XINO file can be a problem, ie. too big,
      particularly when XINO files are located on tmpfs. In this case, another
      separate patch tmpfs-ino.patch in aufs4-standalone.git is recommended
      (as well as vfs-ino.patch). The patch makes tmpfs to maintain inode
      number within itself and suppress its discontiguous distribution.
      
      See also the document in next commit.
      Signed-off-by: default avatarJ. R. Okajima <hooanon05g@gmail.com>
      6fe05098
    • J. R. Okajima's avatar
      aufs: workqueue · f04356cb
      J. R. Okajima authored
      
      
      Aufs uses the workqueue both synchronously and asynchronously.
      For sync-use-case, aufs uses its own specific wkq since doesn't want to
      be disturbed by other tasks on the system. For async-use-case, aufs uses
      the system global workqueue.
      Aufs has to prevent itself to being unmounted during the async-task is
      queued.
      
      See also the document in this commit.
      Signed-off-by: default avatarJ. R. Okajima <hooanon05g@gmail.com>
      f04356cb
    • J. R. Okajima's avatar
      aufs: readonly branch 2/2, callers · 66bc346d
      J. R. Okajima authored
      
      
      For details, see previous commit.
      Signed-off-by: default avatarJ. R. Okajima <hooanon05g@gmail.com>
      66bc346d
    • J. R. Okajima's avatar
      aufs: readonly branch 1/2, definition · b7051459
      J. R. Okajima authored
      
      
      The branch object is managed by the sbinfo object as an element of its
      internal array. The iinfo and dinfo objects contain the branch id, and
      it will be used to implement the correct order in branch management
      (add/del).
      
      See also the documents in this commit.
      Signed-off-by: default avatarJ. R. Okajima <hooanon05g@gmail.com>
      b7051459
    • J. R. Okajima's avatar
      aufs: infos generation 2/2 · f2ade007
      J. R. Okajima authored
      
      
      The generation of iinfo and dinfo inherit sbinfo's.
      Also iinfo generation tracks the branch inode's generation to test the
      matching after the branch management.
      Signed-off-by: default avatarJ. R. Okajima <hooanon05g@gmail.com>
      f2ade007
    • J. R. Okajima's avatar
      aufs: sbinfo core · 3742849b
      J. R. Okajima authored
      
      
      The structure is very similar to inode and dentry infos (in previous
      commits), but the internal array is for 'struct au_branch' instead of
      'superblock.' Additionally the lifetime of 'struct au_sbinfo' is managed
      by kobject since it will be connected to sysfs by later commit.
      Signed-off-by: default avatarJ. R. Okajima <hooanon05g@gmail.com>
      3742849b
    • J. R. Okajima's avatar
      aufs: dinfo core · ee166183
      J. R. Okajima authored
      
      
      The structure is very similar to aufs inode info (in previous commit).
      Signed-off-by: default avatarJ. R. Okajima <hooanon05g@gmail.com>
      ee166183
    • J. R. Okajima's avatar
      aufs: iinfo core · a3d2caf2
      J. R. Okajima authored
      
      
      See the documents in this commit.
      Signed-off-by: default avatarJ. R. Okajima <hooanon05g@gmail.com>
      a3d2caf2