On Thu, Oct 29, 2009 at 02:03:31PM +0000, Thorsten Glaser wrote:
>
> considering Message #64, why is localtime used by ext2fs anyway?
> With all times in UTC (or rather in whatever time_t is) this kind
> of problems certainly couln't happen at all?
Ext2fs doesn't use localtime. The problem is some people, in the need
to be bug-for-bug compatible with Windows, set their hardware CMOS
clocks to tick localtime. This is crazy, since it means that during a
DST transition, you don't know whether or not the hardware clock has
been frobbed (Windows has to ask you, since it can never be sure).
Worse yet, if you have two OS's that are both trying to frob the
hardware CMOS times during the DST transition, it's very likely that
one or the other OS will get things wrong.
Unfortunately, Redmond, Washington got this wrong over two decades
ago, and people who must use Windows are still paying the price. I
solve the problem by simply refusing to run Windows on machines that
run Linux, and making the hardware clock tick UTC time, which is the
One And Only Sane Solution.
In anycase, the problem isn't that ext2fs uses local time, it's that
e2fsprogs requires the system clock to be *correct*; that is, the
date(1) command and the time(2) system call has to return the correct
time. Since Linux uses UTC, like all sane Operating systems, the
problem when the hardware CMOS clock is ticking local time is setting
the system clock correctly when the hardware CMOS clock is ticking
some random local time (and during the DST transition, you really have
no clue how to set the system clock from the hardware clock --- but
the bug here is using local time and the fundamental bug is having
Windows installed. :-)
One of the problems that has only been recently fixed in the latest
kernels is a kernel bug. When the root file system is being mounted,
if you are in a European timezone and you have committed the venial
sin of letting your hardware clock tick localtime, the last write time
gets set incorrectly when the root file system is mounted read-only
--- and it gets set mounted in the future, which means that even if
the init scripts properly adjust for the local timezone so the system
clock is correct when e2fsck runs, it detects a problem because the
last mount time is in the future. Short of applying the local time
zone adjustment in the initrd, there's no way to avoid the system
clock being incorrect when the root file system is being mounted.
The kernel bugfix is to avoid setting the last write time when the
file system is being mounted read-only --- which is a good and proper
thing to do anyway. What was happening was that when we replay the
journal (after an unclean shutdown), we need to update the superblock
to clear the "journal replay needed" bit, and this was setting the
last superblock last write time.
> Still, this is weird. I agree on the Live CD part, although I
> personally take care to set the timezone on all systems to UTC,
> I cannot do that for other systems or for all systems at work.
For the Live CD, arguably it should just set "buggy_init_scripts",
since it's the case that it can't know the local timezone adjustment,
and simply asking fsck to be more lenient about time problems. But
make no mistake, this is a case of papering over a bug. It's a bug we
can't control, since it's fundamentally about Windows being installed
on the disk and the hardware clock being set to tick localtime instead
of UTC. But it's still a bug, and we're still papering over it.
- Ted
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
