linux-ext4 - periodic lifetime_write

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 2 Nov 2022 17:41:07 -0600
From:   Andreas Dilger <adilger@...ger.ca>
To:     linux-ext4@...r.kernel.org
Subject: periodic lifetime_write_kbytes updates?

I was looking at the /sys/fs/ext4/*/lifetime_write_kbytes counters on
my home server and wondering about how accurate they are.  That is most
interesting in the case of flash devices, to get a good idea of the
lifetime writes vs. actual rated drive writes per day.

It looks like s_kbytes_written is only updated on clean unmount
via ext4_commit_super->ext4_update_super() and in a few error handling
codepaths.  This means any in-memory updates are typically lost if the
server crashes or loses power (which is typical for long-running servers,
rather than a clean shutdown).

It would be useful to periodically update the superblock with the current
value, maybe once an hour if the value has changed more than some small
margin (to take into account the *previous* update).  The superblock used
to be written frequently via ->write_super(), but this has not been the
case since commit v3.5-rc5-19-g4d47603d9703.

Any thoughts/objections to a periodic task calling ext4_update_super()
every hour if there have been any noticeable writes since the last time
it was called?  This could potentially be more clever so that it only
writes if the disk is not asleep, and do the writes the next time it wakes,
but I'm not sure how easy/hard that is to detect at the filesystem level.

Cheers, Andreas

PS: there is *also* a function resize.c::ext4_update_super() for added
confusion, but that does something completely different...

Download attachment "signature.asc" of type "application/pgp-signature" (874 bytes)