On Tue, Aug 9, 2016 at 7:16 AM, Austin S. Hemmelgarn <ahferro...@gmail.com> wrote: > On 2016-08-09 05:50, MegaBrutal wrote: >> >> 2016-06-03 14:43 GMT+02:00 Austin S. Hemmelgarn <ahferro...@gmail.com>: >>> >>> >>> Also, since you're on a new enough kernel, try 'lazytime' in the mount >>> options as well, this defers all on-disk timestamp updates for up to 24 >>> hours or until the inode gets written out anyway, but keeps the updated info >>> in memory. The only downside to this is that mtimes might not be correct >>> after an unclean shutdown, but most software will have no issues with this. >>> >> >> Hi all, >> >> Sorry for reviving this old thread, and probably it's not the best >> place to ask about this... but I added the "noatime" option in fstab, >> restarted the system, and now I think I should try "lazytime" too (as >> I like the idea to have proper atimes with delayed writing to disk). >> So now I'd just like to test the "lazytime" mount option without >> restart. >> >> I remounted the file system like this: >> >> mount -o remount,lazytime / >> >> But now the FS still has the "noatime" mount option, which I guess >> renders "lazytime" ineffective. I thought they are supposed to be >> mutually exclusive, so I'm actually surprised that I can have both >> mount options at the same time. > > No, lazytime also affects mtime handling, not just atime, so they aren't > mutually exclusive, and it does make sense to have both. >> >> >> Now my mount looks like this: >> >> /dev/mapper/centrevg-rootlv on / type btrfs >> (rw,noatime,lazytime,space_cache,subvolid=257,subvol=/@) >> >> I also tried to explicitly add "atime" to negate "noatime" (man mount >> says "atime" is the option to disable "noatime"), like this: >> >> mount -o remount,atime,lazytime / >> >> But the "noatime" option still stays. Why? Is it a BTRFS specific >> issue, or does it reside in another layer? >> >> By the way, is it valid to mount BTRFS subvolumes with different atime >> policies? Then how do child subvolumes behave? > > I'm not entirely certain (I have my kernel patched so noatime is the > default, and rarely if ever use anything else, so I don't have much in the > way of experience with this), but my guess would be that it can't be done, > and that changing atime handling on remount isn't really handled. I do know > that adding lazytime on remount doesn't always work, but that kind of makes > sense, since it causes significant changes in how mtimes and atimes are > handled internally. >
TLDR: try 'mount -o remount,strictatime / && mount -o remount,relatime /' This seems strange, but on my unpatched system: $ uname -r 4.7.0 $ mount -o loop,noatime,lazytime /var/tmp/test.dd /mnt $ grep ^/dev/loop0 /proc/mounts /dev/loop0 /mnt btrfs rw,lazytime,noatime,space_cache,subvolid=5,subvol=/ 0 0 $ mount -o remount,relatime /mnt $ grep ^/dev/loop0 /proc/mounts /dev/loop0 /mnt btrfs rw,lazytime,noatime,space_cache,subvolid=5,subvol=/ 0 0 ^^^ No change to noatime option $ mount -o remount,strictatime /mnt $ grep ^/dev/loop0 /proc/mounts /dev/loop0 /mnt btrfs rw,lazytime,space_cache,subvolid=5,subvol=/ 0 0 ^^^ that updated it... $ mount -o remount,relatime /mnt $ grep ^/dev/loop0 /proc/mounts /dev/loop0 /mnt btrfs rw,lazytime,relatime,space_cache,subvolid=5,subvol=/ 0 0 ^^^ now it changes ~ Noah -- 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
