1. 15 Dec, 2015 1 commit
  2. 14 Dec, 2015 2 commits
  3. 09 Dec, 2015 1 commit
  4. 04 Dec, 2015 4 commits
  5. 22 Oct, 2015 1 commit
  6. 13 Oct, 2015 1 commit
    • Chao Yu's avatar
      f2fs crypto: fix racing of accessing encrypted page among · 08b39fbd
      Chao Yu authored
      
      
       different competitors
      
      Since we use different page cache (normally inode's page cache for R/W
      and meta inode's page cache for GC) to cache the same physical block
      which is belong to an encrypted inode. Writeback of these two page
      cache should be exclusive, but now we didn't handle writeback state
      well, so there may be potential racing problem:
      
      a)
      kworker:				f2fs_gc:
       - f2fs_write_data_pages
        - f2fs_write_data_page
         - do_write_data_page
          - write_data_page
           - f2fs_submit_page_mbio
      (page#1 in inode's page cache was queued
      in f2fs bio cache, and be ready to write
      to new blkaddr)
      					 - gc_data_segment
      					  - move_encrypted_block
      					   - pagecache_get_page
      					(page#2 in meta inode's page cache
      					was cached with the invalid datas
      					of physical block located in new
      					blkaddr)
      					   - f2fs_submit_page_mbio
      					(page#1 was submitted, later, page#2
      					with invalid data will be submitted)
      
      b)
      f2fs_gc:
       - gc_data_segment
        - move_encrypted_block
         - f2fs_submit_page_mbio
      (page#1 in meta inode's page cache was
      queued in f2fs bio cache, and be ready
      to write to new blkaddr)
      					user thread:
      					 - f2fs_write_begin
      					  - f2fs_submit_page_bio
      					(we submit the request to block layer
      					to update page#2 in inode's page cache
      					with physical block located in new
      					blkaddr, so here we may read gabbage
      					data from new blkaddr since GC hasn't
      					writebacked the page#1 yet)
      
      This patch fixes above potential racing problem for encrypted inode.
      Signed-off-by: default avatarChao Yu <chao2.yu@samsung.com>
      Signed-off-by: default avatarJaegeuk Kim <jaegeuk@kernel.org>
      08b39fbd
  7. 12 Oct, 2015 3 commits
  8. 09 Oct, 2015 7 commits
  9. 26 Aug, 2015 1 commit
    • Chao Yu's avatar
      f2fs: update extent tree in batches · 19b2c30d
      Chao Yu authored
      
      
      This patch introduce a new helper f2fs_update_extent_tree_range which can
      do extent mapping update at a specified range.
      
      The main idea is:
      1) punch all mapping info in extent node(s) which are at a specified range;
      2) try to merge new extent mapping with adjacent node, or failing that,
         insert the mapping into extent tree as a new node.
      
      In order to see the benefit, I add a function for stating time stamping
      count as below:
      
      uint64_t rdtsc(void)
      {
      	uint32_t lo, hi;
      	__asm__ __volatile__ ("rdtsc" : "=a" (lo), "=d" (hi));
      	return (uint64_t)hi << 32 | lo;
      }
      
      My test environment is: ubuntu, intel i7-3770, 16G memory, 256g micron ssd.
      
      truncation path:	update extent cache from truncate_data_blocks_range
      non-truncataion path:	update extent cache from other paths
      total:			all update paths
      
      a) Removing 128MB file which has one extent node mapping whole range of
      file:
      1. dd if=/dev/zero of=/mnt/f2fs/128M bs=1M count=128
      2. sync
      3. rm /mnt/f2fs/128M
      
      Before:
      		total		count		average
      truncation:	7651022		32768		233.49
      
      Patched:
      		total		count		average
      truncation:	3321		33		100.64
      
      b) fsstress:
      fsstress -d /mnt/f2fs -l 5 -n 100 -p 20
      Test times:		5 times.
      
      Before:
      		total		count		average
      truncation:	5812480.6	20911.6		277.95
      non-truncation:	7783845.6	13440.8		579.12
      total:		13596326.2	34352.4		395.79
      
      Patched:
      		total		count		average
      truncation:	1281283.0	3041.6		421.25
      non-truncation:	7355844.4	13662.8		538.38
      total:		8637127.4	16704.4		517.06
      
      1) For the updates in truncation path:
       - we can see updating in batches leads total tsc and update count reducing
         explicitly;
       - besides, for a single batched updating, punching multiple extent nodes
         in a loop, result in executing more operations, so our average tsc
         increase intensively.
      2) For the updates in non-truncation path:
       - there is a little improvement, that is because for the scenario that we
         just need to update in the head or tail of extent node, new interface
         optimize to update info in extent node directly, rather than removing
         original extent node for updating and then inserting that updated one
         into cache as new node.
      Signed-off-by: default avatarChao Yu <chao2.yu@samsung.com>
      Signed-off-by: default avatarJaegeuk Kim <jaegeuk@kernel.org>
      19b2c30d
  10. 24 Aug, 2015 1 commit
  11. 20 Aug, 2015 1 commit
  12. 10 Aug, 2015 1 commit
  13. 05 Aug, 2015 5 commits
  14. 04 Aug, 2015 3 commits
    • Chao Yu's avatar
      f2fs: warm up cold page after mmaped write · 5b339124
      Chao Yu authored
      
      
      With cost-benifit method, background gc will consider old section with
      fewer valid blocks as candidate victim, these old blocks in section will
      be treated as cold data, and laterly will be moved into cold segment.
      
      But if the gcing page is attached by user through buffered or mmaped
      write, we should reset the page as non-cold one, because this page may
      have more opportunity for further updating.
      
      So fix to add clearing code for the missed 'mmap' case.
      Signed-off-by: default avatarChao Yu <chao2.yu@samsung.com>
      Signed-off-by: default avatarJaegeuk Kim <jaegeuk@kernel.org>
      5b339124
    • Chao Yu's avatar
      f2fs: add new ioctl F2FS_IOC_GARBAGE_COLLECT · c1c1b583
      Chao Yu authored
      
      
      When background gc is off, the only way to trigger gc is executing
      a force gc in some operations who wants to grab space in disk.
      
      The executing condition is limited: to execute force gc, we should
      wait for the time when there is almost no more free section for LFS
      allocation. This seems not reasonable for our user who wants to
      control triggering gc by himself.
      
      This patch introduces F2FS_IOC_GARBAGE_COLLECT interface for
      triggering garbage collection by using ioctl. It provides our users
      one more option to trigger gc.
      Signed-off-by: default avatarChao Yu <chao2.yu@samsung.com>
      Signed-off-by: default avatarJaegeuk Kim <jaegeuk@kernel.org>
      c1c1b583
    • Jaegeuk Kim's avatar
      f2fs: convert inline_data for various fallocate · 97a7b2c2
      Jaegeuk Kim authored
      
      
      For newly added fallocate types, it should convert inline_data before handling
      block swapping.
      Reviewed-by: default avatarChao Yu <chao2.yu@samsung.com>
      Signed-off-by: default avatarJaegeuk Kim <jaegeuk@kernel.org>
      97a7b2c2
  15. 25 Jul, 2015 1 commit
    • Jaegeuk Kim's avatar
      f2fs: call set_page_dirty to attach i_wb for cgroup · 6282adbf
      Jaegeuk Kim authored
      The cgroup attaches inode->i_wb via mark_inode_dirty and when set_page_writeback
      is called, __inc_wb_stat() updates i_wb's stat.
      
      So, we need to explicitly call set_page_dirty->__mark_inode_dirty in prior to
      any writebacking pages.
      
      This patch should resolve the following kernel panic reported by Andreas Reis.
      
      https://bugzilla.kernel.org/show_bug.cgi?id=101801
      
      --- Comment #2 from Andreas Reis <andreas.reis@gmail.com> ---
      BUG: unable to handle kernel NULL pointer dereference at 00000000000000a8
      IP: [<ffffffff8149deea>] __percpu_counter_add+0x1a/0x90
      PGD 2951ff067 PUD 2df43f067 PMD 0
      Oops: 0000 [#1] PREEMPT SMP
      Modules linked in:
      CPU: 7 PID: 10356 Comm: gcc Tainted: G        W       4.2.0-1-cu #1
      
      
      Hardware name: Gigabyte Technology Co., Ltd. G1.Sniper M5/G1.Sniper M5, BIOS
      T01 02/03/2015
      task: ffff880295044f80 ti: ffff880295140000 task.ti: ffff880295140000
      RIP: 0010:[<ffffffff8149deea>]  [<ffffffff8149deea>]
      __percpu_counter_add+0x1a/0x90
      RSP: 0018:ffff880295143ac8  EFLAGS: 00010082
      RAX: 0000000000000003 RBX: ffffea000a526d40 RCX: 0000000000000001
      RDX: 0000000000000020 RSI: 0000000000000001 RDI: 0000000000000088
      RBP: ffff880295143ae8 R08: 0000000000000000 R09: ffff88008f69bb30
      R10: 00000000fffffffa R11: 0000000000000000 R12: 0000000000000088
      R13: 0000000000000001 R14: ffff88041d099000 R15: ffff880084a205d0
      FS:  00007f8549374700(0000) GS:ffff88042f3c0000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00000000000000a8 CR3: 000000033e1d5000 CR4: 00000000001406e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Stack:
       0000000000000000 ffffea000a526d40 ffff880084a20738 ffff880084a20750
       ffff880295143b48 ffffffff811cc91e ffff880000000000 0000000000000296
       0000000000000000 ffff880417090198 0000000000000000 ffffea000a526d40
      Call Trace:
       [<ffffffff811cc91e>] __test_set_page_writeback+0xde/0x1d0
       [<ffffffff813fee87>] do_write_data_page+0xe7/0x3a0
       [<ffffffff813faeea>] gc_data_segment+0x5aa/0x640
       [<ffffffff813fb0b8>] do_garbage_collect+0x138/0x150
       [<ffffffff813fb3fe>] f2fs_gc+0x1be/0x3e0
       [<ffffffff81405541>] f2fs_balance_fs+0x81/0x90
       [<ffffffff813ee357>] f2fs_unlink+0x47/0x1d0
       [<ffffffff81239329>] vfs_unlink+0x109/0x1b0
       [<ffffffff8123e3d7>] do_unlinkat+0x287/0x2c0
       [<ffffffff8123ebc6>] SyS_unlink+0x16/0x20
       [<ffffffff81942e2e>] entry_SYSCALL_64_fastpath+0x12/0x71
      Code: 41 5e 5d c3 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 41 55 49
      89 f5 41 54 49 89 fc 53 48 83 ec 08 65 ff 05 e6 d9 b6 7e <48> 8b 47 20 48 63 ca
      65 8b 18 48 63 db 48 01 f3 48 39 cb 7d 0a
      RIP  [<ffffffff8149deea>] __percpu_counter_add+0x1a/0x90
       RSP <ffff880295143ac8>
      CR2: 00000000000000a8
      ---[ end trace 5132449a58ed93a3 ]---
      note: gcc[10356] exited with preempt_count 2
      Signed-off-by: default avatarJaegeuk Kim <jaegeuk@kernel.org>
      6282adbf
  16. 12 Jun, 2015 1 commit
    • Chao Yu's avatar
      f2fs: do not trim preallocated blocks when truncating after i_size · 3c454145
      Chao Yu authored
      
      
      When we perform generic/092 in xfstests, output is like below:
      
           XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
           0: [0..10239]: data
           0: [0..10239]: data
          -1: [10240..20479]: unwritten
          +1: [10240..14335]: unwritten
      
      This is because with this testcase, we redefine the regulation for
      truncate in perallocated space past i_size as below:
      
      "There was some confused about what the fs was supposed to do when you
      truncate at i_size with preallocated space past i_size. We decided on the
      following things.
      
      1) truncate(i_size) will trim all blocks past i_size.
      2) truncate(x) where x > i_size will not trim all blocks past i_size.
      "
      
      This method is used in xfs, and then ext4/btrfs will follow the rule.
      
      This patch fixes to follow the new rule for f2fs.
      Signed-off-by: default avatarChao Yu <chao2.yu@samsung.com>
      Signed-off-by: default avatarJaegeuk Kim <jaegeuk@kernel.org>
      3c454145
  17. 09 Jun, 2015 1 commit
  18. 08 Jun, 2015 1 commit
  19. 02 Jun, 2015 2 commits
    • Chao Yu's avatar
      f2fs: support FALLOC_FL_INSERT_RANGE · f62185d0
      Chao Yu authored
      FALLOC_FL_INSERT_RANGE flag for ->fallocate was introduced in commit
      dd46c787
      
       ("fs: Add support FALLOC_FL_INSERT_RANGE for fallocate").
      
      The effect of FALLOC_FL_INSERT_RANGE command is the opposite of
      FALLOC_FL_COLLAPSE_RANGE, if this command was performed, all data from
      offset to EOF in our file will be shifted to right as given length, and
      then range [offset, offset + length] becomes a hole.
      
      This command is useful for our user who wants to add some data in the
      middle of the file, for example: video/music editor will insert a keyframe
      in specified position of media file, with this command we can easily create
      a hole for inserting without removing original data.
      
      This patch introduces f2fs_insert_range() to support FALLOC_FL_INSERT_RANGE.
      Signed-off-by: default avatarChao Yu <chao2.yu@samsung.com>
      Signed-off-by: default avatarYuan Zhong <yuan.mark.zhong@samsung.com>
      Signed-off-by: default avatarJaegeuk Kim <jaegeuk@kernel.org>
      f62185d0
    • Chao Yu's avatar
      f2fs: hide common code in f2fs_replace_block · 528e3459
      Chao Yu authored
      
      
      This patch clean up codes through:
      1.rename f2fs_replace_block to __f2fs_replace_block().
      2.introduce new f2fs_replace_block() to include __f2fs_replace_block()
      and some common related codes around __f2fs_replace_block().
      
      Then, newly introduced function f2fs_replace_block can be used by
      following patch.
      Signed-off-by: default avatarChao Yu <chao2.yu@samsung.com>
      Signed-off-by: default avatarJaegeuk Kim <jaegeuk@kernel.org>
      528e3459
  20. 01 Jun, 2015 1 commit
  21. 28 May, 2015 1 commit