On Sun, Nov 28, 2021 at 11:19:50PM +0800, Eryu Guan wrote: > On Mon, Nov 22, 2021 at 05:08:10PM -0500, Josef Bacik wrote: > > We have always failed generic/260, because it tests to see if the file > > system will reject a trim range that is above the reported fs size. > > However for btrfs we will happily remap logical byte offsets within the > > file system, so you can end up with bye offsets past the end of the > > reported end of the file system. Thus we do not fail these weird > > ranges. We also don't have the concept of allocation groups, so the > > other test that tries to catch overflow doesn't apply to us either. Fix > > this by simply using an offset that will fail (once a related kernel > > path is applied) for btrfs. This will allow us to test the different > > overflow cases that do apply to btrfs, and not muddy up test results by > > giving us a false negative for the cases that do not apply to btrfs. > > > > Signed-off-by: Josef Bacik <josef@xxxxxxxxxxxxxx> > > I'd like an ACK from btrfs folks as well. Ack.
