On Tue, Sep 12, 2017 at 01:36:48PM -0400, Austin S. Hemmelgarn wrote: > On 2017-09-12 13:21, Adam Borowski wrote: > > There's fallocate -d, but that for some reason touches mtime which makes > > rsync go again. This can be handled manually but is still not nice.
> It touches mtime because it updates the block allocations, which in turn > touch ctime, which on most (possibly all, not sure though) POSIX systems > implies an mtime update. It's essentially the same as truncate updating the > mtime when you extend the file, the only difference is that the > FALLOCATE_PUNCH_HOLES ioctl doesn't change the file size. Yeah, the underlying ioctl does modify the file, it's merely fallocate -d calling it on regions that are already zero. The ioctl doesn't know that, so fallocate would have to restore the mtime by itself. There's also another problem: such a check + ioctl are racey. Unlike defrag or FILE_EXTENT_SAME, you can't thus use it on a file that's in use (or could suddenly become in use). Fixing this would need kernel support, either as FILE_EXTENT_SAME with /dev/zero or as a new mode of fallocate. For now, though, I wonder -- should we send fine folks at util-linux a patch to make fallocate -d restore mtime, either always or on an option? Meow! -- ⢀⣴⠾⠻⢶⣦⠀ I've read an article about how lively happy music boosts ⣾⠁⢰⠒⠀⣿⡁ productivity. You can read it, too, you just need the ⢿⡄⠘⠷⠚⠋⠀ right music while doing so. I recommend Skepticism ⠈⠳⣄⠀⠀⠀⠀ (funeral doom metal). -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
