The ext3 way of journalling - Kernel

This is a discussion on The ext3 way of journalling - Kernel ; On Jan 9, 2008 1:25 PM, Theodore Tso wrote: > On Wed, Jan 09, 2008 at 10:54:11AM +0100, Martin Schwidefsky wrote: > > Actually you can force Windows to accept a hardware clock in UTC: > > HKEY_LOCAL_MACHINE/SYSTEMCurrentControlSetControl/TimeZoneInformation/RealTimeIsUniversal > > ...

+ Reply to Thread
Page 3 of 4 FirstFirst 1 2 3 4 LastLast
Results 41 to 60 of 74

Thread: The ext3 way of journalling

  1. Re: The ext3 way of journalling

    On Jan 9, 2008 1:25 PM, Theodore Tso wrote:
    > On Wed, Jan 09, 2008 at 10:54:11AM +0100, Martin Schwidefsky wrote:
    > > Actually you can force Windows to accept a hardware clock in UTC:
    > > HKEY_LOCAL_MACHINE/SYSTEMCurrentControlSetControl/TimeZoneInformation/RealTimeIsUniversal

    >
    > Oh, so cool!!! Do you know off hand what version of Windows started
    > honoring that registry setting?


    I have a Windows XP next to Linux on my home box. So I can say from
    experience that Windows XP works. I have no idea if older versions had
    that registry entry as well.

    > And what do you set that registry value to? Just a boolean "true"?


    I can check my dual-boot machine when I get home. I think it was just "1".

    > Now, how to convince Ubuntu to put this in their FAQ so I stop having
    > their ahhh, less than clueful dual-booting Windows users who happen to
    > live in Europe stop submitting bugs on this issue....


    An entry in some FAQ would indeed be helpful. It would have saved me
    some hassle.

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

  2. Re: The ext3 way of journalling

    On 2008-01-09, Mathieu SEGAUD wrote:
    > fix your hardware clock then


    It displays just the right time. On boot anyway. (Linux has had some
    serious problems keeping the time after the switch from 2.6.7 to 2.6.14,
    advanding even 15 minutes a day -- that ntpd doesn't seem to be able
    to keep up with -- requiring running adjtimexconfig every now and
    then for new settings. But the cmos clock displays the right time.)

    --
    Tuomo

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

  3. Re: The ext3 way of journalling

    On Jan 9, 2008 2:53 PM, Martin Schwidefsky wrote:
    > On Jan 9, 2008 1:25 PM, Theodore Tso wrote:
    > > On Wed, Jan 09, 2008 at 10:54:11AM +0100, Martin Schwidefsky wrote:
    > > > Actually you can force Windows to accept a hardware clock in UTC:
    > > > HKEY_LOCAL_MACHINE/SYSTEMCurrentControlSetControl/TimeZoneInformation/RealTimeIsUniversal

    > >
    > > Oh, so cool!!! Do you know off hand what version of Windows started
    > > honoring that registry setting?

    >
    > I have a Windows XP next to Linux on my home box. So I can say from
    > experience that Windows XP works. I have no idea if older versions had
    > that registry entry as well.
    >
    > > And what do you set that registry value to? Just a boolean "true"?

    >
    > I can check my dual-boot machine when I get home. I think it was just "1".


    RealTimeIsUniversal is a REG_DWORD with content "1".

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

  4. Re: The ext3 way of journalling

    Matthias Schniedermeyer wrote:
    >>> Don't use udev then. Good old static dev works fine if you have a fixed
    >>> set of devices.
    >>>

    >> It doesn't, with the unpredictable SCSI mapping insanity.
    >>

    >
    > That what LABEL und UUID-Support in mount is for.
    >
    > You label the filesystems (e2label for ext2 and ext3) and use that label to mount them
    >
    > - fstab -
    > LABEL=root / xfs defaults,noatime 0 1
    > LABEL=boot /boot ext2 defaults,noatime 0 2
    >

    Would've been nice if they worked, but they don't.

    Disks should be so easy to identify uniquely, because they have
    storage space that can be used for that label.

    So I tried (debian linux, last year).

    Mount by label was fine, of course.
    Until the 33rd reboot, when it was decided that a
    fsck was necessary "just to be safe". The problem was that fsck
    fail to find the correct device when /etc/fstab specifies a label
    instead of a device. The boot failed, reboot with init=/bin/sh
    and replace the dysfunctional labels with oldfashioned device names.

    I can live with this kind of problem on my desktop, but this machine
    was going to be a internet router for a customer, so occational
    boot failure requiring intervention was not an option.

    Helge Hafting






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

  5. Re: The ext3 way of journalling

    On Wed, Jan 09, 2008 at 02:16:52PM +0000, Tuomo Valkonen wrote:
    > On 2008-01-09, Mathieu SEGAUD wrote:
    > > fix your hardware clock then

    >
    > It displays just the right time. On boot anyway. (Linux has had some
    > serious problems keeping the time after the switch from 2.6.7 to 2.6.14,
    > advanding even 15 minutes a day -- that ntpd doesn't seem to be able
    > to keep up with -- requiring running adjtimexconfig every now and
    > then for new settings. But the cmos clock displays the right time.)


    What do you mean by "on boot"? Which boot message, precisely? Is the
    time printed before or after e2fsck is run, and by which program?

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

  6. Re: The ext3 way of journalling

    On 2008-01-10 08:16 -0500, Theodore Tso wrote:
    > > It displays just the right time. On boot anyway. (Linux has had some
    > > serious problems keeping the time after the switch from 2.6.7 to 2.6.14,
    > > advanding even 15 minutes a day -- that ntpd doesn't seem to be able
    > > to keep up with -- requiring running adjtimexconfig every now and
    > > then for new settings. But the cmos clock displays the right time.)

    >
    > What do you mean by "on boot"? Which boot message, precisely? Is the
    > time printed before or after e2fsck is run, and by which program?


    The time is right as displayed by `date` after boot, i.e. after it has
    been loaded from the CMOS clock that does keep the (local, IIRC) time
    just allright. But then it often starts advancing very fast.

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

  7. Re: The ext3 way of journalling

    On Thu, Jan 10, 2008 at 12:30:31PM +0100, Helge Hafting wrote:
    > >- fstab -
    > >LABEL=root / xfs defaults,noatime 0 1
    > >LABEL=boot /boot ext2 defaults,noatime 0 2
    > >

    > Would've been nice if they worked, but they don't.
    >
    > Disks should be so easy to identify uniquely, because they have
    > storage space that can be used for that label.
    >
    > So I tried (debian linux, last year).
    >
    > Mount by label was fine, of course.
    > Until the 33rd reboot, when it was decided that a
    > fsck was necessary "just to be safe". The problem was that fsck
    > fail to find the correct device when /etc/fstab specifies a label
    > instead of a device. The boot failed, reboot with init=/bin/sh
    > and replace the dysfunctional labels with oldfashioned device names.
    >
    > I can live with this kind of problem on my desktop, but this machine
    > was going to be a internet router for a customer, so occational
    > boot failure requiring intervention was not an option.


    I use this:
    UUID=35963d32-f15e-497e-859a-ed1cb366b0f3 / ext3 defaults 0 1

    No problem with fsck or anything on my debian system. I had problems
    trying to use LABELs but UUID always worked when I tried it. Back under
    sarge I had problems getting it to work though.

    Works much better than trying to use disk names, since I have 3
    different IDE controllers and the modules seem to never quite initialize
    in the same order every time from the initramfs.

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

  8. Re: The ext3 way of journalling

    On 10.01.2008 12:30, Helge Hafting wrote:
    > Matthias Schniedermeyer wrote:
    >>>> Don't use udev then. Good old static dev works fine if you have a fixed
    >>>> set of devices.
    >>>>
    >>> It doesn't, with the unpredictable SCSI mapping insanity.
    >>>

    >>
    >> That what LABEL und UUID-Support in mount is for.
    >>
    >> You label the filesystems (e2label for ext2 and ext3) and use that label to mount them
    >>
    >> - fstab -
    >> LABEL=root / xfs defaults,noatime 0 1
    >> LABEL=boot /boot ext2 defaults,noatime 0 2
    >>

    > Would've been nice if they worked, but they don't.
    >
    > Disks should be so easy to identify uniquely, because they have
    > storage space that can be used for that label.
    >
    > So I tried (debian linux, last year).
    >
    > Mount by label was fine, of course.
    > Until the 33rd reboot, when it was decided that a
    > fsck was necessary "just to be safe". The problem was that fsck
    > fail to find the correct device when /etc/fstab specifies a label
    > instead of a device. The boot failed, reboot with init=/bin/sh
    > and replace the dysfunctional labels with oldfashioned device names.
    >
    > I can live with this kind of problem on my desktop, but this machine
    > was going to be a internet router for a customer, so occational
    > boot failure requiring intervention was not an option.


    As written by Theodore somewhere else in this thread support for labels
    in fsck came later, so maybe the fsck-version on your problematic-server
    was too old.

    Personally i never had a problem with labels and i use them for about
    4-5 years now.





    Bis denn

    --
    Real Programmers consider "what you see is what you get" to be just as
    bad a concept in Text Editors as it is in women. No, the Real Programmer
    wants a "you asked for it, you got it" text editor -- complicated,
    cryptic, powerful, unforgiving, dangerous.

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

  9. Re: The ext3 way of journalling

    On Thu, Jan 10, 2008 at 03:41:11PM +0200, Tuomo Valkonen wrote:
    > On 2008-01-10 08:16 -0500, Theodore Tso wrote:
    > > > It displays just the right time. On boot anyway. (Linux has had some
    > > > serious problems keeping the time after the switch from 2.6.7 to 2.6.14,
    > > > advanding even 15 minutes a day -- that ntpd doesn't seem to be able
    > > > to keep up with -- requiring running adjtimexconfig every now and
    > > > then for new settings. But the cmos clock displays the right time.)

    > >
    > > What do you mean by "on boot"? Which boot message, precisely? Is the
    > > time printed before or after e2fsck is run, and by which program?

    >
    > The time is right as displayed by `date` after boot, i.e. after it has
    > been loaded from the CMOS clock that does keep the (local, IIRC) time
    > just allright. But then it often starts advancing very fast.


    So running the "date" command after the boot sequence is completely
    finished. That doesn't mean that system clock was correct at the time
    when fsck is run.

    See, here's the the problem. You have the CMOS hardware clock, which
    for people who are dual-booting with Windows, is unfortunately ticking
    local time, instead of GMT time (or if you want to be pedantic, UTC
    time; whatever). When the kernel is first loaded and starts
    executing, it will set the Linux system clock from the CMOS hardware
    clock. However, it has *no* idea whether the CMOS hardware clock is
    ticking localtime or UTC time. The Linux system clock (i.e., what is
    returned via the gettimeofday() or time() functions) is always UTC
    time.

    What happens later is that distribution init scripts will adjust the
    system clock either forward or backwards if the system is set up so
    that hardware is in Windows bug-compatibility mode where the CMOS
    hwclock is ticking localtime. If it is 1400 GMT, then in the
    US/Eastern timezone, the clock will be 9:00am, so the clock will be
    pushed four hours later. If you are in the Central European Timezone,
    then the local time will be 3pm, and the clock will be pushed
    *backwards* by one hour.

    The question is when does this happen. In some buggy distributions,
    this happens *after* e2fsck is run. And it is in those distributions
    e2fsck can sometimes get confused about when the last time the
    filesystem was checked --- especially if the system is getting
    rebooted a lot (which tends to be the case with people who are
    dual-booting). So the cases where this happens a lot are (a) people
    who are using windows and so the CMOS hwclock is ticking localtime,
    (b) distributions that don't adjust the Linux system clock before
    e2fsck runs. Unfortunately Ubuntu users in Europe fit this
    demographic hugely, and Ubuntu refuses to fix this problem[1], so it's
    been personally very vexing, because the users complain to *me*, and I
    can't fix the problem, because it's a distribution init script issue.

    So what I tell people is to upgrade to the latest e2fsprogs, and then
    set in /etc/e2fsck.conf:

    [options]
    buggy_init_scripts = 1

    Maybe someday Ubuntu will get this right --- but I'm not counting on it.


    [1] Something about installer CD's, and not wanting to ask the users
    any questions, not even what time zone they are in, or some other
    crazyness. I never completely understood the argument and their
    design constraints.

    - Ted

    P.S. If there are other scripts which are started, they can also get
    confused because the time is getting warped backwards early-on. I
    haven't done an analysis to find out which sort programs might be
    vulnerable to this, but this is not necessarily an e2fsck-specific
    problems. After all, it *is* reasonable to expect that the time
    returned by time(0) or gettimeofday() is correct, and many programs do
    make that assumption....
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  10. Re: The ext3 way of journalling

    On Jan 12, 2008 10:06 AM, Theodore Tso wrote:
    [snip]
    > Unfortunately Ubuntu users [snip] fit this demographic hugely, and
    > Ubuntu refuses to fix this problem[1], so it's been personally very
    > vexing, because the users complain to *me*, and I can't fix the problem,
    > because it's a distribution init script issue.

    Ubuntu refuses to be power user friendly. They've forgotten the True
    Meaning (tm) of Linux and try to be Windows-friendly, i.e., No Choices
    (tm).


    > Maybe someday Ubuntu will get this right --- but I'm not counting on it.

    The alternative CD installer still looks like a semi-dumbed-down
    debian installer. Hell, even the command-line base install is severely
    bloated - it's the exact opposite of LFS or gentoo.
    Still, it's *usable* in comparison to the livecd.
    >
    > [1] Something about installer CD's, and not wanting to ask the users
    > any questions, not even what time zone they are in, or some other
    > crazyness. I never completely understood the argument and their
    > design constraints.

    Idiot friendliness and no exceptions to power users (e.g.., bloated
    init scripts, UUID fstab). I switched to debian-unstable ages ago
    *just* because apt is _really_ easy to use. Which I use secondarily to
    Gentoo, where things Just Work (tm), once you patch the package
    ebuilds to process your .patch files anyway and, while the packages
    have *lots* of patches, it doesn't bloat the code *and* you can
    disable the patches with the "vanilla" USE flag.

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

  11. Re: The ext3 way of journalling

    On 2008-01-12 10:06 -0500, Theodore Tso wrote:
    > So running the "date" command after the boot sequence is completely
    > finished. That doesn't mean that system clock was correct at the time
    > when fsck is run.


    Unless ntpd has managed to change it by that time, it was correct,
    in the local time zone. But judging from the "too big difference,
    refusing to correct" behaviour of ntpd while the system is up,
    I doubt ntpd would correct the time at boot, if it were considerably
    wrong. This rapidly advancing system clock is A COMPLETELY DIFFERENT
    PROBLEM that started with switch from 2.6.7 to 2.6.14. Before that
    it worked just fine.

    > Unfortunately Ubuntu users in Europe fit this
    > demographic hugely, and Ubuntu refuses to fix this problem[1], so it's
    > been personally very vexing, because the users complain to *me*, and I
    > can't fix the problem, because it's a distribution init script issue.


    FYI, I'm not running Ubuntu. This system once used to by Debian,
    but since Etch is already obsolete wrt. many non-base software,
    and I'm not going to suffer stable/unstable anymore, and megafrozen
    megadistros with everything between the earth and skies suck anyway,
    largely consists of self-installed software by now. Maybe they broke
    time initialisations for etch.

    Also, I must say that e2fsck is brain-damaged, if it can be confused
    by/do the stupid then when the system clock has warped by just a few
    hours, not the _days_ that a file system check interval typically is,
    and users need to specifically kludge around such misbehaviour in
    e2fsck.

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

  12. Re: The ext3 way of journalling

    On 2008-01-14 00:13 +0200, Tuomo Valkonen wrote:
    > Also, I must say that e2fsck is brain-damaged, if it can be confused
    > by/do the stupid then when the system clock has warped by just a few
    > hours, not the _days_ that a file system check interval typically is,
    > and users need to specifically kludge around such misbehaviour in
    > e2fsck.


    Just to clarify, I had about 60 days of uptime, and hence at least
    60 days since the last FS check/mount/etc., when Linux crashed those
    few days ago, and wanted to start checking disks with "9192 days since
    last file system check".

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

  13. Re: The ext3 way of journalling

    On Mon, Jan 14, 2008 at 12:23:10AM +0200, Tuomo Valkonen wrote:
    > On 2008-01-14 00:13 +0200, Tuomo Valkonen wrote:
    > > Also, I must say that e2fsck is brain-damaged, if it can be confused
    > > by/do the stupid then when the system clock has warped by just a few
    > > hours, not the _days_ that a file system check interval typically is,
    > > and users need to specifically kludge around such misbehaviour in
    > > e2fsck.

    >
    > Just to clarify, I had about 60 days of uptime, and hence at least
    > 60 days since the last FS check/mount/etc., when Linux crashed those
    > few days ago, and wanted to start checking disks with "9192 days since
    > last file system check".


    Well, let's see. 9192 days is a little over 25 years, so that means
    the filesystem was marked as having done an fsck in 2008-25 or roughly
    1983. If you're not seeing any other corruption when e2fsck runs,
    it's highly unlikely that the superblock is getting corrupted. It's
    much more likely that this early in your boot cycle, your clock is
    sometimes incorrect.

    My suggestion to you is to rig your init scripts to print out the the
    current time/date using "/bin/date" and to print out the superblock
    information using "dumpe2fs -h /dev/hdXX" and record the information
    someplace useful. A simple way to do this would be via the following
    command inserted into /etc/init.d/checkroot.sh:

    (date; /sbin/dumpe2fs -h /dev/XXX) | logsave -a /var/log/boot-debug -

    where you've replaced /dev/XXX with the block device of the filesystem
    which keeps on getting checked erroneously.

    All I can say is that most people aren't see what you're seeing, so
    there is something unique about your system which is causing this
    problem to show up. 9192 days means it's not the time going backwards
    scenario; somehow the last checked value is getting set to some very
    bogus value. Normally the only way this could happen is for the time
    to be set to a bogus value (i.e., 1982) when the filesystem check
    takes place. Is the "9192" number roughly constant, or is it always
    changing?

    I wonder if the battery-backed hardware clock in your system is
    busted, and so you're always starting the system with some completely
    bogus time. 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. If you really, really, can't guarantee
    that the time on your system is correct in early boot, about the only
    thing you really *can* do is to use the command "tune2fs -i 0
    /dev/XXX" and disable time-based checks altogether.

    Regards and best of luck,

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

  14. Re: The ext3 way of journalling

    In article <20080113222310.GA20815@jolt.modeemi.cs.tut.fi> you wrote:
    > Just to clarify, I had about 60 days of uptime, and hence at least
    > 60 days since the last FS check/mount/etc., when Linux crashed those
    > few days ago, and wanted to start checking disks with "9192 days since
    > last file system check".


    This, however sounds like a typical "RTC has forgotten time" problem which
    is typical for some motherboards. 9192days is very close to 1984. I never
    see any coruption like that, but broken BIOS clocks quite often.

    Gruss
    Bernd

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

  15. Re: The ext3 way of journalling

    On Mon, 14 Jan 2008 10:57:09 +0100
    Bernd Petrovitsch wrote:

    > On Mon, 2008-01-14 at 09:48 +0000, Tuomo Valkonen wrote:
    > > On 2008-01-14, Bernd Petrovitsch wrote:
    > > > Yes, that is a usual bug/problem in common distributions[0] as
    > > > there is no real guarantee that your clock is not far off.

    > >
    > > It isn't, right after boot. But while the system is on, it sometimes
    > > starts advancing very fast, 15min a day or so. To my knowledge, the
    > > time the CMOS clock is not used then, but rather the kernel tracks
    > > the

    >
    > > time based on scheduler interrupts, with ntpd occasionally
    > > correcting. However, ntpd refuses to correct when the time has
    > > drifted too much, causing even further drift.

    >
    > That shouldn't happen.


    > > Nope, as explained above. ntpdate at boot wouldn't help much,
    > > because the time is (approximately) correct after boot. It only
    > > drifts after it.

    >
    > Aha. That's also strange. `ntpd` is able to (and always does AFAIK)
    > modify the speed of the clock (to keep it synchronized) so that the
    > error is usually much smaller than 1 second - also if you are behind
    > high-jitter links and/or an a high stratum.
    > That leads to the question why the clock starts to run like crazy at
    > some time so that `ntpd` can't cope with it.
    > Playing with `ntpd` parameters (e.g. increasing ) doesn't help I
    > assume.


    NTP can't correct too large errors. I had some similar problems
    (one of many problems) with my HP Proliant desktop. Something totally
    messed up the timekeeping, so the system would drift up to an hour or
    so per day. I don't know what was wrong, I tried a lot of combinations
    of timer options, but couldn't find any that fixed it. A kernel
    upgrade a couple of weeks later fixed those problems and the system
    time has been stable since then.

    So upgrading to a recent kernel is probably a good idea.

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

  16. Re: The ext3 way of journalling

    On Mon, 2008-01-14 at 09:48 +0000, Tuomo Valkonen wrote:
    > On 2008-01-14, Bernd Petrovitsch wrote:
    > > Yes, that is a usual bug/problem in common distributions[0] as there is
    > > no real guarantee that your clock is not far off.

    >
    > It isn't, right after boot. But while the system is on, it sometimes
    > starts advancing very fast, 15min a day or so. To my knowledge, the
    > time the CMOS clock is not used then, but rather the kernel tracks the


    ACK.

    > time based on scheduler interrupts, with ntpd occasionally correcting.
    > However, ntpd refuses to correct when the time has drifted too much,
    > causing even further drift.


    That shouldn't happen.

    > > That the reason to activate `ntpdate` unconditionally: It sets the
    > > current time to an (somewhat) accurate value and `ntpd` handles the
    > > rest.

    >
    > Nope, as explained above. ntpdate at boot wouldn't help much, because
    > the time is (approximately) correct after boot. It only drifts after it.


    Aha. That's also strange. `ntpd` is able to (and always does AFAIK)
    modify the speed of the clock (to keep it synchronized) so that the
    error is usually much smaller than 1 second - also if you are behind
    high-jitter links and/or an a high stratum.
    That leads to the question why the clock starts to run like crazy at
    some time so that `ntpd` can't cope with it.
    Playing with `ntpd` parameters (e.g. increasing ) doesn't help I assume.

    Bernd
    --
    Firmix Software GmbH http://www.firmix.at/
    mobil: +43 664 4416156 fax: +43 1 7890849-55
    Embedded Linux Development and Services


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

  17. Re: The ext3 way of journalling

    On 2008-01-14 10:57 +0100, Bernd Petrovitsch wrote:
    > That leads to the question why the clock starts to run like crazy at
    > some time so that `ntpd` can't cope with it.


    I do wonder whether the PSU could've been causing it. Now that think
    about it, I got the PSU around two years ago, just like I compiled
    2.6.14. This PSU coincidentally seems to have been the cause of the
    crash that started this thread, and went completely silent during
    the same day, on the third crash. But even if the PSU could cause
    the timer interrupt to signal too frequently or so, doesn't explain
    why nearly always after a crash (when journal recovery would be the
    normal course of action), fsck starts checking with absurd intervals
    since last check, whereas there's no trouble booting after normal
    shutdown.

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

  18. Re: The ext3 way of journalling

    On 2008-01-14, Bernd Petrovitsch wrote:
    > But for normal PCs, I don't know how much the quality of a PSU is
    > relevant for the speed of the clock.
    > Can you test with a different PSU?


    I am testing right now. After all I had to get a new PSU, the old one
    being as dead as a rock. But it will take time to see the results.

    --
    Tuomo

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

  19. Re: The ext3 way of journalling

    On 2008-01-14 11:06 +0100, Krzysztof Halasa wrote:
    > So why don't you fix it first? Correct system time is essential.


    I've tried tuning it with adjtimex and everything, and sometimes it
    works for days, but then just suddenly the clock starts advancing.

    > I guess I would upgrade to some newer version, perhaps one which isn't
    > more than two years old...


    As I have stated earlier, upgrading Linux has become too painful by
    compiling from source, and the distros provide even worse crap as
    their stock kernels.

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

  20. Re: The ext3 way of journalling

    Tuomo Valkonen writes:

    >> So why don't you fix it first? Correct system time is essential.

    >
    > I've tried tuning it with adjtimex and everything, and sometimes it
    > works for days, but then just suddenly the clock starts advancing.


    Nothing will make it work reliably if the system clock isn't stable.

    > As I have stated earlier, upgrading Linux has become too painful by
    > compiling from source,


    It works for me.

    > and the distros provide even worse crap as
    > their stock kernels.


    That works for me, too.


    The remaining options are c) to live with present situation, and
    d) to give up using Linux (computers etc).

    Or maybe e) to get a motherboard which isn't broken (with the kernel
    you want to use).
    --
    Krzysztof Halasa
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread
Page 3 of 4 FirstFirst 1 2 3 4 LastLast