On 2018-08-19 06:25, Andrei Borzenkov wrote:
Отправлено с iPhone
19 авг. 2018 г., в 11:37, Martin Steigerwald <mar...@lichtvoll.de> написал(а):
waxhead - 18.08.18, 22:45:
Adam Hunt wrote:
Back in 2014 Ted Tso introduced the lazytime mount option for ext4
and shortly thereafter a more generic VFS implementation which was
then merged into mainline. His early patches included support for
Btrfs but those changes were removed prior to the feature being
merged. His>
changelog includes the following note about the removal:
- Per Christoph's suggestion, drop support for btrfs and xfs for
now,
issues with how btrfs and xfs handle dirty inode tracking. We
can add btrfs and xfs support back later or at the end of this
series if we want to revisit this decision.
My reading of the current mainline shows that Btrfs still lacks any
support for lazytime. Has any thought been given to adding support
for lazytime to Btrfs?
[…]
Is there any new regarding this?
I´d like to know whether there is any news about this as well.
If I understand it correctly this could even help BTRFS performance a
lot cause it is COW´ing metadata.
I do not see how btrfs can support it exactly due to cow. Modified atime means
checksum no more matches so you must update all related metadata. At which
point you have kind of shadow in-memory metadata trees. And if this metadata is
not written out, then some other metadata that refers to them becomes invalid.
I think you might be misunderstanding something here, either how
lazytime actually works, or how BTRFS checksumming works.
Lazytime prevents timestamp updates from triggering writeback of a
cached inode. Other changes will trigger writeback, as will anything
that evicts the inode from the cache, and an automatic writeback will be
triggered if the timestamp changed more than 24 hours ago, but until any
of those situations happens, no writeback will be triggered.
BTRFS checksumming only verifies checksums of blocks which are being
read. If the inode is in the cache (which it has to be for lazytime to
have _any_ effect on it), the block containing it on disk does not need
to be read, so no checksum verification happens. Even if there was
verification, we would not be verifying blocks that are in memory using
the on-disk checksums (because that would break writeback caching, which
we already do and already works correctly).
So, given all this, the only inconsistency on-disk for BTRFS with this
would be identical to the inconsistency it causes for other filesystems,
namely that mtimes and atimes may not be accurate.
Also, slightly OT, but atimes are not where the real benefit is here for
most people. No sane software other than mutt uses atimes (and mutt's
use of them is not sane, but that's a different argument), so pretty
much everyone who wants to avoid the overhead from them can just use the
`noatime` mount option. The real benefit for most people is with
mtimes, for which there is no other way to limit the impact they have on
performance.
I suspect any file system that keeps checksums of metadata will run into the
same issue.
Nope, only if they verify checksums on stuff that's already cached _and_
they pull the checksums for verification from the block device and not
the cache.
