On Thu, 28 Sept 2023 at 20:50, Amir Goldstein <amir73il@xxxxxxxxx> wrote:
>
> OTOH, it is perfectly fine if the vfs wants to stop providing sub 100ns
> services to filesystems. It's just going to be the fs problem and the
> preserved pre-historic/fine-grained time on existing files would only
> need to be provided in getattr(). It does not need to be in __i_mtime.
Hmm. That sounds technically sane, but for one thing: if the aim is to try to do
(a) atomic timestamp access
(b) shrink the inode
then having the filesystem maintain its own timestamp for fine-grained
data will break both of those goals.
Yes, we'd make 'struct inode' smaller if we pack the times into one
64-bit entity, but if btrfs responds by adding mtime fields to "struct
btrfs_inode", we lost the size advantage and only made things worse.
And if ->getattr() then reads those fields without locking (and we
definitely don't want locking in that path), then we lost the
atomicity thing too.
So no. A "but the filesystem can maintain finer granularity" model is
not acceptable, I think.
If we do require nanoseconds for compatibility, what we could possibly
do is say "we guarantee nanosecond values for *legacy* dates", and say
that future dates use 100ns resolution. We'd define "legacy dates" to
be the traditional 32-bit signed time_t.
So with a 64-bit fstime_t, we'd have the "legacy format":
- top 32 bits are seconds, bottom 32 bits are ns
which gives us that ns format.
Then, because only 30 bits are needed for nanosecond resolution, we
use the top two bits of that ns field as flags. '00' means that legacy
format, and '01' would mean "we're not doing nanosecond resolution,
we're doing 64ns resolution, and the low 6 bits of the ns field are
actually bits 32-37 of the seconds field".
That still gives us some extensibility (unless the multi-grain code
still wants to use the other top bit), and it gives us 40 bits of
seconds, which is quite a lot.
And all the conversion functions will be simple bit field
manipulations, so there are no expensive ops here.
Anyway, I agree with the "let's introduce the accessor functions
first, we can do the 'pack into one word' decisions later".
Linus
