1. 15 May, 2012 9 commits
  2. 11 Apr, 2012 6 commits
    • Artem Bityutskiy's avatar
      ext2: do not register write_super within VFS · f72cf5e2
      Artem Bityutskiy authored
      Jan Kara removed 'sb->s_dirt' VFS flag references, so we do not need to
      register the ext2 'ext2_write_super()' method in the VFS superblock operations,
      because 'sb->s_dirt' won't be ever set to 1 and VFS won't ever call
      '->write_super()' anyway. Thus, remove the method.
      
      Tested using xfstests.
      Signed-off-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      f72cf5e2
    • Jan Kara's avatar
      ext2: Remove s_dirt handling · b838ec22
      Jan Kara authored
      Places which modify superblock feature / state fields mark the superblock
      buffer dirty so it is written out by flusher thread. Thus there's no need to
      set s_dirt there.
      
      The only other fields changing in the superblock are the numbers of free
      blocks, free inodes and s_wtime. There's no real need to write (or even
      compute) these periodically. Free blocks / inodes counters are recomputed on
      every mount from group counters anyway and value of s_wtime is only
      informational and imprecise anyway. So it should be enough to write these
      opportunistically on mount, remount, umount, and sync_fs times.
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      b838ec22
    • Artem Bityutskiy's avatar
      ext2: write superblock only once on unmount · f2b22420
      Artem Bityutskiy authored
      Currently on unmount if we are mounted R/W, we first write the superblock to
      the media if it is dirty, and then write it again, which is not optimal. This
      patch makes ext2 write the superblock on unmount less times.
      Signed-off-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      f2b22420
    • Stefan Hajnoczi's avatar
      ext3: update documentation with barrier=1 default · ee65244b
      Stefan Hajnoczi authored
      Commit 00eacd66 ("ext3: make ext3 mount default to barrier=1") changed
      the default barrier mount option for ext3.  The documentation needs to
      be updated, so this patch does that.
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarStefan Hajnoczi <stefanha@linux.vnet.ibm.com>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      ee65244b
    • Akira Fujita's avatar
      ext3: remove max_debt in find_group_orlov() · ac0dd247
      Akira Fujita authored
      max_debt, involved variables and calculations
      are no longer needed, clean them up.
      Signed-off-by: default avatarAkira Fujita <a-fujita@rs.jp.nec.com>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      ac0dd247
    • Jan Kara's avatar
      jbd: Refine commit writeout logic · 2db938be
      Jan Kara authored
      Currently we write out all journal buffers in WRITE_SYNC mode. This improves
      performance for fsync heavy workloads but hinders performance when writes
      are mostly asynchronous, most noticably it slows down readers and users
      complain about slow desktop response etc.
      
      So submit writes as asynchronous in the normal case and only submit writes as
      WRITE_SYNC if we detect someone is waiting for current transaction commit.
      
      I've gathered some numbers to back this change. The first is the read latency
      test. It measures time to read 1 MB after several seconds of sleeping in
      presence of streaming writes.
      
      Top 10 times (out of 90) in us:
      Before		After
      2131586		697473
      1709932		557487
      1564598		535642
      1480462		347573
      1478579		323153
      1408496		222181
      1388960		181273
      1329565		181070
      1252486		172832
      1223265		172278
      
      Average:
      619377		82180
      
      So the improvement in both maximum and average latency is massive.
      
      I've measured fsync throughput by:
      fs_mark -n 100 -t 1 -s 16384 -d /mnt/fsync/ -S 1 -L 4
      
      in presence of streaming reader. The numbers (fsyncs/s) are:
      Before		After
      9.9		6.3
      6.8		6.0
      6.3		6.2
      5.8		6.1
      
      So fsync performance seems unharmed by this change.
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      2db938be
  3. 10 Apr, 2012 8 commits
  4. 09 Apr, 2012 6 commits
  5. 08 Apr, 2012 1 commit
  6. 07 Apr, 2012 10 commits