On 2018年04月01日 11:28, Chris Murphy wrote: > On Mon, Nov 20, 2017 at 11:10 PM, Qu Wenruo <quwenruo.btrfs@xxxxxxx> wrote: >> >> >> On 2017年11月21日 13:58, Chris Murphy wrote: >>> On Mon, Nov 20, 2017 at 9:58 PM, Qu Wenruo <quwenruo.btrfs@xxxxxxx> wrote: >>>> >>>> >>>> On 2017年11月21日 12:49, Chris Murphy wrote: >>>>> On Mon, Nov 20, 2017 at 9:43 PM, Qu Wenruo <quwenruo.btrfs@xxxxxxx> wrote: >>>>>> >>>>>> >>>>>>> >>>>>>> Apply in addition to previous patch? Or apply to clean v4.14? >>>>>> >>>>>> On previous patch. >>>>> >>>>> Refuses to apply with or without previous patch. >>>>> >>>>> $ git apply -v ~/qufstrim3.patch >>>>> Checking patch fs/btrfs/extent-tree.c... >>>>> error: while searching for: >>>>> int dev_ret = 0; >>>>> int ret = 0; >>>>> >>>>> /* >>>>> * try to trim all FS space, our block group may start from non-zero. >>>>> */ >>>>> >>>>> error: patch failed: fs/btrfs/extent-tree.c:10972 >>>>> error: fs/btrfs/extent-tree.c: patch does not apply >>>>> >>>> >>>> Please try this branch. >>>> >>>> It's just previous patch and diff merged together and applied on v4.14 >>>> tag from torvalds. >>>> >>>> https://github.com/adam900710/linux/tree/tmp >>> >>> # fstrim -v / >>> /: 38 GiB (40767586304 bytes) trimmed >>> # dmesg >>> >>> ..snip... >>> [ 46.408792] BTRFS info (device nvme0n1p8): trimming btrfs, start=0 >>> len=75161927680 minlen=512 >>> [ 46.408800] BTRFS info (device nvme0n1p8): bg start=140882477056 >>> len=1073741824 >>> [ 46.433867] BTRFS info (device nvme0n1p8): trimming done >> >> Great (for the output, not for the trimming failure). >> >> And the problem is very obvious now. >> 140882477056 << First chunk start >> 75161927680 << length of fstrim_range passed in >> >> Obviously, fstrim_range passed in is using the filesystem size it >> assumes to be. >> >> While we stupidly use the range in fstrim_range without considering the >> fact that, we're dealing with *btrfs logical address space*. >> Where our chunk can start from any bytenr (well, at least aligned with >> sectorsize). >> When I read the code I also think the range check has nothing wrong at all. >> >> So the truth here is, we should not ever try to check the range from >> fstrim_range. >> >> And the problem means that, a normal btrfs with some usage and after >> several full balance, fstrim will only trim the unallocated space for btrfs. >> >> Now the fix should not be a hard to craft. >> >> Great thanks for all your help to locate the problem. > > I still see this problem in 4.16.0-0.rc7.git1.1.fc29.x86_64. Are there > any patches to test? > > [chris@f27h mnt]$ sudo btrfs fi us / > Overall: > Device size: 70.00GiB > Device allocated: 60.06GiB > Device unallocated: 9.94GiB > Device missing: 0.00B > Used: 36.89GiB > Free (estimated): 29.75GiB (min: 24.78GiB) > Data ratio: 1.00 > Metadata ratio: 1.00 > Global reserve: 107.77MiB (used: 12.38MiB) > > Data,single: Size:55.00GiB, Used:35.19GiB > /dev/nvme0n1p9 55.00GiB > > Metadata,single: Size:5.00GiB, Used:1.70GiB > /dev/nvme0n1p9 5.00GiB > > System,DUP: Size:32.00MiB, Used:16.00KiB > /dev/nvme0n1p9 64.00MiB > > Unallocated: > /dev/nvme0n1p9 9.94GiB > [chris@f27h mnt]$ sudo fstrim -v / > [sudo] password for chris: > /: 10 GiB (10669260800 bytes) trimmed The latest version is here https://patchwork.kernel.org/patch/10078773/ https://patchwork.kernel.org/patch/10083979/ And I didn't see it in misc-next either, I may need to ping it soon. Thanks, Qu
Attachment:
signature.asc
Description: OpenPGP digital signature
