1

I had the idea to compare the system clock with the data of the last superblock update when booting (as traditional UNIX systems did).

However it seems the superblock (or at least it's write time) is not updated after mounting:

# uptime
 09:58:25  up 9 days 21:39,  2 users,  load average: 0.00, 0.06, 0.03
# grep /var /etc/fstab
/dev/v04/var         /var                 ext3       acl,user_xattr        1 2
# dumpe2fs -h /dev/v04/var | grep "^Last write time:"
dumpe2fs 1.47.0 (5-Feb-2023)
Last write time:          Mon Aug 11 12:18:34 2025

It seems the time of last write is the time of mounting:

Filesystem created:       Fri May 22 09:56:26 2015
Last mount time:          Mon Aug 11 12:18:34 2025
Last write time:          Mon Aug 11 12:18:34 2025

Why isn't the superblock updated periodically?

The kernel is 6.4.0-150600.23.53-default (SLES15 SP6 on x86_64), and I was using dumpe2fs 1.47.0 (5-Feb-2023).

Improve this question
10
  • Not sure why you'd expect that to happen? Repeated updates without changed data would seem to be something I'd immediately want to disable for a storage driver. Commented Aug 21 at 14:54
  • @MarcusMüller I'd consider it rather unlikely that /var (the home of syslog) does not change data frequently. Likewise I'd be surprised if Free blocks would have the same value after 10 days. Commented Aug 22 at 7:24
  • But changes do not imply at all superblock changes at all. Why do you care about the superblock? Commented Aug 22 at 10:45
  • Regarding free space, I wouldn't be that surprised: Free space tallying is typically delayed, because it is kind of "redundant" information that's gathered from the actual free block lists. If but small changes occur, I could see why a sensible FS driver wouldn't update the on-disk counter for that regularly (that's just not necessary - the counter can be correctly kept in RAM, and in case of a system crash / power loss, can be correctly reconstructed from the free space tables) but only on unmount – a point at which esp. for a directory mostly used not by syslog but by cleaning-up-log-by-size Commented Aug 22 at 10:48
  • … journald (I think logrotate might have a similar function?) has "balanced" to a stable value. Again, here, the question I'd ask is: why do you care about the superblock, specifically? To me, that's an implementation detail of the OS's filesystem implementation, not an API to ask – if you want to know how much free space there is while the FS is mounted, you'd go and use statfs on the mount point, not read the on-disk data directly (which, again, doesn't have to, and usually isn't, updated all the time, because: no upside, storage wear, latency and power downside) Commented Aug 22 at 10:53

0

Reset to default

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.