linux-kernel - Re: The ext3 way of journalling

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 14 Jan 2008 14:39:23 -0800
From:	John Hubbard <john.hubbard@...il.com>
To:	Tuomo Valkonen <tuomov@....fi>
CC:	Theodore Tso <tytso@....edu>, linux-kernel@...r.kernel.org
Subject: Re: The ext3 way of journalling

Tuomo Valkonen wrote:
> On 2008-01-13 18:11 -0500, Theodore Tso wrote:
>> It's much more likely that this early in your boot cycle, your clock is
>> sometimes incorrect.
> 
> I doubt it. I get this nearly _always_ when the system crashes, which
> accounts for the vast majority of the times I boot it. (I wish swsusp
> didn't suck so much..)
> 
>> Is the "9192" number roughly constant, or is it always changing?
> 
> No. That's the number I got last time, but typically I've got 
> something in the 3xxxx range. 
> 
>> If your machine is on the network, then the "ntpdate"
>> program could be setting your time so that it looks correct, but
>> that's after e2fsck is run.  
> 
> ntpdate isn't run by any of the init scripts. ntpd is, but like I 
> already mentioned, I doubt it would correct vastly incorrect time,
> not even being able to track and correct when it advances fast.
> 

ntpd will allow an initial correction that is arbitrarily large, if run 
with the -g option. This is a commonly used option. I see it is running 
on my stock Fedora Core 8, for example. So there is often no need to run 
ntpdate.

Also, ntpd keeps track of how fast your local clock tends to drift, and 
attempts to compensate. So, even if the local clock runs quite fast or 
slow, you'll normally get good results. The exception would be if you 
clock's drift rate jumps around; for example: fast today, slow tomorrow.

On most systems, ntpd will also copy the current time back to the CMOS, 
periodically, and during an orderly shutdown.

Hope that adds some clarity.

thanks,
John Hubbard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/