1. 13 8月, 2013 35 次提交
  2. 31 7月, 2013 1 次提交
  3. 25 7月, 2013 1 次提交
    • D
      xfs: di_flushiter considered harmful · e60896d8
      Dave Chinner 提交于
      When we made all inode updates transactional, we no longer needed
      the log recovery detection for inodes being newer on disk than the
      transaction being replayed - it was redundant as replay of the log
      would always result in the latest version of the inode would be on
      disk. It was redundant, but left in place because it wasn't
      considered to be a problem.
      
      However, with the new "don't read inodes on create" optimisation,
      flushiter has come back to bite us. Essentially, the optimisation
      made always initialises flushiter to zero in the create transaction,
      and so if we then crash and run recovery and the inode already on
      disk has a non-zero flushiter it will skip recovery of that inode.
      As a result, log recovery does the wrong thing and we end up with a
      corrupt filesystem.
      
      Because we have to support old kernel to new kernel upgrades, we
      can't just get rid of the flushiter support in log recovery as we
      might be upgrading from a kernel that doesn't have fully transactional
      inode updates.  Unfortunately, for v4 superblocks there is no way to
      guarantee that log recovery knows about this fact.
      
      We cannot add a new inode format flag to say it's a "special inode
      create" because it won't be understood by older kernels and so
      recovery could do the wrong thing on downgrade. We cannot specially
      detect the combination of zero mode/non-zero flushiter on disk to
      non-zero mode, zero flushiter in the log item during recovery
      because wrapping of the flushiter can result in false detection.
      
      Hence that makes this "don't use flushiter" optimisation limited to
      a disk format that guarantees that we don't need it. And that means
      the only fix here is to limit the "no read IO on create"
      optimisation to version 5 superblocks....
      Reported-by: NMarkus Trippelsdorf <markus@trippelsdorf.de>
      Signed-off-by: NDave Chinner <dchinner@redhat.com>
      Reviewed-by: NMark Tinguely <tinguely@sgi.com>
      Signed-off-by: NBen Myers <bpm@sgi.com>
      e60896d8
  4. 23 7月, 2013 3 次提交
    • C
      xfs: Start using pquotaino from the superblock. · d892d586
      Chandra Seetharaman 提交于
      Start using pquotino and define a macro to check if the
      superblock has pquotino.
      
      Keep backward compatibilty by alowing mount of older superblock
      with no separate pquota inode.
      Signed-off-by: NChandra Seetharaman <sekharan@us.ibm.com>
      Reviewed-by: NBen Myers <bpm@sgi.com>
      Signed-off-by: NBen Myers <bpm@sgi.com>
      d892d586
    • C
      xfs: Initialize all quota inodes to be NULLFSINO · 01026297
      Chandra Seetharaman 提交于
      mkfs doesn't initialize the quota inodes to NULLFSINO as it does for the
      other internal inodes. This leads to two in-core values (0 and NULLFSINO)
      to be checked against, to make sure if a quota inode is valid.
      
      Solve that problem by initializing the in-core values of all quotaino
      values to NULLFSINO if they are 0 in the disk.
      
      Note that these values are not written back to on-disk superblock unless
      some quota is enabled on the filesystem. Even in that case sb_pquotino is
      written to disk only if the on-disk superblock supports pquotino
      Signed-off-by: NChandra Seetharaman <sekharan@us.ibm.com>
      Reviewed-by: NBen Myers <bpm@sgi.com>
      Signed-off-by: NBen Myers <bpm@sgi.com>
      01026297
    • C
      xfs: Fix a deadlock in xfs_log_commit_cil() code path · 297aa637
      Chandra Seetharaman 提交于
      While testing and rearranging pquota/gquota code, I stumbled
      on a xfs_shutdown() during a mount. But the mount just hung.
      
      Debugged and found that there is a deadlock involving
      &log->l_cilp->xc_ctx_lock.
      
      It is in a code path where &log->l_cilp->xc_ctx_lock is first
      acquired in read mode and some levels down the same semaphore
      is being acquired in write mode causing a deadlock.
      
      This is the stack:
      xfs_log_commit_cil -> acquires &log->l_cilp->xc_ctx_lock in read mode
        xlog_print_tic_res
          xfs_force_shutdown
            xfs_log_force_umount
              xlog_cil_force
                xlog_cil_force_lsn
                  xlog_cil_push_foreground
                    xlog_cil_push - tries to acquire same semaphore in write mode
      
      This patch fixes the deadlock by changing the reason code for
      xfs_force_shutdown in xlog_print_tic_res() to SHUTDOWN_LOG_IO_ERROR.
      
      SHUTDOWN_LOG_IO_ERROR is the right reason code to be set since
      we are in the log path.
      
      Thanks to Dave for suggesting this solution.
      Signed-off-by: NChandra Seetharaman <sekharan@us.ibm.com>
      Reviewed-by: NBen Myers <bpm@sgi.com>
      Signed-off-by: NBen Myers <bpm@sgi.com>
      297aa637