On Wed, Jan 9, 2019 at 4:24 AM Jean-Pierre André <jean-pierre.an...@wanadoo.fr> wrote: > There are no recent changes in the trimming code, so you can > keep the version from Tuxera used by arch, or the latest code > from the repository on > https://sourceforge.net/p/ntfs-3g/ntfs-3g/ci/edge/tree/ > For a test build, you may want to use the basic sequence > without installing (and without disturbing your environment) > ./configure > make > Just use the script src/ntfs-3g for mounting. > Note : from the repository you first have to generate the > ./configure by running ./autogen.sh If you are more familiar > with the arch building procedure, you probably do not have > to make any change to it.
Sounds good. I went ahead and used the repo with your patch, without installing. Thanks for the link. > This is the correct procedure, just replace ntfs-3g by > src/ntfs-3g (src being the directory used for compiling), > and no need to use both ntfs-3g and lowntfs-3g : the log > has shown the error was issued by ntfs-3g. > > Also the strace is probably not useful any more. > > Attached is a patch to help understanding the issue, with > a more precise logging, and without stopping if a lower > level returns an error. The aim here is to determine if the > error has something to do with thin provisioning. For this > to be meaningful, you need to create a file and remove it > before trimming, for instance : > dd if=/dev/random of=/tmp/ntfs/random-data bs=16384 count=64 > rm /tmp/ntfs/random-data > (using bs=16384 reduces the size of log). > > Maybe a test without thin provisioning would be useful. > Jean-Pierre Good call for a non-thin test. That succeeds. Having the volume be thin appears to cause a "fstrim: discard granularity of backing device is larger than cluster size". Thin log: https://termbin.com/6org Non-thin (still through LVM) log: https://termbin.com/dn3u Not in the logs, but I ran more tests modifying the error message to include discard_granularity and vol->cluster_size. On a thin volume, 65536 and 4096. On a thick volume, 512 and 4096. Looks like those are from /sys/dev/block/<major>:<minor>/queue/discard_granularity, which are as expected 512 and 65536 for thick and thin LVM volumes. Doing some looking, I ran across a patch for the kernel's drivers/scsi/sd.c which discusses block layer rounding and aligning, devices that guarantee zeros after discard, and if the block layer leaves parts of the requested block range out, that it could lead to data corruption. It also discusses that dm thinp is unable to deal with partial discard blocks, and they work around the problem by setting the granularity to match the logical block size when LBPRZ (guaranteed zeros after discard) is enabled. Link: https://patchwork.kernel.org/patch/7614861/ --- This was later fixed by a patch, because it had a typo causing discard granularity to be sent to 1: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/scsi/sd.c?id=f4327a95dd080ed6aecb185478a88ce1ee4fa3c4 /queue/discard_zeroes_data for thin or thick LVM volumes, at least on my setup, is showing 0. I'm not sure if LVM ever guarantees zeros after discard. There is a volume attribute for zeroing, but at least in "man lvs" that's documented in notes:8 as "Newly-allocated data blocks are overwritten with blocks of (z)eroes before use", so nothing to do with after discard. /queue/minimum_io_size is 65536 for thin, 512 for thick. I found a thread regarding a problem of that scsi patch here: https://www.spinics.net/lists/linux-scsi/msg106824.html Going to be away for about 12 hours. Not sure if the proper fix is if discard_granularity > vol->cluster_size, to look for aligned blocks of size discard_granularity where all clusters within it are discardable. My initial thought was if discard_zeroes_data was 0, perhaps vol->cluster_size could be used instead, but the scsi patch notes did say "dm thinp is unable to deal with partial discard blocks", if that's still true. Maybe looking at how another fs handles this, like btrfs, would be helpful. It's at https://github.com/torvalds/linux/blob/master/fs/btrfs/ioctl.c line 490, "btrfs_ioctl_fitrim()". _______________________________________________ ntfs-3g-devel mailing list ntfs-3g-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
