Re: btrfs filesystem keeps allocating new chunks for no apparent reason

["Austin S. Hemmelgarn" <ahferroin7@gmail.com>]

On 2017-04-11 05:55, Adam Borowski wrote:
> On Tue, Apr 11, 2017 at 06:01:19AM +0200, Kai Krakow wrote:
>> Yes, I know all this. But I don't see why you still want noatime or
>> relatime if you use lazytime, except for super-optimizing. Lazytime
>> gives you POSIX conformity for a problem that the other options only
>> tried to solve.
>
> (Besides lazytime also working on mtime, and, technically, ctime.)
Nope, it by definition can't work on ctime because a ctime update means 
something else changed in the inode, which in turn will cause it to be 
flushed to disk normally (lazytime only defers the flush as long as 
nothing else in the inode is different, so it won't help much on stuff 
like traditional log files because their size is changing regularly 
(which updates the inode, which then causes it to get flushed)).
>
> First: atime, in any form, murders snapshots.  On any filesystem that has
> them, not just btrfs -- I've tested zfs and LVM snapshots, there's also
> qcow2/vdi and so on.  On all of them, every single read-everything operation
> costs you 5% disk space.  For a _read_ operation!
>
> I've tested /usr-y mix of files, for consistency with the guy who mentioned
> this problem first.  Your mileage will vary depending on whether you store
> 100GB disk images or a news spool.
>
> Read-everything is quite rare, but most systems have at least one
> stat-everything cronjob.  That touches only diratime, but that's still
> 1-in-11 inodes (remarkably consistent: I've checked a few machines with
> drastically different purposes, and somehow the min was 10, max 12).
>
> And no, marking snapshots as ro doesn't help: reading the live version still
> breaks CoW.
>
>
> Second: atime murders media with limited write endurance.  Modern SSD can
> cope well, but I for one work a lot with SD and eMMC.  Every single SoC
> image I've seen uses noatime for this reason.
Even on SSD's it's still an issue, especially if it's something like 
ext4 which uses inode tables (updating one inode will usually require a 
RMW of an erase block regardless, but using inode tables means that this 
happens _all the time_).
>
>
> Third: relatime/lazytime don't eliminate the performance cost.  They fix
> only frequently read files -- if you have a big filesystem where you read a
> lot but individual files tend to be read rarely, relatime is as bad as
> strictatime, and lazytime actually worse.  Both will do an unnecessary write
> of all inodes.
>
>
> Four: why?  Beside being POSIXLY_CORRECT, what do you actually gain from
> atime?  I can think only of:
> * new mail notification with mbox.  Just patch the mail reader to manually
>   futimens(..., {UTIME_NOW,UTIME_OMIT}), it has no extra cost on !noatime
>   mounts.  I've personally did so for mutt, the updated version will ship
>   in Debian stretch; you can patch other mail readers although they tend
>   to be rarely used in conjunction with shell access (and thus they have
>   no need for atime at all).
> * Debian's popcon's "vote" field.  Use "inst", and there's no gain from
>   popcon for you personally.
> * some intrusion detection forensics (broken by open(..., O_NOATIME))
On top of all that:
Five:
Handling of atime slows down stat and a handful of other things.  If you 
take a source tree the size of the Linux kernel, write a patch that 
changes every file (even just one character), and then go to commit it 
in Git (or SVN, or Bazaar, or Mercurial), you'll see a pretty serious 
difference in the time it takes to commit because almost all VCS 
software calls stat() on the entire tree.  relatime won't help much here 
because the check to determine whether or not to update the atime still 
has to happen (in fact, it will hurt slightly, strictatime eliminates 
that check).

Six:
It doesn't behave how most users would inherently expect, partly because 
there are ways to bypass it even if the FS is mounted with strictatime.
>
>
> Conclusion: death to atime!
>