BUG relating to fstrim on btrfs partitions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I think I found a bug affecting btrfs filesystems and users invoking fstrim to discard unused blocks: if I execute a `fstrim -v /` twice, the amount trimmed does not change on the 2nd invocation AND it takes just as long as the first.  Why do I think this is a bug?  When I do the same on an ext4 partition I get different behavior: the output shows 0 B trimmed and it does is instantaneously when I run it a 2nd time.  After contacting the fstrim developer, he stated that the userspace part (fstrim) does only one thing and it is invoke an ioctl (FITRIM); it is the job of the filesystem to properly implement this.

Supporting data
----------------
Example on a btrfs partition:
The 1st time:
% time sudo fstrim -v /
/: 5.2 GiB (5575192576 bytes) trimmed
sudo fstrim -v /  0.00s user 0.05s system 2% cpu 2.084 total

The 2nd time:
% time sudo fstrim -v /
/: 5.2 GiB (5575192576 bytes) trimmed
sudo fstrim -v /  0.00s user 0.06s system 2% cpu 2.107 total

If I run the command twice on an ext4 filesystem, it does go to zero and the 2nd invocation is instantaneous:
The 1st time:
% time sudo fstrim -v /                   
/: 15.4 GiB (16481087488 bytes) trimmed
sudo fstrim -v /  0.00s user 0.08s system 1% cpu 6.268 total

The 2nd time:
% time sudo fstrim -v /
/: 0 B (0 bytes) trimmed
sudo fstrim -v /  0.00s user 0.00s system 48% cpu 0.007 total
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux