1. 16 9月, 2009 1 次提交
    • J
      ext3: Flush disk caches on fsync when needed · 56fcad29
      Jan Kara 提交于
      In case we fsync() a file and inode is not dirty, we don't force a transaction
      to disk and hence don't flush disk caches. Thus file data could be just in disk
      caches and not on persistent storage. Fix the problem by flushing disk caches
      if we didn't force a transaction commit.
      Signed-off-by: NJan Kara <jack@suse.cz>
      56fcad29
  2. 28 4月, 2008 1 次提交
    • H
      ext3: fdatasync should skip metadata writeout when overwriting · 3d61f75e
      Hisashi Hifumi 提交于
      Currently fdatasync is identical to fsync in ext3.
      
      I think fdatasync should skip journal flush in data=ordered and
      data=writeback mode when it overwrites to already-instantiated blocks on
      HDD.  When I_DIRTY_DATASYNC flag is not set, fdatasync should skip journal
      writeout because this indicates only atime or/and mtime updates.
      
      Following patch is the same approach of ext2's fsync code(ext2_sync_file).
      
      I did a performance test using the sysbench.
      
      #sysbench --num-threads=128 --max-requests=50000 --test=fileio --file-total-size=128G
      --file-test-mode=rndwr --file-fsync-mode=fdatasync run
      
      The result on ext3 was:
      
      	-2.6.24
      	Operations performed:  0 Read, 50080 Write, 59600 Other = 109680 Total
      	Read 0b  Written 782.5Mb  Total transferred 782.5Mb  (12.116Mb/sec)
      	  775.45 Requests/sec executed
      
      	Test execution summary:
      	    total time:                          64.5814s
      	    total number of events:              50080
      	    total time taken by event execution: 3713.9836
      	    per-request statistics:
      	         min:                            0.0000s
      	         avg:                            0.0742s
      	         max:                            0.9375s
      	         approx.  95 percentile:         0.2901s
      
      	Threads fairness:
      	    events (avg/stddev):           391.2500/23.26
      	    execution time (avg/stddev):   29.0155/1.99
      
      	-2.6.24-patched
      	Operations performed:  0 Read, 50009 Write, 61596 Other = 111605 Total
      	Read 0b  Written 781.39Mb  Total transferred 781.39Mb  (16.419Mb/sec)
      	1050.83 Requests/sec executed
      
      	Test execution summary:
      	    total time:                          47.5900s
      	    total number of events:              50009
      	    total time taken by event execution: 2934.5768
      	    per-request statistics:
       	         min:                            0.0000s
      	         avg:                            0.0587s
       	         max:                            0.8938s
      	         approx.  95 percentile:         0.1993s
      
      	Threads fairness:
      	    events (avg/stddev):           390.6953/22.64
      	    execution time (avg/stddev):   22.9264/1.17
      
      Filesystem I/O throughput was improved.
      
      Signed-off-by :Hisashi Hifumi <hifumi.hisashi@oss.ntt.co.jp>
      Acked-by: NJan Kara <jack@suse.cz>
      Cc: <linux-ext4@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3d61f75e
  3. 19 10月, 2007 1 次提交
  4. 27 9月, 2006 1 次提交
  5. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4