1. 22 Sep, 2016 2 commits
  2. 20 Jun, 2016 4 commits
  3. 05 Apr, 2016 3 commits
  4. 29 Feb, 2016 2 commits
  5. 09 Feb, 2016 4 commits
  6. 04 Jan, 2016 1 commit
    • Dave Chinner's avatar
      xfs: introduce per-inode DAX enablement · 58f88ca2
      Dave Chinner authored
      Rather than just being able to turn DAX on and off via a mount
      option, some applications may only want to enable DAX for certain
      performance critical files in a filesystem.
      This patch introduces a new inode flag to enable DAX in the v3 inode
      di_flags2 field. It adds support for setting and clearing flags in
      the di_flags2 field via the XFS_IOC_FSSETXATTR ioctl, and sets the
      S_DAX inode flag appropriately when it is seen.
      When this flag is set on a directory, it acts as an "inherit flag".
      That is, inodes created in the directory will automatically inherit
      the on-disk inode DAX flag, enabling administrators to set up
      directory heirarchies that automatically use DAX. Setting this flag
      on an empty root directory will make the entire filesystem use DAX
      by default.
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
  7. 30 Dec, 2015 1 commit
  8. 09 Dec, 2015 1 commit
    • Al Viro's avatar
      replace ->follow_link() with new method that could stay in RCU mode · 6b255391
      Al Viro authored
      new method: ->get_link(); replacement of ->follow_link().  The differences
      	* inode and dentry are passed separately
      	* might be called both in RCU and non-RCU mode;
      the former is indicated by passing it a NULL dentry.
      	* when called that way it isn't allowed to block
      and should return ERR_PTR(-ECHILD) if it needs to be called
      in non-RCU mode.
      It's a flagday change - the old method is gone, all in-tree instances
      converted.  Conversion isn't hard; said that, so far very few instances
      do not immediately bail out when called in RCU mode.  That'll change
      in the next commits.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
  9. 12 Oct, 2015 1 commit
    • Bill O'Donnell's avatar
      xfs: per-filesystem stats counter implementation · ff6d6af2
      Bill O'Donnell authored
      This patch modifies the stats counting macros and the callers
      to those macros to properly increment, decrement, and add-to
      the xfs stats counts. The counts for global and per-fs stats
      are correctly advanced, and cleared by writing a "1" to the
      corresponding clear file.
      global counts: /sys/fs/xfs/stats/stats
      per-fs counts: /sys/fs/xfs/sda*/stats/stats
      global clear:  /sys/fs/xfs/stats/stats_clear
      per-fs clear:  /sys/fs/xfs/sda*/stats/stats_clear
      [dchinner: cleaned up macro variables, removed CONFIG_FS_PROC around
       stats structures and macros. ]
      Signed-off-by: default avatarBill O'Donnell <billodo@redhat.com>
      Reviewed-by: default avatarEric Sandeen <sandeen@redhat.com>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
  10. 28 Aug, 2015 1 commit
  11. 04 Jun, 2015 2 commits
    • Christoph Hellwig's avatar
      xfs: saner xfs_trans_commit interface · 70393313
      Christoph Hellwig authored
      The flags argument to xfs_trans_commit is not useful for most callers, as
      a commit of a transaction without a permanent log reservation must pass
      0 here, and all callers for a transaction with a permanent log reservation
      except for xfs_trans_roll must pass XFS_TRANS_RELEASE_LOG_RES.  So remove
      the flags argument from the public xfs_trans_commit interfaces, and
      introduce low-level __xfs_trans_commit variant just for xfs_trans_roll
      that regrants a log reservation instead of releasing it.
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Reviewed-by: default avatarDave Chinner <dchinner@redhat.com>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
    • Christoph Hellwig's avatar
      xfs: remove the flags argument to xfs_trans_cancel · 4906e215
      Christoph Hellwig authored
      xfs_trans_cancel takes two flags arguments: XFS_TRANS_RELEASE_LOG_RES and
      XFS_TRANS_ABORT.  Both of them are a direct product of the transaction
      state, and can be deducted:
       - any dirty transaction needs XFS_TRANS_ABORT to be properly canceled,
         and XFS_TRANS_ABORT is a noop for a transaction that is not dirty.
       - any transaction with a permanent log reservation needs
         XFS_TRANS_RELEASE_LOG_RES to be properly canceled, and passing
         XFS_TRANS_RELEASE_LOG_RES for a transaction without a permanent
         log reservation is invalid.
      So just remove the flags argument and do the right thing.
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Reviewed-by: default avatarDave Chinner <dchinner@redhat.com>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
  12. 03 Jun, 2015 2 commits
  13. 11 May, 2015 2 commits
    • Al Viro's avatar
      don't pass nameidata to ->follow_link() · 6e77137b
      Al Viro authored
      its only use is getting passed to nd_jump_link(), which can obtain
      it from current->nameidata
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
    • Al Viro's avatar
      new ->follow_link() and ->put_link() calling conventions · 680baacb
      Al Viro authored
      a) instead of storing the symlink body (via nd_set_link()) and returning
      an opaque pointer later passed to ->put_link(), ->follow_link() _stores_
      that opaque pointer (into void * passed by address by caller) and returns
      the symlink body.  Returning ERR_PTR() on error, NULL on jump (procfs magic
      symlinks) and pointer to symlink body for normal symlinks.  Stored pointer
      is ignored in all cases except the last one.
      Storing NULL for opaque pointer (or not storing it at all) means no call
      of ->put_link().
      b) the body used to be passed to ->put_link() implicitly (via nameidata).
      Now only the opaque pointer is.  In the cases when we used the symlink body
      to free stuff, ->follow_link() now should store it as opaque pointer in addition
      to returning it.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
  14. 15 Apr, 2015 1 commit
  15. 13 Apr, 2015 1 commit
  16. 25 Mar, 2015 1 commit
    • Dave Chinner's avatar
      xfs: add RENAME_WHITEOUT support · 7dcf5c3e
      Dave Chinner authored
      Whiteouts are used by overlayfs -  it has a crazy convention that a
      whiteout is a character device inode with a major:minor of 0:0.
      Because it's not documented anywhere, here's an example of what
      RENAME_WHITEOUT does on ext4:
      # echo foo > /mnt/scratch/foo
      # echo bar > /mnt/scratch/bar
      # ls -l /mnt/scratch
      total 24
      -rw-r--r-- 1 root root     4 Feb 11 20:22 bar
      -rw-r--r-- 1 root root     4 Feb 11 20:22 foo
      drwx------ 2 root root 16384 Feb 11 20:18 lost+found
      # src/renameat2 -w /mnt/scratch/foo /mnt/scratch/bar
      # ls -l /mnt/scratch
      total 20
      -rw-r--r-- 1 root root     4 Feb 11 20:22 bar
      c--------- 1 root root  0, 0 Feb 11 20:23 foo
      drwx------ 2 root root 16384 Feb 11 20:18 lost+found
      # cat /mnt/scratch/bar
      In XFS rename terms, the operation that has been done is that source
      (foo) has been moved to the target (bar), which is like a nomal
      rename operation, but rather than the source being removed, it have
      been replaced with a whiteout.
      We can't allocate whiteout inodes within the rename transaction due
      to allocation being a multi-commit transaction: rename needs to
      be a single, atomic commit. Hence we have several options here, form
      most efficient to least efficient:
          - use DT_WHT in the target dirent and do no whiteout inode
            allocation.  The main issue with this approach is that we need
            hooks in lookup to create a virtual chardev inode to present
            to userspace and in places where we might need to modify the
            dirent e.g. unlink.  Overlayfs also needs to be taught about
            DT_WHT. Most invasive change, lowest overhead.
          - create a special whiteout inode in the root directory (e.g. a
            ".wino" dirent) and then hardlink every new whiteout to it.
            This means we only need to create a single whiteout inode, and
            rename simply creates a hardlink to it. We can use DT_WHT for
            these, though using DT_CHR means we won't have to modify
            overlayfs, nor anything in userspace. Downside is we have to
            look up the whiteout inode on every operation and create it if
            it doesn't exist.
          - copy ext4: create a special whiteout chardev inode for every
            whiteout.  This is more complex than the above options because
            of the lack of atomicity between inode creation and the rename
            operation, requiring us to create a tmpfile inode and then
            linking it into the directory structure during the rename. At
            least with a tmpfile inode crashes between the create and
            rename doesn't leave unreferenced inodes or directory
            pollution around.
      By far the simplest thing to do in the short term is to copy ext4.
      While it is the most inefficient way of supporting whiteouts, but as
      an initial implementation we can simply reuse existing functions and
      add a small amount of extra code the the rename operation.
      When we get full whiteout support in the VFS (via the dentry cache)
      we can then look to supporting DT_WHT method outlined as the first
      method of supporting whiteouts. But until then, we'll stick with
      what overlayfs expects us to be: dumb and stupid.
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
  17. 23 Feb, 2015 4 commits
    • Dave Chinner's avatar
      xfs: inodes are new until the dentry cache is set up · 58c90473
      Dave Chinner authored
      Al Viro noticed a generic set of issues to do with filehandle lookup
      racing with dentry cache setup. They involve a filehandle lookup
      occurring while an inode is being created and the filehandle lookup
      racing with the dentry creation for the real file. This can lead to
      multiple dentries for the one path being instantiated. There are a
      host of other issues around this same set of paths.
      The underlying cause is that file handle lookup only waits on inode
      cache instantiation rather than full dentry cache instantiation. XFS
      is mostly immune to the problems discovered due to it's own internal
      inode cache, but there are a couple of corner cases where races can
      We currently clear the XFS_INEW flag when the inode is fully set up
      after insertion into the cache. Newly allocated inodes are inserted
      locked and so aren't usable until the allocation transaction
      commits. This, however, occurs before the dentry and security
      information is fully initialised and hence the inode is unlocked and
      available for lookups to find too early.
      To solve the problem, only clear the XFS_INEW flag for newly created
      inodes once the dentry is fully instantiated. This means lookups
      will retry until the XFS_INEW flag is removed from the inode and
      hence avoids the race conditions in questions.
      THis also means that xfs_create(), xfs_create_tmpfile() and
      xfs_symlink() need to finish the setup of the inode in their error
      paths if we had allocated the inode but failed later in the creation
      process. xfs_symlink(), in particular, needed a lot of help to make
      it's error handling match that of xfs_create().
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarBrian Foster <bfoster@redhat.com>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
    • Dave Chinner's avatar
      xfs: ensure truncate forces zeroed blocks to disk · 5885ebda
      Dave Chinner authored
      A new fsync vs power fail test in xfstests indicated that XFS can
      have unreliable data consistency when doing extending truncates that
      require block zeroing. The blocks beyond EOF get zeroed in memory,
      but we never force those changes to disk before we run the
      transaction that extends the file size and exposes those blocks to
      userspace. This can result in the blocks not being correctly zeroed
      after a crash.
      Because in-memory behaviour is correct, tools like fsx don't pick up
      any coherency problems - it's not until the filesystem is shutdown
      or the system crashes after writing the truncate transaction to the
      journal but before the zeroed data in the page cache is flushed that
      the issue is exposed.
      Fix this by also flushing the dirty data in memory region between
      the old size and new size when we've found blocks that need zeroing
      in the truncate process.
      Reported-by: default avatarLiu Bo <bo.li.liu@oracle.com>
      cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarBrian Foster <bfoster@redhat.com>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
    • Dave Chinner's avatar
      xfs: xfs_setattr_size no longer races with page faults · 0f9160b4
      Dave Chinner authored
      Now that truncate locks out new page faults, we no longer need to do
      special writeback hacks in truncate to work around potential races
      between page faults, page cache truncation and file size updates to
      ensure we get write page faults for extending truncates on sub-page
      block size filesystems. Hence we can remove the code in
      xfs_setattr_size() that handles this and update the comments around
      the code tha thandles page cache truncate and size updates to
      reflect the new reality.
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarBrian Foster <bfoster@redhat.com>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
    • Dave Chinner's avatar
      xfs: take i_mmap_lock on extent manipulation operations · e8e9ad42
      Dave Chinner authored
      Now we have the i_mmap_lock being held across the page fault IO
      path, we now add extent manipulation operation exclusion by adding
      the lock to the paths that directly modify extent maps. This
      includes truncate, hole punching and other fallocate based
      operations. The operations will now take both the i_iolock and the
      i_mmaplock in exclusive mode, thereby ensuring that all IO and page
      faults block without holding any page locks while the extent
      manipulation is in progress.
      This gives us the lock order during truncate of i_iolock ->
      i_mmaplock -> page_lock -> i_lock, hence providing the same
      lock order as the iolock provides the normal IO path without
      involving the mmap_sem.
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarBrian Foster <bfoster@redhat.com>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
  18. 16 Feb, 2015 2 commits
  19. 23 Dec, 2014 2 commits
  20. 03 Dec, 2014 1 commit
  21. 28 Nov, 2014 2 commits