On 2016-08-09 05:50, MegaBrutal wrote:
2016-06-03 14:43 GMT+02:00 Austin S. Hemmelgarn <ahferroin7@xxxxxxxxx>:
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.
--
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