Date: Wed, 3 Jul 2019 21:26:35 -0000 (UTC)
From: mlel...@serpens.de (Michael van Elst)
Message-ID: <qfj6ib$njd$1...@serpens.de>
| FFSv1 also has a 32bit (or rather 31bit) limit. Since it counts fragments,
| not physical disk blocks, the effective limit for the filesystem size
| varies between 1TB (512byte fragments) and 128TB (64kByte fragments).
The other significant difference is that FFSv1 uses 32 bit time_t's (for
everything) with microsecond precision, FFSv2 uses 64 bit time_t's with
nanosecond prevision.
This means that in 2038 (unless we do a fiddle, which we will almost
certainly do) FFSv1 filesystems will all become useless.
But, as no-one has FFS filesystems with (legitimate) dates in them before 1970
we can easily change the range of 32 bit time_t values in the filesystem from
1902-2038 to instead be 1970-2106 by simply treating the timestamp recorded
in the filesystem as an unsigned value (when converting it to the 32 bit
time_t that is used internally).
A bigger problem is continuing to support the old APIs with 32 bit time_t's
in compat mode .. we should really be starting now to make sure that no-one
has anything left that uses 32 bit time_t's well before 2038. We could
move the range for those as well (with libc hacks) making it be something
like 1950-2086 (approx - or something like that) but that can be dangerous
to apps that beliee they understand the time_t representation and don't
simply treat it as an opaque value to hand off to localtime().
An insignificant difference is that FFSv2 has the totally useless birthtime
timestamp added (which ought to be removed again...)
kre
