Thread (10 messages) 10 messages, 4 authors, 2022-09-12

Re: [man-pages RFC PATCH v4] statx, inode: document the new STATX_INO_VERSION field

From: Florian Weimer <hidden>
Date: 2022-09-12 12:13:27
Also in: ceph-devel, linux-api, linux-btrfs, linux-ext4, linux-fsdevel, linux-nfs, linux-xfs, lkml

Possibly related (same subject, not in this thread)

* Jeff Layton:
To do this we'd need 2 64-bit fields in the on-disk and in-memory 
superblocks for ext4, xfs and btrfs. On the first mount after a crash,
the filesystem would need to bump s_version_max by the significant
increment (2^40 bits or whatever). On a "clean" mount, it wouldn't need
to do that.

Would there be a way to ensure that the new s_version_max value has made
it to disk? Bumping it by a large value and hoping for the best might be
ok for most cases, but there are always outliers, so it might be
worthwhile to make an i_version increment wait on that if necessary. 
How common are unclean shutdowns in practice?  Do ex64/XFS/btrfs keep
counters in the superblocks for journal replays that can be read easily?

Several useful i_version applications could be negatively impacted by
frequent i_version invalidation.

Thanks,
Florian
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help