Hi, Richard W.M. Jones wrote: > The following patch adds preliminary support for the FITRIM ioctl (as > used by the `fstrim' command). For those unfamiliar with this > command, it instructs the filesystem to send "TRIM" (aka "DISCARD") > requests for all unused areas of the filesystem. Usually this means > that the underlying device is able to release these blocks for other > uses -- commonly known as thin-provisioning. > > As I'm not very familiar with the ntfs-3g code, it would be good for > someone to check this over in detail, in case I've made some obvious > blunders. Some areas that I'm unclear about: > > - Can FUSE entry points be called from multiple threads? It is > unlikely that this code is thread safe.
This is not a new issue, ntfs-3g is not thread safe, and the multithreading capability of fuse cannot be used. > - Can we include <linux/fs.h> directly? You will note that I had to > add a rather ugly hack to make this work. This makes the code specific to Linux, and unfortunately I see no obvious way to avoid the hack. > - Does FUSE-lite get pulled in from FUSE? FUSE-lite does not appear > to support the ioctl entry point, whereas external FUSE does. At > the moment you must use external FUSE. fuse-lite was extracted from full fuse years ago, and only new features useful to ntfs-3g are ported now. I however expect ioctls can be added with minimal effort, and if so, I will add them. > - I did not add an ntfs_* operation for discarding. Instead this > code just calls ctx->vol->dev->d_ops->ioctl directly. > > There are some known shortcomings: > > - It does not support the fstrim range options -o/-l/-m. > > - I have only tested it on recent Linux with external FUSE. > - I see that you are trimming by clusters, though on a SSD trimming has to be done by blocks. This means a block is trimmed multiple times with multiple rewritings of the clusters in use... unless some lower level groups the requests for trimming. Trimming per cluster might also mean long delays for big devices. Assuming the actual block size is not available to the fs, I would trim per run of consecutive unallocated clusters, relying on a lower level to subdivide per block. - There is no need to read the full bitmap in a buffer which might be of unreasonable size. For allocating clusters, the bitmap is read in a 4K buffer. - Most of this code should be shared by ntfs-3g and lowntfs-3g. A specific file ioctl.c linked into libntfs-3g would be nice. > You can test this using a loopback device. For example: > > truncate -s1G /tmp/fs > mkntfs --force /tmp/fs > losetup -f /tmp/fs > mkdir /tmp/mnt > ./src/ntfs-3g -o no_detach,debug /dev/loop0 /tmp/mnt > > First of all notice that /tmp/fs starts off fully allocated (because > mkntfs writes zeroes over the whole disk): > > $ du -sh /tmp/fs > 1.1G /tmp/fs > > Now copy data to the filesystem and issue an fstrim command, and the > underlying loop file should become sparse: ... if the underlying fs supports a BLKDISCARD ioctl requests, which is not the case for NTFS... > > $ fstrim /tmp/mnt > $ du -sh /tmp/fs > 69M /tmp/fs > > (This test probably requires a recent kernel to work - I am testing > this with 3.16.0). > > Comments gladly received, > > Rich. I will be able to better check (and test) in a couple of weeks. Thank you for your contribution. Jean-Pierre ------------------------------------------------------------------------------ Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft _______________________________________________ ntfs-3g-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
