1. 16 Feb, 2015 2 commits
  2. 09 Feb, 2015 2 commits
  3. 05 Feb, 2015 4 commits
  4. 01 Feb, 2015 14 commits
  5. 21 Jan, 2015 10 commits
    • Brian Foster's avatar
      xfs: remove incorrect error negation in attr_multi ioctl · 4d949021
      Brian Foster authored
      xfs_compat_attrmulti_by_handle() calls memdup_user() which returns a
      negative error code. The error code is negated by the caller and thus
      incorrectly converted to a positive error code.
      
      Remove the error negation such that the negative error is passed
      correctly back up to userspace.
      Signed-off-by: default avatarBrian Foster <bfoster@redhat.com>
      Reviewed-by: default avatarDave Chinner <dchinner@redhat.com>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      4d949021
    • Dave Chinner's avatar
      438c3c8d
    • Dave Chinner's avatar
      xfs: set superblock buffer type correctly · 3443a3bc
      Dave Chinner authored
      When the superblock is modified in a transaction, the commonly
      modified fields are not actually copied to the superblock buffer to
      avoid the buffer lock becoming a serialisation point. However, there
      are some other operations that modify the superblock fields within
      the transaction that don't directly log to the superblock but rely
      on the changes to be applied during the transaction commit (to
      minimise the buffer lock hold time).
      
      When we do this, we fail to mark the buffer log item as being a
      superblock buffer and that can lead to the buffer not being marked
      with the corect type in the log and hence causing recovery issues.
      Fix it by setting the type correctly, similar to xfs_mod_sb()...
      
      cc: <stable@vger.kernel.org> # 3.10 to current
      Tested-by: default avatarJan Kara <jack@suse.cz>
      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>
      3443a3bc
    • Dave Chinner's avatar
      xfs: set buf types when converting extent formats · fe22d552
      Dave Chinner authored
      Conversion from local to extent format does not set the buffer type
      correctly on the new extent buffer when a symlink data is moved out
      of line.
      
      Fix the symlink code and leave a comment in the generic bmap code
      reminding us that the format-specific data copy needs to set the
      destination buffer type appropriately.
      
      cc: <stable@vger.kernel.org> # 3.10 to current
      Tested-by: default avatarJan Kara <jack@suse.cz>
      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>
      fe22d552
    • Dave Chinner's avatar
      xfs: inode unlink does not set AGI buffer type · f19b872b
      Dave Chinner authored
      This leads to log recovery throwing errors like:
      
      XFS (md0): Mounting V5 Filesystem
      XFS (md0): Starting recovery (logdev: internal)
      XFS (md0): Unknown buffer type 0!
      XFS (md0): _xfs_buf_ioapply: no ops on block 0xaea8802/0x1
      ffff8800ffc53800: 58 41 47 49 .....
      
      Which is the AGI buffer magic number.
      
      Ensure that we set the type appropriately in both unlink list
      addition and removal.
      
      cc: <stable@vger.kernel.org> # 3.10 to current
      Tested-by: default avatarJan Kara <jack@suse.cz>
      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>
      f19b872b
    • Dave Chinner's avatar
      xfs: ensure buffer types are set correctly · 0d612fb5
      Dave Chinner authored
      Jan Kara reported that log recovery was finding buffers with invalid
      types in them. This should not happen, and indicates a bug in the
      logging of buffers. To catch this, add asserts to the buffer
      formatting code to ensure that the buffer type is in range when the
      transaction is committed.
      
      We don't set a type on buffers being marked stale - they are not
      going to get replayed, the format item exists only for recovery to
      be able to prevent replay of the buffer, so the type does not
      matter. Hence that needs special casing here.
      
      cc: <stable@vger.kernel.org> # 3.10 to current
      Reported-by: default avatarJan Kara <jack@suse.cz>
      Tested-by: default avatarJan Kara <jack@suse.cz>
      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>
      0d612fb5
    • Dave Chinner's avatar
      Merge branch 'xfs-sb-logging-rework' into for-next · 465e2def
      Dave Chinner authored
      Conflicts:
      	fs/xfs/xfs_mount.c
      465e2def
    • Dave Chinner's avatar
      xfs: sanitise sb_bad_features2 handling · 074e427b
      Dave Chinner authored
      We currently have to ensure that every time we update sb_features2
      that we update sb_bad_features2. Now that we log and format the
      superblock in it's entirety we actually don't have to care because
      we can simply update the sb_bad_features2 when we format it into the
      buffer. This removes the need for anything but the mount and
      superblock formatting code to care about sb_bad_features2, and
      hence removes the possibility that we forget to update bad_features2
      when necessary in the future.
      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>
      074e427b
    • Dave Chinner's avatar
      xfs: consolidate superblock logging functions · 61e63ecb
      Dave Chinner authored
      We now have several superblock loggin functions that are identical
      except for the transaction reservation and whether it shoul dbe a
      synchronous transaction or not. Consolidate these all into a single
      function, a single reserveration and a sync flag and call it
      xfs_sync_sb().
      
      Also, xfs_mod_sb() is not really a modification function - it's the
      operation of logging the superblock buffer. hence change the name of
      it to reflect this.
      
      Note that we have to change the mp->m_update_flags that are passed
      around at mount time to a boolean simply to indicate a superblock
      update is needed.
      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>
      61e63ecb
    • Dave Chinner's avatar
      xfs: remove bitfield based superblock updates · 4d11a402
      Dave Chinner authored
      When we log changes to the superblock, we first have to write them
      to the on-disk buffer, and then log that. Right now we have a
      complex bitfield based arrangement to only write the modified field
      to the buffer before we log it.
      
      This used to be necessary as a performance optimisation because we
      logged the superblock buffer in every extent or inode allocation or
      freeing, and so performance was extremely important. We haven't done
      this for years, however, ever since the lazy superblock counters
      pulled the superblock logging out of the transaction commit
      fast path.
      
      Hence we have a bunch of complexity that is not necessary that makes
      writing the in-core superblock to disk much more complex than it
      needs to be. We only need to log the superblock now during
      management operations (e.g. during mount, unmount or quota control
      operations) so it is not a performance critical path anymore.
      
      As such, remove the complex field based logging mechanism and
      replace it with a simple conversion function similar to what we use
      for all other on-disk structures.
      
      This means we always log the entirity of the superblock, but again
      because we rarely modify the superblock this is not an issue for log
      bandwidth or CPU time. Indeed, if we do log the superblock
      frequently, delayed logging will minimise the impact of this
      overhead.
      
      [Fixed gquota/pquota inode sharing regression noticed by bfoster.]
      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>
      4d11a402
  6. 09 Jan, 2015 1 commit
  7. 08 Jan, 2015 7 commits