1. 26 1月, 2014 2 次提交
  2. 11 11月, 2013 1 次提交
    • C
      f2fs: issue more large discard command · 29e59c14
      Changman Lee 提交于
      o Changes from v1
        Use find_next(_zero)_bit suggested by jg.kim
      
      When f2fs issues discard command, if segment is contiguous,
      let's issue more large segment to gather adjacent segments.
      
      ** blktrace **
      179,1    0     5859    42.619023770   971  C   D 131072 + 2097152 [0]
      179,1    0    33665   108.840475468   971  C   D 2228224 + 2494464 [0]
      179,1    0    33671   109.131616427   971  C   D 14909440 + 344064 [0]
      179,1    0    33677   109.137100677   971  C   D 15261696 + 4096 [0]
      Signed-off-by: NChangman Lee <cm224.lee@samsung.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk.kim@samsung.com>
      29e59c14
  3. 08 11月, 2013 2 次提交
  4. 06 11月, 2013 1 次提交
  5. 04 11月, 2013 1 次提交
  6. 31 10月, 2013 1 次提交
  7. 30 10月, 2013 2 次提交
  8. 29 10月, 2013 3 次提交
  9. 28 10月, 2013 3 次提交
  10. 25 10月, 2013 8 次提交
  11. 22 10月, 2013 3 次提交
  12. 18 10月, 2013 5 次提交
  13. 08 10月, 2013 2 次提交
    • J
      f2fs: fix writing incorrect orphan blocks · ccaaca25
      Jaegeuk Kim 提交于
      Previously, there was a erroneous scenario like below.
      thread 1:                       thread 2:
       f2fs_unlink
        - acquire_orphan_inode
          : sbi->n_orphans++           write_checkpoint
                                       - block_operations
                                        : f2fs_lock_all
                                       - do_checkpoint
                                        : write orphan blocks with sbi->n_orphans
                                       - unblock_operations
        - f2fs_lock_op
        - release_orphan_inode
        - f2fs_unlock_op
      
      During the checkpoint by thread 2, f2fs stores a wrong orphan block according
      to the wrong sbi->n_orphans.
      To avoid this, simply we should make cover acquire_orphan_inode too with
      f2fs_lock_op.
      Signed-off-by: NJaegeuk Kim <jaegeuk.kim@samsung.com>
      ccaaca25
    • J
      f2fs: avoid unnecessary checkpoints · 5887d291
      Jaegeuk Kim 提交于
      During the f2fs_put_super procedure, we don't need to conduct checkpoint all
      the time, since we don't need to do that if superblock is clean.
      Signed-off-by: NJaegeuk Kim <jaegeuk.kim@samsung.com>
      5887d291
  14. 07 10月, 2013 2 次提交
    • K
      f2fs: handle remount options correctly · 4058c511
      Kelly Anderson 提交于
      The current f2fs code errors if the xattr or acl options are passed when
      remounting.  This is important in a typical scenario where f2fs is mounted
      as a "ro" root file-system by the boot loader and then the init process wants
      to remount it "rw" with the "remount,rw" option.
      Signed-off-by: NKelly Anderson <kelly@xilka.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk.kim@samsung.com>
      4058c511
    • G
      f2fs: use rw_sem instead of fs_lock(locks mutex) · e479556b
      Gu Zheng 提交于
      The fs_locks is used to block other ops(ex, recovery) when doing checkpoint.
      And each other operate routine(besides checkpoint) needs to acquire a fs_lock,
      there is a terrible problem here, if these are too many concurrency threads acquiring
      fs_lock, so that they will block each other and may lead to some performance problem,
      but this is not the phenomenon we want to see.
      Though there are some optimization patches introduced to enhance the usage of fs_lock,
      but the thorough solution is using a *rw_sem* to replace the fs_lock.
      Checkpoint routine takes write_sem, and other ops take read_sem, so that we can block
      other ops(ex, recovery) when doing checkpoint, and other ops will not disturb each other,
      this can avoid the problem described above completely.
      Because of the weakness of rw_sem, the above change may introduce a potential problem
      that the checkpoint thread might get starved if other threads are intensively locking
      the read semaphore for I/O.(Pointed out by Xu Jin)
      In order to avoid this, a wait_list is introduced, the appending read semaphore ops
      will be dropped into the wait_list if checkpoint thread is waiting for write semaphore,
      and will be waked up when checkpoint thread gives up write semaphore.
      Thanks to Kim's previous review and test, and will be very glad to see other guys'
      performance tests about this patch.
      
      V2:
        -fix the potential starvation problem.
        -use more suitable func name suggested by Xu Jin.
      Signed-off-by: NGu Zheng <guz.fnst@cn.fujitsu.com>
      [Jaegeuk Kim: adjust minor coding standard]
      Signed-off-by: NJaegeuk Kim <jaegeuk.kim@samsung.com>
      e479556b
  15. 25 9月, 2013 4 次提交