1. 05 2月, 2019 1 次提交
  2. 27 12月, 2018 5 次提交
  3. 14 12月, 2018 1 次提交
  4. 27 11月, 2018 3 次提交
  5. 23 10月, 2018 2 次提交
  6. 17 10月, 2018 2 次提交
    • C
      f2fs: use rb_*_cached friends · 4dada3fd
      Chao Yu 提交于
      As rbtree supports caching leftmost node natively, update f2fs codes
      to use rb_*_cached helpers to speed up leftmost node visiting.
      Signed-off-by: NChao Yu <yuchao0@huawei.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      4dada3fd
    • D
      f2fs: checkpoint disabling · 4354994f
      Daniel Rosenberg 提交于
      Note that, it requires "f2fs: return correct errno in f2fs_gc".
      
      This adds a lightweight non-persistent snapshotting scheme to f2fs.
      
      To use, mount with the option checkpoint=disable, and to return to
      normal operation, remount with checkpoint=enable. If the filesystem
      is shut down before remounting with checkpoint=enable, it will revert
      back to its apparent state when it was first mounted with
      checkpoint=disable. This is useful for situations where you wish to be
      able to roll back the state of the disk in case of some critical
      failure.
      Signed-off-by: NDaniel Rosenberg <drosen@google.com>
      [Jaegeuk Kim: use SB_RDONLY instead of MS_RDONLY]
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      4354994f
  7. 01 10月, 2018 2 次提交
  8. 29 9月, 2018 1 次提交
  9. 20 9月, 2018 1 次提交
  10. 13 9月, 2018 1 次提交
  11. 06 9月, 2018 4 次提交
    • J
      f2fs: avoid wrong decrypted data from disk · 0ded69f6
      Jaegeuk Kim 提交于
      1. Create a file in an encrypted directory
      2. Do GC & drop caches
      3. Read stale data before its bio for metapage was not issued yet
      Reviewed-by: NChao Yu <yuchao0@huawei.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      0ded69f6
    • C
      Revert "f2fs: use printk_ratelimited for f2fs_msg" · 22d7ea13
      Chao Yu 提交于
      Don't limit printing log, so that we will not miss any key messages.
      
      This reverts commit a36c106d.
      
      In addition, we use printk_ratelimited to avoid too many log prints.
      - error injection
      - discard submission failure
      Signed-off-by: NChao Yu <yuchao0@huawei.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      22d7ea13
    • S
      f2fs: fix unnecessary periodic wakeup of discard thread when dev is busy · abde73c7
      Sahitya Tummala 提交于
      When dev is busy, discard thread wake up timeout can be aligned with the
      exact time that it needs to wait for dev to come out of busy. This helps
      to avoid unnecessary periodic wakeups and thus save some power.
      Signed-off-by: NSahitya Tummala <stummala@codeaurora.org>
      Reviewed-by: NChao Yu <yuchao0@huawei.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      abde73c7
    • C
      f2fs: fix to avoid NULL pointer dereference on se->discard_map · 7d20c8ab
      Chao Yu 提交于
      https://bugzilla.kernel.org/show_bug.cgi?id=200951
      
      These is a NULL pointer dereference issue reported in bugzilla:
      
      Hi,
      in the setup there is a SATA SSD connected to a SATA-to-USB bridge.
      
      The disc is "Samsung SSD 850 PRO 256G" which supports TRIM.
      There are four partitions:
       sda1: FAT  /boot
       sda2: F2FS /
       sda3: F2FS /home
       sda4: F2FS
      
      The bridge is ASMT1153e which uses the "uas" driver.
      There is no TRIM pass-through, so, when mounting it reports:
       mounting with "discard" option, but the device does not support discard
      
      The USB host is USB3.0 and UASP capable. It is the one on RK3399.
      
      Given this everything works fine, except there is no TRIM support.
      
      In order to enable TRIM a new UDEV rule is added [1]:
       /etc/udev/rules.d/10-sata-bridge-trim.rules:
       ACTION=="add|change", ATTRS{idVendor}=="174c", ATTRS{idProduct}=="55aa", SUBSYSTEM=="scsi_disk", ATTR{provisioning_mode}="unmap"
      After reboot any F2FS write hangs forever and dmesg reports:
       Unable to handle kernel NULL pointer dereference
      
      Also tested on a x86_64 system: works fine even with TRIM enabled.
       same disc
       same bridge
       different usb host controller
       different cpu architecture
       not root filesystem
      
      Regards,
        Vicenç.
      
      [1] Post #5 in https://bbs.archlinux.org/viewtopic.php?id=236280
      
       Unable to handle kernel NULL pointer dereference at virtual address 000000000000003e
       Mem abort info:
         ESR = 0x96000004
         Exception class = DABT (current EL), IL = 32 bits
         SET = 0, FnV = 0
         EA = 0, S1PTW = 0
       Data abort info:
         ISV = 0, ISS = 0x00000004
         CM = 0, WnR = 0
       user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000626e3122
       [000000000000003e] pgd=0000000000000000
       Internal error: Oops: 96000004 [#1] SMP
       Modules linked in: overlay snd_soc_hdmi_codec rc_cec dw_hdmi_i2s_audio dw_hdmi_cec snd_soc_simple_card snd_soc_simple_card_utils snd_soc_rockchip_i2s rockchip_rga snd_soc_rockchip_pcm rockchipdrm videobuf2_dma_sg v4l2_mem2mem rtc_rk808 videobuf2_memops analogix_dp videobuf2_v4l2 videobuf2_common dw_hdmi dw_wdt cec rc_core videodev drm_kms_helper media drm rockchip_thermal rockchip_saradc realtek drm_panel_orientation_quirks syscopyarea sysfillrect sysimgblt fb_sys_fops dwmac_rk stmmac_platform stmmac pwm_bl squashfs loop crypto_user gpio_keys hid_kensington
       CPU: 5 PID: 957 Comm: nvim Not tainted 4.19.0-rc1-1-ARCH #1
       Hardware name: Sapphire-RK3399 Board (DT)
       pstate: 00000005 (nzcv daif -PAN -UAO)
       pc : update_sit_entry+0x304/0x4b0
       lr : update_sit_entry+0x108/0x4b0
       sp : ffff00000ca13bd0
       x29: ffff00000ca13bd0 x28: 000000000000003e
       x27: 0000000000000020 x26: 0000000000080000
       x25: 0000000000000048 x24: ffff8000ebb85cf8
       x23: 0000000000000253 x22: 00000000ffffffff
       x21: 00000000000535f2 x20: 00000000ffffffdf
       x19: ffff8000eb9e6800 x18: ffff8000eb9e6be8
       x17: 0000000007ce6926 x16: 000000001c83ffa8
       x15: 0000000000000000 x14: ffff8000f602df90
       x13: 0000000000000006 x12: 0000000000000040
       x11: 0000000000000228 x10: 0000000000000000
       x9 : 0000000000000000 x8 : 0000000000000000
       x7 : 00000000000535f2 x6 : ffff8000ebff3440
       x5 : ffff8000ebff3440 x4 : ffff8000ebe3a6c8
       x3 : 00000000ffffffff x2 : 0000000000000020
       x1 : 0000000000000000 x0 : ffff8000eb9e5800
       Process nvim (pid: 957, stack limit = 0x0000000063a78320)
       Call trace:
        update_sit_entry+0x304/0x4b0
        f2fs_invalidate_blocks+0x98/0x140
        truncate_node+0x90/0x400
        f2fs_remove_inode_page+0xe8/0x340
        f2fs_evict_inode+0x2b0/0x408
        evict+0xe0/0x1e0
        iput+0x160/0x260
        do_unlinkat+0x214/0x298
        __arm64_sys_unlinkat+0x3c/0x68
        el0_svc_handler+0x94/0x118
        el0_svc+0x8/0xc
       Code: f9400800 b9488400 36080140 f9400f01 (387c4820)
       ---[ end trace a0f21a307118c477 ]---
      
      The reason is it is possible to enable discard flag on block queue via
      UDEV, but during mount, f2fs will initialize se->discard_map only if
      this flag is set, once the flag is set after mount, f2fs may dereference
      NULL pointer on se->discard_map.
      
      So this patch does below changes to fix this issue:
      - initialize and update se->discard_map all the time.
      - don't clear DISCARD option if device has no QUEUE_FLAG_DISCARD flag
      during mount.
      - don't issue small discard on zoned block device.
      - introduce some functions to enhance the readability.
      Signed-off-by: NChao Yu <yuchao0@huawei.com>
      Tested-by: NVicente Bergas <vicencb@gmail.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      7d20c8ab
  12. 21 8月, 2018 3 次提交
    • C
      f2fs: readahead encrypted block during GC · 6aa58d8a
      Chao Yu 提交于
      During GC, for each encrypted block, we will read block synchronously
      into meta page, and then submit it into current cold data log area.
      
      So this block read model with 4k granularity can make poor performance,
      like migrating non-encrypted block, let's readahead encrypted block
      as well to improve migration performance.
      
      To implement this, we choose meta page that its index is old block
      address of the encrypted block, and readahead ciphertext into this
      page, later, if readaheaded page is still updated, we will load its
      data into target meta page, and submit the write IO.
      
      Note that for OPU, truncation, deletion, we need to invalid meta
      page after we invalid old block address, to make sure we won't load
      invalid data from target meta page during encrypted block migration.
      
      for ((i = 0; i < 1000; i++))
      do {
              xfs_io -f /mnt/f2fs/dir/$i -c "pwrite 0 128k" -c "fsync";
      } done
      
      for ((i = 0; i < 1000; i+=2))
      do {
              rm /mnt/f2fs/dir/$i;
      } done
      
      ret = ioctl(fd, F2FS_IOC_GARBAGE_COLLECT, 0);
      
      Before:
                    gc-6549  [001] d..1 214682.212797: block_rq_insert: 8,32 RA 32768 () 786400 + 64 [gc]
                    gc-6549  [001] d..1 214682.212802: block_unplug: [gc] 1
                    gc-6549  [001] .... 214682.213892: block_bio_queue: 8,32 R 67494144 + 8 [gc]
                    gc-6549  [001] .... 214682.213899: block_getrq: 8,32 R 67494144 + 8 [gc]
                    gc-6549  [001] .... 214682.213902: block_plug: [gc]
                    gc-6549  [001] d..1 214682.213905: block_rq_insert: 8,32 R 4096 () 67494144 + 8 [gc]
                    gc-6549  [001] d..1 214682.213908: block_unplug: [gc] 1
                    gc-6549  [001] .... 214682.226405: block_bio_queue: 8,32 R 67494152 + 8 [gc]
                    gc-6549  [001] .... 214682.226412: block_getrq: 8,32 R 67494152 + 8 [gc]
                    gc-6549  [001] .... 214682.226414: block_plug: [gc]
                    gc-6549  [001] d..1 214682.226417: block_rq_insert: 8,32 R 4096 () 67494152 + 8 [gc]
                    gc-6549  [001] d..1 214682.226420: block_unplug: [gc] 1
                    gc-6549  [001] .... 214682.226904: block_bio_queue: 8,32 R 67494160 + 8 [gc]
                    gc-6549  [001] .... 214682.226910: block_getrq: 8,32 R 67494160 + 8 [gc]
                    gc-6549  [001] .... 214682.226911: block_plug: [gc]
                    gc-6549  [001] d..1 214682.226914: block_rq_insert: 8,32 R 4096 () 67494160 + 8 [gc]
                    gc-6549  [001] d..1 214682.226916: block_unplug: [gc] 1
      
      After:
                    gc-5678  [003] .... 214327.025906: block_bio_queue: 8,32 R 67493824 + 8 [gc]
                    gc-5678  [003] .... 214327.025908: block_bio_backmerge: 8,32 R 67493824 + 8 [gc]
                    gc-5678  [003] .... 214327.025915: block_bio_queue: 8,32 R 67493832 + 8 [gc]
                    gc-5678  [003] .... 214327.025917: block_bio_backmerge: 8,32 R 67493832 + 8 [gc]
                    gc-5678  [003] .... 214327.025923: block_bio_queue: 8,32 R 67493840 + 8 [gc]
                    gc-5678  [003] .... 214327.025925: block_bio_backmerge: 8,32 R 67493840 + 8 [gc]
                    gc-5678  [003] .... 214327.025932: block_bio_queue: 8,32 R 67493848 + 8 [gc]
                    gc-5678  [003] .... 214327.025934: block_bio_backmerge: 8,32 R 67493848 + 8 [gc]
                    gc-5678  [003] .... 214327.025941: block_bio_queue: 8,32 R 67493856 + 8 [gc]
                    gc-5678  [003] .... 214327.025943: block_bio_backmerge: 8,32 R 67493856 + 8 [gc]
                    gc-5678  [003] .... 214327.025953: block_bio_queue: 8,32 R 67493864 + 8 [gc]
                    gc-5678  [003] .... 214327.025955: block_bio_backmerge: 8,32 R 67493864 + 8 [gc]
                    gc-5678  [003] .... 214327.025962: block_bio_queue: 8,32 R 67493872 + 8 [gc]
                    gc-5678  [003] .... 214327.025964: block_bio_backmerge: 8,32 R 67493872 + 8 [gc]
                    gc-5678  [003] .... 214327.025970: block_bio_queue: 8,32 R 67493880 + 8 [gc]
                    gc-5678  [003] .... 214327.025972: block_bio_backmerge: 8,32 R 67493880 + 8 [gc]
                    gc-5678  [003] .... 214327.026000: block_bio_queue: 8,32 WS 34123776 + 2048 [gc]
                    gc-5678  [003] .... 214327.026019: block_getrq: 8,32 WS 34123776 + 2048 [gc]
                    gc-5678  [003] d..1 214327.026021: block_rq_insert: 8,32 R 131072 () 67493632 + 256 [gc]
                    gc-5678  [003] d..1 214327.026023: block_unplug: [gc] 1
                    gc-5678  [003] d..1 214327.026026: block_rq_issue: 8,32 R 131072 () 67493632 + 256 [gc]
                    gc-5678  [003] .... 214327.026046: block_plug: [gc]
      Signed-off-by: NChao Yu <yuchao0@huawei.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      6aa58d8a
    • J
      f2fs: avoid fi->i_gc_rwsem[WRITE] lock in f2fs_gc · 6f8d4455
      Jaegeuk Kim 提交于
      The f2fs_gc() called by f2fs_balance_fs() requires to be called outside of
      fi->i_gc_rwsem[WRITE], since f2fs_gc() can try to grab it in a loop.
      
      If it hits the miximum retrials in GC, let's give a chance to release
      gc_mutex for a short time in order not to go into live lock in the worst
      case.
      Reviewed-by: NChao Yu <yuchao0@huawei.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      6f8d4455
    • J
      f2fs: fix performance issue observed with multi-thread sequential read · 853137ce
      Jaegeuk Kim 提交于
      This reverts the commit - "b93f7712 - f2fs: remove writepages lock"
      to fix the drop in sequential read throughput.
      
      Test: ./tiotest -t 32 -d /data/tio_tmp -f 32 -b 524288 -k 1 -k 3 -L
      device: UFS
      
      Before -
      read throughput: 185 MB/s
      total read requests: 85177 (of these ~80000 are 4KB size requests).
      total write requests: 2546 (of these ~2208 requests are written in 512KB).
      
      After -
      read throughput: 758 MB/s
      total read requests: 2417 (of these ~2042 are 512KB reads).
      total write requests: 2701 (of these ~2034 requests are written in 512KB).
      Signed-off-by: NSahitya Tummala <stummala@codeaurora.org>
      Reviewed-by: NChao Yu <yuchao0@huawei.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      853137ce
  13. 15 8月, 2018 1 次提交
    • A
      f2fs: rework fault injection handling to avoid a warning · 7fa750a1
      Arnd Bergmann 提交于
      When CONFIG_F2FS_FAULT_INJECTION is disabled, we get a warning about an
      unused label:
      
      fs/f2fs/segment.c: In function '__submit_discard_cmd':
      fs/f2fs/segment.c:1059:1: error: label 'submit' defined but not used [-Werror=unused-label]
      
      This could be fixed by adding another #ifdef around it, but the more
      reliable way of doing this seems to be to remove the other #ifdefs
      where that is easily possible.
      
      By defining time_to_inject() as a trivial stub, most of the checks for
      CONFIG_F2FS_FAULT_INJECTION can go away. This also leads to nicer
      formatting of the code.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Reviewed-by: NChao Yu <yuchao0@huawei.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      7fa750a1
  14. 14 8月, 2018 5 次提交
    • C
      f2fs: fix to return success when trimming meta area · 3f16ecd9
      Chao Yu 提交于
      generic/251
          --- tests/generic/251.out	2016-05-03 20:20:11.381899000 +0800
           QA output created by 251
           Running the test: done.
          +fstrim: /mnt/scratch_f2fs: FITRIM ioctl failed: Invalid argument
          +fstrim: /mnt/scratch_f2fs: FITRIM ioctl failed: Invalid argument
          +fstrim: /mnt/scratch_f2fs: FITRIM ioctl failed: Invalid argument
          +fstrim: /mnt/scratch_f2fs: FITRIM ioctl failed: Invalid argument
          +fstrim: /mnt/scratch_f2fs: FITRIM ioctl failed: Invalid argument
          ...
      Ran: generic/251
      Failures: generic/251
      
      The reason is coverage of fstrim locates in meta area, previously we
      just return -EINVAL for such case, making generic/251 failed, to fix
      this problem, let's relieve restriction to return success with no
      block discarded.
      Signed-off-by: NChao Yu <yuchao0@huawei.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      3f16ecd9
    • C
      f2fs: fix use-after-free of dicard command entry · 6b9cb124
      Chao Yu 提交于
      As Dan Carpenter reported:
      
      The patch 20ee4382: "f2fs: issue small discard by LBA order" from
      Jul 8, 2018, leads to the following Smatch warning:
      
      	fs/f2fs/segment.c:1277 __issue_discard_cmd_orderly()
      	warn: 'dc' was already freed.
      
      See also:
      fs/f2fs/segment.c:2550 __issue_discard_cmd_range() warn: 'dc' was already freed.
      
      In order to fix this issue, let's get error from __submit_discard_cmd(),
      and release current discard command after we referenced next one.
      Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NChao Yu <yuchao0@huawei.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      6b9cb124
    • C
      f2fs: support discard submission error injection · b83dcfe6
      Chao Yu 提交于
      This patch adds to support discard submission error injection for testing
      error handling of __submit_discard_cmd().
      Signed-off-by: NChao Yu <yuchao0@huawei.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      b83dcfe6
    • C
      f2fs: split discard command in prior to block layer · 35ec7d57
      Chao Yu 提交于
      Some devices has small max_{hw,}discard_sectors, so that in
      __blkdev_issue_discard(), one big size discard bio can be split
      into multiple small size discard bios, result in heavy load in IO
      scheduler and device, which can hang other sync IO for long time.
      
      Now, f2fs is trying to control discard commands more elaboratively,
      in order to make less conflict in between discard IO and user IO
      to enhance application's performance, so in this patch, we will
      split discard bio in f2fs in prior to in block layer to reduce
      issuing multiple discard bios in a short time.
      Signed-off-by: NChao Yu <yuchao0@huawei.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      35ec7d57
    • C
      f2fs: fix incorrect range->len in f2fs_trim_fs() · 6eae2694
      Chao Yu 提交于
      generic/260 reported below error:
      
           [+] Default length with start set (should succeed)
           [+] Length beyond the end of fs (should succeed)
           [+] Length beyond the end of fs with start set (should succeed)
          +./tests/generic/260: line 94: [: 18446744073709551615: integer expression expected
          +./tests/generic/260: line 104: [: 18446744073709551615: integer expression expected
           Test done
          ...
      
      In f2fs_trim_fs(), if there is no discard being trimmed, we need to correct
      range->len before return.
      Signed-off-by: NChao Yu <yuchao0@huawei.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      6eae2694
  15. 02 8月, 2018 7 次提交
    • C
      f2fs: let checkpoint flush dnode page of regular · fd8c8caf
      Chao Yu 提交于
      Fsyncer will wait on all dnode pages of regular writeback before flushing,
      if there are async dnode pages blocked by IO scheduler, it may decrease
      fsync's performance.
      
      In this patch, we choose to let f2fs_balance_fs_bg() to trigger checkpoint
      to flush these dnode pages of regular, so async IO of dnode page can be
      elimitnated, making fsyncer only need to wait for sync IO.
      Signed-off-by: NChao Yu <yuchao0@huawei.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      fd8c8caf
    • Y
      f2fs: issue discard align to section in LFS mode · ad6672bb
      Yunlong Song 提交于
      For the case when sbi->segs_per_sec > 1 with lfs mode, take
      section:segment = 5 for example, if the section prefree_map is
      ...previous section | current section (1 1 0 1 1) | next section...,
      then the start = x, end = x + 1, after start = start_segno +
      sbi->segs_per_sec, start = x + 5, then it will skip x + 3 and x + 4, but
      their bitmap is still set, which will cause duplicated
      f2fs_issue_discard of this same section in the next write_checkpoint:
      
      round 1: section bitmap : 1 1 1 1 1, all valid, prefree_map: 0 0 0 0 0
      then rm data block NO.2, block NO.2 becomes invalid, prefree_map: 0 0 1 0 0
      write_checkpoint: section bitmap: 1 1 0 1 1, prefree_map: 0 0 0 0 0,
      prefree of NO.2 is cleared, and no discard issued
      
      round 2: rm data block NO.0, NO.1, NO.3, NO.4
      all invalid, but prefree bit of NO.2 is set and cleared in round 1, then
      prefree_map: 1 1 0 1 1
      write_checkpoint: section bitmap: 0 0 0 0 0, prefree_map: 0 0 0 1 1, no
      valid blocks of this section, so discard issued, but this time prefree
      bit of NO.3 and NO.4 is skipped due to start = start_segno + sbi->segs_per_sec;
      
      round 3:
      write_checkpoint: section bitmap: 0 0 0 0 0, prefree_map: 0 0 0 1 1 ->
      0 0 0 0 0, no valid blocks of this section, so discard issued,
      this time prefree bit of NO.3 and NO.4 is cleared, but the discard of
      this section is sent again...
      
      To fix this problem, we can align the start and end value to section
      boundary for fstrim and real-time discard operation, and decide to issue
      discard only when the whole section is invalid, which can issue discard
      aligned to section size as much as possible and avoid redundant discard.
      Signed-off-by: NYunlong Song <yunlong.song@huawei.com>
      Signed-off-by: NChao Yu <yuchao0@huawei.com>
      Reviewed-by: NChao Yu <yuchao0@huawei.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      ad6672bb
    • C
      f2fs: clean up with f2fs_is_{atomic,volatile}_file() · 2079f115
      Chao Yu 提交于
      Signed-off-by: NChao Yu <yuchao0@huawei.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      2079f115
    • C
      f2fs: fix to propagate error from __get_meta_page() · 7735730d
      Chao Yu 提交于
      If caller of __get_meta_page() can handle error, let's propagate error
      from __get_meta_page().
      Signed-off-by: NChao Yu <yuchao0@huawei.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      7735730d
    • C
      f2fs: issue small discard by LBA order · 20ee4382
      Chao Yu 提交于
      For small granularity discard which size is smaller than 64KB, if we
      issue those kind of discards orderly by size, their IOs will be spread
      into entire logical address, so that in FTL, L2P table will be updated
      randomly, result bad wear rate in the table.
      
      In this patch, we choose to issue small discard by LBA order, by this
      way, we can expect that L2P table updates from adjacent discard IOs can
      be merged in the cache, so it can reduce lifetime wearing of flash.
      Signed-off-by: NChao Yu <yuchao0@huawei.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      20ee4382
    • C
      f2fs: stop issuing discard immediately if there is queued IO · 522d1711
      Chao Yu 提交于
      For background discard policy, even if there is queued user IO, still
      we will check max_requests times for next discard entry, it is unneeded,
      let's just stop this round submission immediately.
      Signed-off-by: NChao Yu <yuchao0@huawei.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      522d1711
    • C
      f2fs: detect bug_on in f2fs_wait_discard_bios · 2482c432
      Chao Yu 提交于
      Add bug_on to detect potential non-empty discard wait list.
      Signed-off-by: NChao Yu <yuchao0@huawei.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      2482c432
  16. 27 7月, 2018 1 次提交