registry team mailing list archive

[Theodore Ts'o <tytso@xxxxxxx>]

>Couldn't/shouldn't systems with broken real time clocks be fixed to
>force the system clock up to mkfs time before mounting the root fs, and
>wouldn't that take care of that and other problems?

Unfortunately, it's not so simple.  What about people running old
systems, like Ubuntu LTS and then upgrade to a newer e2fsprogs?   What
if someone else from Ubuntu doesn't realize about this dependency and
releases a version of e2fsprogs with this change?

More seriously, what if there is more than one filesystem?  What about
an USB storage device containing an extN filesystem which is hotplugged
in after system boot?

What about someone running an Live CD system with a crappy clock far in
the future, and who then formats the filesystem?  What if they install a
system using an Ubuntu installation CD with the date far into the
future?

I agree with you that it would be highly convenient if we could count on
the system clock.   I come from the Unix world, where we could, and it
makes life much easer.   In the good old days, Multics simply wouldn't
allow the system to come up at all if it would result in time going
backwards, and then they utilized this property in all sorts of really
cool ways.  (Heh, Multics could even allow you to detect a file system
corruption, and then repair a live mounted filesystem with that error,
all while the file system was mounted.  It could even survive a third of
its memory suddenly disappearing, and it would only kill the processes
which had  memory disappear after the janitor plugged the floor waxer
into the wrong circuit, blowing an electrical breaker and disabling one
of the cabinets containing some of the system's memory.)

Unfortunately, we don't live in that world.   We live in the world of
clueless users, people who want to dual boot Windows, crap hardware with
CMOS crystals that are off by plus or minus 20%, so simply keeping
crapola tablet or embedded device turned off while it is shipped from
Taiwan to the US in a container ship will cause the clock to be at some
random time.  We live in the world of crappy virtualization manager
software which sets the CMOS time from the Unix system time and then
doesn't bother to do the time zone virtualization.   (I'm looking at
you, Ubuntu; the bug was filed in Launchpad a while back IIRC --- no,
not against the virtualization manager, but in e2fsprogs; it's always
e2fsprogs fault when something goes wrong because people can't deal with
system clock bugs.)  And of course, the clock could be bad in the
factory in Taiwan where the system is installed.

And because of this, the sorts of problems are legion.  The hueristic I
proposed won't handle the case where the s_mkfs time is set into the
future because the clock was bad at installer time, and then the system
boots, and then the time gets warped back to the correct time by NTP,
and the hardware clock is set correctly, and on the next reboot, e2fsck
with your proposed patch goes wild and started deleting inodes as
"belonging to the previous filesystem format".

>I'd rather avoid the need to zero the table completely since that has
>negative consequences other than just using up disk IO in the
>background. For instance, if the fs is on a snapshot, thin provisioned
>san disk, or SSD, the writes cause allocations that aren't needed just
>to hold zeroes, which reads there would already return.

First of all, it's no worse than it is today given how mke2fs works,
which zeros the inode table in the foreground.  Secondly, I'd much
rather have correct behaviour than lose some users data just to optimize
mke2fs time.   The snapshot case only applies if you are making a
snapshot in the first 15 minutes after the system is installed; after
that the inode table will have been zero'ed so this isn't a big deal.
As far as the SSD is concerned, *if* we know it is an SSD reliably
(perhaps because it doesn't take long to read in the a few block groups
worth of inode table blocks), then we could also simply verify that the
inode table blocks have been cleared after issuing the BLKDISCARD ioctl,
and if so, we don't need to zero the blocks.

The other long-term solution to this problem is to add checksum fields
to protect the inode structures, which will have in the inode structure
the inode number and an FS-unique random seed included in the checksum.
This requires a read-only incompat file system feature flag, which means
older kernels won't be allowed to modify such file systems (since
otherwise they will break the checksum), so it's something that would
have to be phased in.  But it's the right long-term solution.

The bottom line is that given today's crappy hardware, and machines
which can't be counted upon to be maintained by professional system
administrators, trying to depend on the clock is just going to get you
in trouble.   Ubuntu has taught me this less all too well....

-- 
lazy_itable_init not on by default
https://bugs.launchpad.net/bugs/556621
You received this bug notification because you are a member of Registry
Administrators, which is the registrant for e2fsprogs.