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. Thanks, Qu > > Attaching 'btrfs-debug -b /' to get an idea about the block groups present. > > >
Attachment:
signature.asc
Description: OpenPGP digital signature
