Re: The ext3 way of journalling
On Jan 9, 2008 12:07 AM, Tuomo Valkonen <[EMAIL PROTECTED]> wrote: > One should always indicate the version of software when complaining. Well, > > $ uname -a > Linux noi 2.6.14 #1 PREEMPT Sun Oct 30 20:18:48 EET 2005 i686 GNU/Linux > > I've tried upgrading, and failed: the megatonne monolith with a gazillion > hidden options (and totally worthless make oldconfig) is impossible to > compile these days, and the distros' stock kernel are utter and total crap > that load drivers in wrong order etc., and are difficult to configure > (demanding crap that demands udev to edit their initrds). Not to even > speak of the udev-demanding scsi-mapping insanity of SATA etc. devices > these days. > somebody has been reading the Unix Haters Handbook... I like that book too. In a way it a very good guideline for unix developers. > I've had it with Linux. It's no longer for power users. It's so complex > that it's only for idiot users that are content with the shoddy defaults, > and (paid) developers. > > -- > Tuomo > I said that 2 weeks ago. And after trying out alternatives im back to linux. But i bought the minix 3 book... -- Lay low and nourish in obscurity -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On Jan 9, 2008 12:07 AM, Tuomo Valkonen [EMAIL PROTECTED] wrote: One should always indicate the version of software when complaining. Well, $ uname -a Linux noi 2.6.14 #1 PREEMPT Sun Oct 30 20:18:48 EET 2005 i686 GNU/Linux I've tried upgrading, and failed: the megatonne monolith with a gazillion hidden options (and totally worthless make oldconfig) is impossible to compile these days, and the distros' stock kernel are utter and total crap that load drivers in wrong order etc., and are difficult to configure (demanding crap that demands udev to edit their initrds). Not to even speak of the udev-demanding scsi-mapping insanity of SATA etc. devices these days. somebody has been reading the Unix Haters Handbook... I like that book too. In a way it a very good guideline for unix developers. I've had it with Linux. It's no longer for power users. It's so complex that it's only for idiot users that are content with the shoddy defaults, and (paid) developers. -- Tuomo I said that 2 weeks ago. And after trying out alternatives im back to linux. But i bought the minix 3 book... -- Lay low and nourish in obscurity -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On Tue, Jan 15, 2008 at 02:09:02AM +0100, Krzysztof Halasa wrote: > Right, I remember some reports about that, probably IOAPIC or other > HPET issues. Personally never seen that. Thus the suggestion of kernel > upgrade. I believe the ATI chipset managed to somehow get the timer interrupt to arive both on the legacy 8259 and the APIC causing each timer tick to count twice. Nice way to double your system time rate. The nforce2 didn't double, it just ran fast some of the time, which I have no idea how happened, but it went away with newer kernels (and wasn't there with earlier kernels either). -- Len Sorensen -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On Tue, Jan 15, 2008 at 12:13:51AM +0100, Alejandro Riveira Fern??ndez wrote: > My experience too with a Uli 1697 based mb. Estrange clock behaviour with > kernel around .15-20 but fixed now (suffering too with ext3 fsck now i use > jfs) > > Back in the day i blamed the new mb but now that it runs fine i can only > blame > the kernel or ubuntu user space. A lot was due to bugs in the BIOS setup on many of the boards, and a few even due to bugs in the chip design (like ATI's as far as I remember), which the kernel then had to detect and work around. -- Len Sorensen -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On Tue, Jan 15, 2008 at 02:09:02AM +0100, Krzysztof Halasa wrote: Right, I remember some reports about that, probably IOAPIC or other HPET issues. Personally never seen that. Thus the suggestion of kernel upgrade. I believe the ATI chipset managed to somehow get the timer interrupt to arive both on the legacy 8259 and the APIC causing each timer tick to count twice. Nice way to double your system time rate. The nforce2 didn't double, it just ran fast some of the time, which I have no idea how happened, but it went away with newer kernels (and wasn't there with earlier kernels either). -- Len Sorensen -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
[EMAIL PROTECTED] (Lennart Sorensen) writes: > I remember my nforce2 board having totally insane clock behaviour back > around 2.6.14/2.6.15 or so. It has since been fixed in newer kernels. > I seem to recall some ATI chipsets were even more insane than the nvidia > at the time, with some running double speed for the system time. Right, I remember some reports about that, probably IOAPIC or other HPET issues. Personally never seen that. Thus the suggestion of kernel upgrade. -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
El Mon, 14 Jan 2008 11:18:28 -0500 [EMAIL PROTECTED] (Lennart Sorensen) escribió: > On Mon, Jan 14, 2008 at 01:46:56PM +0100, Krzysztof Halasa wrote: > > Nothing will make it work reliably if the system clock isn't stable. > > I remember my nforce2 board having totally insane clock behaviour back > around 2.6.14/2.6.15 or so. It has since been fixed in newer kernels. My experience too with a Uli 1697 based mb. Estrange clock behaviour with kernel around .15-20 but fixed now (suffering too with ext3 fsck now i use jfs) Back in the day i blamed the new mb but now that it runs fine i can only blame the kernel or ubuntu user space. > I seem to recall some ATI chipsets were even more insane than the nvidia > at the time, with some running double speed for the system time. > > -- > Len Sorensen > -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 3 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On Mon, Jan 14, 2008 at 01:46:56PM +0100, Krzysztof Halasa wrote: > Nothing will make it work reliably if the system clock isn't stable. I remember my nforce2 board having totally insane clock behaviour back around 2.6.14/2.6.15 or so. It has since been fixed in newer kernels. I seem to recall some ATI chipsets were even more insane than the nvidia at the time, with some running double speed for the system time. -- Len Sorensen -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On 2008-01-14, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > It sounds like you have CONFIG_PM_TRACE turned on. From the Kconfig help: It isn't listed in /proc/config.gz. No, I don't think I even have swsusp stuff compiled in, if it's related to that. -- Tuomo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On 1/14/08, Tuomo Valkonen <[EMAIL PROTECTED]> 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..) It sounds like you have CONFIG_PM_TRACE turned on. From the Kconfig help: This enables some cheesy code to save the last PM event point in the RTC across reboots, so that you can debug a machine that just hangs during suspend (or more commonly, during resume). [...] CAUTION: this option will cause your machine's real-time clock to be set to an invalid time after a resume. -Bob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
Tuomo Valkonen <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On 2008-01-14, Bernd Petrovitsch <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On Mon, 2008-01-14 at 13:11 +0200, Tuomo Valkonen wrote: > 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 We have some embedded systems where some strange problems[0] were caused by bad/cheap/low-quality PSUs. > 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. 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? Bernd [0]: I don't know more details out of the top of my head. -- 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On Mon, 14 Jan 2008 10:57:09 +0100 Bernd Petrovitsch <[EMAIL PROTECTED]> wrote: > On Mon, 2008-01-14 at 09:48 +, Tuomo Valkonen wrote: > > On 2008-01-14, Bernd Petrovitsch <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
Tuomo Valkonen <[EMAIL PROTECTED]> writes: > It isn't, right after boot. But while the system is on, it sometimes > starts advancing very fast, 15min a day or so. So why don't you fix it first? Correct system time is essential. I guess I would upgrade to some newer version, perhaps one which isn't more than two years old... -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On Mon, 2008-01-14 at 09:48 +, Tuomo Valkonen wrote: > On 2008-01-14, Bernd Petrovitsch <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On 2008-01-14, Bernd Petrovitsch <[EMAIL PROTECTED]> 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 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. -- Tuomo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On Mon, 2008-01-14 at 09:15 +0200, Tuomo Valkonen wrote: [...] > ntpdate isn't run by any of the init scripts. ntpd is, but like I Yes, that is a usual bug/problem in common distributions[0] as there is no real guarantee that your clock is not far off. Add your timeservers in /etc/ntp/step-tickers whereever your distribution looks into to decide if ntpdate should run or activate the ntpdate init.d script. And some distributions run `ntpdate` quite late BTW > already mentioned, I doubt it would correct vastly incorrect time, > not even being able to track and correct when it advances fast. That the reason to activate `ntpdate` unconditionally: It sets the current time to an (somewhat) accurate value and `ntpd` handles the rest. Bernd [0]: Perhaps there is some reason for this. However I don't of any and none came ever to my mind. -- 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On Mon, 2008-01-14 at 09:15 +0200, Tuomo Valkonen wrote: [...] ntpdate isn't run by any of the init scripts. ntpd is, but like I Yes, that is a usual bug/problem in common distributions[0] as there is no real guarantee that your clock is not far off. Add your timeservers in /etc/ntp/step-tickers whereever your distribution looks into to decide if ntpdate should run or activate the ntpdate init.d script. And some distributions run `ntpdate` quite late BTW already mentioned, I doubt it would correct vastly incorrect time, not even being able to track and correct when it advances fast. That the reason to activate `ntpdate` unconditionally: It sets the current time to an (somewhat) accurate value and `ntpd` handles the rest. Bernd [0]: Perhaps there is some reason for this. However I don't of any and none came ever to my mind. -- 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On 2008-01-14, Bernd Petrovitsch [EMAIL PROTECTED] 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 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. -- Tuomo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On Mon, 2008-01-14 at 09:48 +, Tuomo Valkonen wrote: On 2008-01-14, Bernd Petrovitsch [EMAIL PROTECTED] 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
Tuomo Valkonen [EMAIL PROTECTED] writes: It isn't, right after boot. But while the system is on, it sometimes starts advancing very fast, 15min a day or so. So why don't you fix it first? Correct system time is essential. I guess I would upgrade to some newer version, perhaps one which isn't more than two years old... -- Krzysztof Halasa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On Mon, 14 Jan 2008 10:57:09 +0100 Bernd Petrovitsch [EMAIL PROTECTED] wrote: On Mon, 2008-01-14 at 09:48 +, Tuomo Valkonen wrote: On 2008-01-14, Bernd Petrovitsch [EMAIL PROTECTED] 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On Mon, 2008-01-14 at 13:11 +0200, Tuomo Valkonen wrote: 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 We have some embedded systems where some strange problems[0] were caused by bad/cheap/low-quality PSUs. 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. 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? Bernd [0]: I don't know more details out of the top of my head. -- 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On 2008-01-14, Bernd Petrovitsch [EMAIL PROTECTED] 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
Tuomo Valkonen [EMAIL PROTECTED] 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On 1/14/08, Tuomo Valkonen [EMAIL PROTECTED] 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..) It sounds like you have CONFIG_PM_TRACE turned on. From the Kconfig help: This enables some cheesy code to save the last PM event point in the RTC across reboots, so that you can debug a machine that just hangs during suspend (or more commonly, during resume). [...] CAUTION: this option will cause your machine's real-time clock to be set to an invalid time after a resume. -Bob -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On Mon, Jan 14, 2008 at 01:46:56PM +0100, Krzysztof Halasa wrote: Nothing will make it work reliably if the system clock isn't stable. I remember my nforce2 board having totally insane clock behaviour back around 2.6.14/2.6.15 or so. It has since been fixed in newer kernels. I seem to recall some ATI chipsets were even more insane than the nvidia at the time, with some running double speed for the system time. -- Len Sorensen -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On 2008-01-14, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: It sounds like you have CONFIG_PM_TRACE turned on. From the Kconfig help: It isn't listed in /proc/config.gz. No, I don't think I even have swsusp stuff compiled in, if it's related to that. -- Tuomo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 3 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
El Mon, 14 Jan 2008 11:18:28 -0500 [EMAIL PROTECTED] (Lennart Sorensen) escribió: On Mon, Jan 14, 2008 at 01:46:56PM +0100, Krzysztof Halasa wrote: Nothing will make it work reliably if the system clock isn't stable. I remember my nforce2 board having totally insane clock behaviour back around 2.6.14/2.6.15 or so. It has since been fixed in newer kernels. My experience too with a Uli 1697 based mb. Estrange clock behaviour with kernel around .15-20 but fixed now (suffering too with ext3 fsck now i use jfs) Back in the day i blamed the new mb but now that it runs fine i can only blame the kernel or ubuntu user space. I seem to recall some ATI chipsets were even more insane than the nvidia at the time, with some running double speed for the system time. -- Len Sorensen -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
[EMAIL PROTECTED] (Lennart Sorensen) writes: I remember my nforce2 board having totally insane clock behaviour back around 2.6.14/2.6.15 or so. It has since been fixed in newer kernels. I seem to recall some ATI chipsets were even more insane than the nvidia at the time, with some running double speed for the system time. Right, I remember some reports about that, probably IOAPIC or other HPET issues. Personally never seen that. Thus the suggestion of kernel upgrade. -- Krzysztof Halasa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
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 3 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. -- Tuomo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
In article <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
In article [EMAIL PROTECTED] 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
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 3 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. -- Tuomo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On Jan 12, 2008 10:06 AM, Theodore Tso <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On 12.01.2008 18:10, TimC wrote: > Bodo Eggert <[EMAIL PROTECTED]> said on Sat, 12 Jan 2008 02:41:17 +0100 (CET): > > On Fri, 11 Jan 2008, Lennart Sorensen wrote: > > > On Fri, Jan 11, 2008 at 05:22:45PM +0100, Bodo Eggert wrote: > > > > > > What can happen if someone does tune2fs -Lroot /dev/usbstick > > > > and puts that stick into this system? > > > > > > Don't know. I use UUIDs rather than LABELs. Having duplicated labels > > > just means being careless. Having duplicate UUIDs should require being > > > malicous. > > > > That's exactly what you have to assume for your users. Otherwise, you could > > remove any security feature from the system. > > If they've got physical access to your machine, you've already lost. As a last resort there is always the option to encrypt everything. Of course you loose the LABEL & UUID support with that. But i circumvented that by a custom udev script and marking the MBR in the documented 4 bytes for an ID that is used by said script to create an appropriate symlink. Together with a matching autofs-conf i can still automatically mount all my >50 encrypted HDDs i have stacked on my shelf. :-) 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On 12.01.2008 18:10, TimC wrote: Bodo Eggert [EMAIL PROTECTED] said on Sat, 12 Jan 2008 02:41:17 +0100 (CET): On Fri, 11 Jan 2008, Lennart Sorensen wrote: On Fri, Jan 11, 2008 at 05:22:45PM +0100, Bodo Eggert wrote: What can happen if someone does tune2fs -Lroot /dev/usbstick and puts that stick into this system? Don't know. I use UUIDs rather than LABELs. Having duplicated labels just means being careless. Having duplicate UUIDs should require being malicous. That's exactly what you have to assume for your users. Otherwise, you could remove any security feature from the system. If they've got physical access to your machine, you've already lost. As a last resort there is always the option to encrypt everything. Of course you loose the LABEL UUID support with that. But i circumvented that by a custom udev script and marking the MBR in the documented 4 bytes for an ID that is used by said script to create an appropriate symlink. Together with a matching autofs-conf i can still automatically mount all my 50 encrypted HDDs i have stacked on my shelf. :-) 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On Jan 12, 2008 10:06 AM, Theodore Tso [EMAIL PROTECTED] 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
Bodo Eggert <[EMAIL PROTECTED]> said on Sat, 12 Jan 2008 02:41:17 +0100 (CET): > On Fri, 11 Jan 2008, Lennart Sorensen wrote: > > On Fri, Jan 11, 2008 at 05:22:45PM +0100, Bodo Eggert wrote: > > > > What can happen if someone does tune2fs -Lroot /dev/usbstick > > > and puts that stick into this system? > > > > Don't know. I use UUIDs rather than LABELs. Having duplicated labels > > just means being careless. Having duplicate UUIDs should require being > > malicous. > > That's exactly what you have to assume for your users. Otherwise, you could > remove any security feature from the system. If they've got physical access to your machine, you've already lost. -- TimC A bug in the code is worth two in the documentation. --unknown -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On Fri, 11 Jan 2008, Lennart Sorensen wrote: > On Fri, Jan 11, 2008 at 05:22:45PM +0100, Bodo Eggert wrote: > > What can happen if someone does tune2fs -Lroot /dev/usbstick > > and puts that stick into this system? > > Don't know. I use UUIDs rather than LABELs. Having duplicated labels > just means being careless. Having duplicate UUIDs should require being > malicous. That's exactly what you have to assume for your users. Otherwise, you could remove any security feature from the system. -- Fun things to slip into your budget Not in a budget, but in an annual report: An employee stole 500,000+. They accounted for it on the annual report as 'involountary employee relations expense' -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On Fri, Jan 11, 2008 at 05:22:45PM +0100, Bodo Eggert wrote: > What can happen if someone does tune2fs -Lroot /dev/usbstick > and puts that stick into this system? Don't know. I use UUIDs rather than LABELs. Having duplicated labels just means being careless. Having duplicate UUIDs should require being malicous. -- Len Sorensen -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
Matthias Schniedermeyer <[EMAIL PROTECTED]> 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 /bootext2defaults,noatime 0 2 What can happen if someone does tune2fs -Lroot /dev/usbstick and puts that stick into this system? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On Fri, Jan 11, 2008 at 05:22:45PM +0100, Bodo Eggert wrote: What can happen if someone does tune2fs -Lroot /dev/usbstick and puts that stick into this system? Don't know. I use UUIDs rather than LABELs. Having duplicated labels just means being careless. Having duplicate UUIDs should require being malicous. -- Len Sorensen -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
Matthias Schniedermeyer [EMAIL PROTECTED] 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 /bootext2defaults,noatime 0 2 What can happen if someone does tune2fs -Lroot /dev/usbstick and puts that stick into this system? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On Fri, 11 Jan 2008, Lennart Sorensen wrote: On Fri, Jan 11, 2008 at 05:22:45PM +0100, Bodo Eggert wrote: What can happen if someone does tune2fs -Lroot /dev/usbstick and puts that stick into this system? Don't know. I use UUIDs rather than LABELs. Having duplicated labels just means being careless. Having duplicate UUIDs should require being malicous. That's exactly what you have to assume for your users. Otherwise, you could remove any security feature from the system. -- Fun things to slip into your budget Not in a budget, but in an annual report: An employee stole 500,000+. They accounted for it on the annual report as 'involountary employee relations expense' -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
Bodo Eggert [EMAIL PROTECTED] said on Sat, 12 Jan 2008 02:41:17 +0100 (CET): On Fri, 11 Jan 2008, Lennart Sorensen wrote: On Fri, Jan 11, 2008 at 05:22:45PM +0100, Bodo Eggert wrote: What can happen if someone does tune2fs -Lroot /dev/usbstick and puts that stick into this system? Don't know. I use UUIDs rather than LABELs. Having duplicated labels just means being careless. Having duplicate UUIDs should require being malicous. That's exactly what you have to assume for your users. Otherwise, you could remove any security feature from the system. If they've got physical access to your machine, you've already lost. -- TimC A bug in the code is worth two in the documentation. --unknown -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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,noatime0 1 >> LABEL=boot /bootext2defaults,noatime0 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On Thu, Jan 10, 2008 at 12:30:31PM +0100, Helge Hafting wrote: > >- fstab - > >LABEL=root /xfs defaults,noatime0 1 > >LABEL=boot /bootext2defaults,noatime0 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 defaults0 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On Wed, Jan 09, 2008 at 02:16:52PM +, Tuomo Valkonen wrote: > On 2008-01-09, Mathieu SEGAUD <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 /bootext2defaults,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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 /bootext2defaults,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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On Wed, Jan 09, 2008 at 02:16:52PM +, Tuomo Valkonen wrote: On 2008-01-09, Mathieu SEGAUD [EMAIL PROTECTED] 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On Thu, Jan 10, 2008 at 12:30:31PM +0100, Helge Hafting wrote: - fstab - LABEL=root /xfs defaults,noatime0 1 LABEL=boot /bootext2defaults,noatime0 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 defaults0 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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,noatime0 1 LABEL=boot /bootext2defaults,noatime0 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On Jan 9, 2008 2:53 PM, Martin Schwidefsky <[EMAIL PROTECTED]> wrote: > On Jan 9, 2008 1:25 PM, Theodore Tso <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On 2008-01-09, Mathieu SEGAUD <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On Jan 9, 2008 1:25 PM, Theodore Tso <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
Vous m'avez dit récemment : > On 2008-01-08, John Stoffel <[EMAIL PROTECTED]> wrote: >> Look at your filesystems, using 'tune2fs' and see if the ext3 journal >> is actually turned on and used. If it's not, then I can see why >> you're having problems on reboots. > > Journalling is on, but it's no use because the superblock always has > corrupted last-checked time at boot. "File system check forced: 31352 > days since last check" or so. fix your hardware clock then -- Mathieu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On Wed, Jan 09, 2008 at 02:55:53AM -0500, [EMAIL PROTECTED] wrote: > > Does this create a snapshot of the *disk* at that moment, or does it > capture "disk plus still-to-be-written blocks in the cache"? > (Phrased differently, does it Do The Right Thing regarding "blocks > queued before lvcreate" and "blocks queued for write after > lvcreate")? > > If the snapshot doesn't capture the blocks queued but still > unwritten by kjournald and similar, then you're still hitting the > same old problems that you always get when you fsck an "active > disk". Actually, it does better than that. For ext3 and xfs, it will take a snapshot of the filesystem in a quiscent state; that is, it will force the journal transaction to close, suspend all filesystem activity, take a snapshot of the disk as if it had been unmounted, and then allow filesystem activity to continue. So if you look at an ext3 filesystem taken in this way, you will see that the NEEDS_RECOVERY flag is not set, since the ext3 journal is empty on the snapshot. So snapshots are also a great way of doing stable backups. For the purposes of stable backups, you'll also want to quiesce your application files, particularly databases. For example, in the case of mysql, send the server the sql commands "flush tables with read lock; flush logs", take the snapshot, and then after the snapshot send the server the sql command "unlock tables". For more information, see: http://forums.mysql.com/read.php?26,185026,185302#msg-185302 If you do this, you will get a snapshot of your disk where *both* the database and the filesystem is at a stable state, perfect for doing a backup. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On Wed, 9 Jan 2008 07:25:56 -0500 Theodore Tso <[EMAIL PROTECTED]> wrote: > On Wed, Jan 09, 2008 at 10:54:11AM +0100, Martin Schwidefsky wrote: > > On Jan 8, 2008 7:15 PM, Theodore Tso <[EMAIL PROTECTED]> wrote: > > > That will fix the this issue. The problem you are facing is that > > > you have your hardware clock set to ticking localtime, instead of > > > GMT. Windows ticks localtime, which is a mistake carried over > > > from the 1970's and MS-DOS. Ticking localtime has all sorts of > > > problems, among which is if you reboot around the transition > > > between Summer Time (or Daylight Savings Time, depending on your > > > contry) and normal time, the OS has no idea whether the DST > > > adjustment has been applied or not. > > > > 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? > > And what do you set that registry value to? Just a boolean "true"? > > 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 According to http://www.cl.cam.ac.uk/~mgk25/mswish/ut-rtc.html it's been there since Windows NT, but it is more or less broken in all newer versions. Michal -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On Wed, Jan 09, 2008 at 11:28:21AM +0100, Matthias Schniedermeyer wrote: > On 09.01.2008 11:21, Matthias Schniedermeyer wrote: > > On 09.01.2008 09:56, Tuomo Valkonen wrote: > > > On 2008-01-09 00:06 +0100, Matthias Schniedermeyer wrote: > > > > That what LABEL und UUID-Support in mount is for. > > > > > > That's udev shit. I don't want it. > > > > No. > > To be more verbose. > > The 'LABEL=' is native mount turf and is much older than udev. Native fsck supports it to; "LABEL=" and "UUID=" support has been in e2fsprogs since July 3rd, 1999. (Mount had it a little before then, but you needed both mount and fsck support before the feature could be used.) And it has *nothing* to do with udev - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On Wed, Jan 09, 2008 at 10:54:11AM +0100, Martin Schwidefsky wrote: > On Jan 8, 2008 7:15 PM, Theodore Tso <[EMAIL PROTECTED]> wrote: > > That will fix the this issue. The problem you are facing is that you > > have your hardware clock set to ticking localtime, instead of GMT. > > Windows ticks localtime, which is a mistake carried over from the > > 1970's and MS-DOS. Ticking localtime has all sorts of problems, among > > which is if you reboot around the transition between Summer Time (or > > Daylight Savings Time, depending on your contry) and normal time, the > > OS has no idea whether the DST adjustment has been applied or not. > > 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? And what do you set that registry value to? Just a boolean "true"? 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 - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On 09.01.2008 11:21, Matthias Schniedermeyer wrote: > On 09.01.2008 09:56, Tuomo Valkonen wrote: > > On 2008-01-09 00:06 +0100, Matthias Schniedermeyer wrote: > > > That what LABEL und UUID-Support in mount is for. > > > > That's udev shit. I don't want it. > > No. To be more verbose. The 'LABEL=' is native mount turf and is much older than udev. That udev ALSO supports the same labels, by providing sym-links in /dev/disk/by-label/<...>, is written on another page. 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On 09.01.2008 09:56, Tuomo Valkonen wrote: > On 2008-01-09 00:06 +0100, Matthias Schniedermeyer wrote: > > That what LABEL und UUID-Support in mount is for. > > That's udev shit. I don't want it. No. 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On Jan 8, 2008 7:15 PM, Theodore Tso <[EMAIL PROTECTED]> wrote: > That will fix the this issue. The problem you are facing is that you > have your hardware clock set to ticking localtime, instead of GMT. > Windows ticks localtime, which is a mistake carried over from the > 1970's and MS-DOS. Ticking localtime has all sorts of problems, among > which is if you reboot around the transition between Summer Time (or > Daylight Savings Time, depending on your contry) and normal time, the > OS has no idea whether the DST adjustment has been applied or not. Actually you can force Windows to accept a hardware clock in UTC: HKEY_LOCAL_MACHINE/SYSTEMCurrentControlSetControl/TimeZoneInformation/RealTimeIsUniversal I'm using this on my dual-boot machine at home because I that stupid Daylight Savings Time change twice a year really annoyed me. So far the only downside I found is that you have to remember that the time you enter in the BIOS has to be UTC. -- blue skies, Martin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On 2008-01-09 00:06 +0100, Matthias Schniedermeyer wrote: > That what LABEL und UUID-Support in mount is for. That's udev shit. I don't want it. -- Tuomo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On Wed, 09 Jan 2008 15:00:46 +0700, BuraphaLinux Server said: > The help for CONFIG_DM_SNAPSHOT says it is EXPERIMENTAL (in > 2.6.23.12). So this would mean that there is very high risk of > software failure using snapshots. Would you want to do that for your > fsck? The overall current state of EXPERIMENTAL in the tree is, quite frankly, somewhere between a complete crock and a wheelbarrow full of bovine fertilizer. There's a lot of things labeled EXPERIMENTAL that shouldn't be, and a lot of bleeding edge things that may eat your disks and cause your dog to turn green that aren't labelled EXPERIMENTAL. Having said that, I have *no* idea what state the snapshot code is in, but I have approximately zero confidence that the EXPERIMENTAL tag tells me anything actually useful about the snapshot code. pgpBeZMfh0A3V.pgp Description: PGP signature
Re: The ext3 way of journalling
The help for CONFIG_DM_SNAPSHOT says it is EXPERIMENTAL (in
2.6.23.12). So this would mean that there is very high risk of
software failure using snapshots. Would you want to do that for your
fsck?
On 1/9/08, Kyle Moffett <[EMAIL PROTECTED]> wrote:
> On Jan 08, 2008, at 15:51:53, Andi Kleen wrote:
> > Theodore Tso <[EMAIL PROTECTED]> writes:
> >> Now, there are good reasons for doing periodic checks every N
> >> mounts and after M months. And it has to do with PC class
> >> hardware. (Ted's aphorism: "PC class hardware is cr*p").
> >
> > If these reasons are good ones (some skepticism here) then the
> > correct way to really handle this would be to do regular background
> > scrubbing during runtime; ideally with metadata checksums so that
> > you can actually detect all corruption.
>
> Poor man's background scrubbing:
>
> (A) Use LVM like virtually all modern distros offer
> (B) Leave some extra space in your LVM volume group (enough for 1
> snapshot over the time it takes to do an FSCK).
> (C) Periodically run the following scriptlet:
>
> set -e
> START="$(date +'%Y%m%d%H%M%S')"
> lvcreate -s -n "${VOLUME}-snap" "${VG}/${VOLUME}"
> if nice +20 fsck -fy "/dev/mapper/${VG}_${VOLUME}-snap"; then
> echo 'Background scrubbing succeeded!'
> tune2fs -T "${START}" "/dev/mapper/${VG}_${VOLUME}"
> else
> echo 'Background scrubbing failed! Reboot to fsck soon!'
> tune2fs -C 16383 -T "19000101" "/dev/mapper/${VG}_${VOLUME}"
> fi
> lvremove "${VG}/${VOLUME}-snap"
>
> Basically you can fsck the offline snapshot in the background. If it
> succeeds you can adjust the "last checked" date to the time when the
> snapshot was taken and if it fails you can schedule an FSCK at next
> reboot (and possibly remount the filesystem read-only or reboot
> immediately).
>
> You can do the same thing for your /boot volume, although you
> probably have to manually use dmsetup since most bootloaders can't
> interpret LVM volumes.
>
> I've always been surprised that distros like RedHat which
> automatically use LVM don't stuff this in their weekly or monthly
> checks on desktop systems. User experience could also be
> dramatically improved with automated smartd configuration and user-
> interactive logging and warning messages.
>
>
> > But since fsck is so slow and disks are so big this whole thing is
> > a ticking time bomb now. e.g. it is not uncommon to require tens of
> > minutes or even hours of fsck time and some server that reboots
> > only every few months will eat that when it happens to reboot. This
> > means you get a quite long downtime.
>
> My servers all have an "interval-between-checks" of 2-6 weeks and are
> configured to run nice +20 background "fsck" checks during off-hours
> between once every few days and once every few weeks. I also have
> the "max mount count" numbers set to primes between 7 and 37
> (depending on the filesystem) so that troubled or frequently-rebooted
> systems are more frequently verified. The end result is that I
> almost never have the dreaded 4-hour-fsck-on-boot problem. A drive
> has certainly been fscked within the last few weeks of operation, and
> I will only ever have multiple large filesystems all fscked at the
> same time very rarely (gcd of their max-mount-counts).
>
> Cheers,
> Kyle Moffett
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
The help for CONFIG_DM_SNAPSHOT says it is EXPERIMENTAL (in
2.6.23.12). So this would mean that there is very high risk of
software failure using snapshots. Would you want to do that for your
fsck?
On 1/9/08, Kyle Moffett [EMAIL PROTECTED] wrote:
On Jan 08, 2008, at 15:51:53, Andi Kleen wrote:
Theodore Tso [EMAIL PROTECTED] writes:
Now, there are good reasons for doing periodic checks every N
mounts and after M months. And it has to do with PC class
hardware. (Ted's aphorism: PC class hardware is cr*p).
If these reasons are good ones (some skepticism here) then the
correct way to really handle this would be to do regular background
scrubbing during runtime; ideally with metadata checksums so that
you can actually detect all corruption.
Poor man's background scrubbing:
(A) Use LVM like virtually all modern distros offer
(B) Leave some extra space in your LVM volume group (enough for 1
snapshot over the time it takes to do an FSCK).
(C) Periodically run the following scriptlet:
set -e
START=$(date +'%Y%m%d%H%M%S')
lvcreate -s -n ${VOLUME}-snap ${VG}/${VOLUME}
if nice +20 fsck -fy /dev/mapper/${VG}_${VOLUME}-snap; then
echo 'Background scrubbing succeeded!'
tune2fs -T ${START} /dev/mapper/${VG}_${VOLUME}
else
echo 'Background scrubbing failed! Reboot to fsck soon!'
tune2fs -C 16383 -T 19000101 /dev/mapper/${VG}_${VOLUME}
fi
lvremove ${VG}/${VOLUME}-snap
Basically you can fsck the offline snapshot in the background. If it
succeeds you can adjust the last checked date to the time when the
snapshot was taken and if it fails you can schedule an FSCK at next
reboot (and possibly remount the filesystem read-only or reboot
immediately).
You can do the same thing for your /boot volume, although you
probably have to manually use dmsetup since most bootloaders can't
interpret LVM volumes.
I've always been surprised that distros like RedHat which
automatically use LVM don't stuff this in their weekly or monthly
checks on desktop systems. User experience could also be
dramatically improved with automated smartd configuration and user-
interactive logging and warning messages.
But since fsck is so slow and disks are so big this whole thing is
a ticking time bomb now. e.g. it is not uncommon to require tens of
minutes or even hours of fsck time and some server that reboots
only every few months will eat that when it happens to reboot. This
means you get a quite long downtime.
My servers all have an interval-between-checks of 2-6 weeks and are
configured to run nice +20 background fsck checks during off-hours
between once every few days and once every few weeks. I also have
the max mount count numbers set to primes between 7 and 37
(depending on the filesystem) so that troubled or frequently-rebooted
systems are more frequently verified. The end result is that I
almost never have the dreaded 4-hour-fsck-on-boot problem. A drive
has certainly been fscked within the last few weeks of operation, and
I will only ever have multiple large filesystems all fscked at the
same time very rarely (gcd of their max-mount-counts).
Cheers,
Kyle Moffett
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On Wed, 09 Jan 2008 15:00:46 +0700, BuraphaLinux Server said: The help for CONFIG_DM_SNAPSHOT says it is EXPERIMENTAL (in 2.6.23.12). So this would mean that there is very high risk of software failure using snapshots. Would you want to do that for your fsck? The overall current state of EXPERIMENTAL in the tree is, quite frankly, somewhere between a complete crock and a wheelbarrow full of bovine fertilizer. There's a lot of things labeled EXPERIMENTAL that shouldn't be, and a lot of bleeding edge things that may eat your disks and cause your dog to turn green that aren't labelled EXPERIMENTAL. Having said that, I have *no* idea what state the snapshot code is in, but I have approximately zero confidence that the EXPERIMENTAL tag tells me anything actually useful about the snapshot code. pgpBeZMfh0A3V.pgp Description: PGP signature
Re: The ext3 way of journalling
On 2008-01-09 00:06 +0100, Matthias Schniedermeyer wrote: That what LABEL und UUID-Support in mount is for. That's udev shit. I don't want it. -- Tuomo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On Jan 8, 2008 7:15 PM, Theodore Tso [EMAIL PROTECTED] wrote: That will fix the this issue. The problem you are facing is that you have your hardware clock set to ticking localtime, instead of GMT. Windows ticks localtime, which is a mistake carried over from the 1970's and MS-DOS. Ticking localtime has all sorts of problems, among which is if you reboot around the transition between Summer Time (or Daylight Savings Time, depending on your contry) and normal time, the OS has no idea whether the DST adjustment has been applied or not. Actually you can force Windows to accept a hardware clock in UTC: HKEY_LOCAL_MACHINE/SYSTEMCurrentControlSetControl/TimeZoneInformation/RealTimeIsUniversal I'm using this on my dual-boot machine at home because I that stupid Daylight Savings Time change twice a year really annoyed me. So far the only downside I found is that you have to remember that the time you enter in the BIOS has to be UTC. -- blue skies, Martin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On 09.01.2008 09:56, Tuomo Valkonen wrote: On 2008-01-09 00:06 +0100, Matthias Schniedermeyer wrote: That what LABEL und UUID-Support in mount is for. That's udev shit. I don't want it. No. 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On 09.01.2008 11:21, Matthias Schniedermeyer wrote: On 09.01.2008 09:56, Tuomo Valkonen wrote: On 2008-01-09 00:06 +0100, Matthias Schniedermeyer wrote: That what LABEL und UUID-Support in mount is for. That's udev shit. I don't want it. No. To be more verbose. The 'LABEL=' is native mount turf and is much older than udev. That udev ALSO supports the same labels, by providing sym-links in /dev/disk/by-label/..., is written on another page. 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On Wed, Jan 09, 2008 at 10:54:11AM +0100, Martin Schwidefsky wrote: On Jan 8, 2008 7:15 PM, Theodore Tso [EMAIL PROTECTED] wrote: That will fix the this issue. The problem you are facing is that you have your hardware clock set to ticking localtime, instead of GMT. Windows ticks localtime, which is a mistake carried over from the 1970's and MS-DOS. Ticking localtime has all sorts of problems, among which is if you reboot around the transition between Summer Time (or Daylight Savings Time, depending on your contry) and normal time, the OS has no idea whether the DST adjustment has been applied or not. 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? And what do you set that registry value to? Just a boolean true? 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 - Ted -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On Wed, Jan 09, 2008 at 11:28:21AM +0100, Matthias Schniedermeyer wrote: On 09.01.2008 11:21, Matthias Schniedermeyer wrote: On 09.01.2008 09:56, Tuomo Valkonen wrote: On 2008-01-09 00:06 +0100, Matthias Schniedermeyer wrote: That what LABEL und UUID-Support in mount is for. That's udev shit. I don't want it. No. To be more verbose. The 'LABEL=' is native mount turf and is much older than udev. Native fsck supports it to; LABEL= and UUID= support has been in e2fsprogs since July 3rd, 1999. (Mount had it a little before then, but you needed both mount and fsck support before the feature could be used.) And it has *nothing* to do with udev - Ted -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On Wed, Jan 09, 2008 at 02:55:53AM -0500, [EMAIL PROTECTED] wrote: Does this create a snapshot of the *disk* at that moment, or does it capture disk plus still-to-be-written blocks in the cache? (Phrased differently, does it Do The Right Thing regarding blocks queued before lvcreate and blocks queued for write after lvcreate)? If the snapshot doesn't capture the blocks queued but still unwritten by kjournald and similar, then you're still hitting the same old problems that you always get when you fsck an active disk. Actually, it does better than that. For ext3 and xfs, it will take a snapshot of the filesystem in a quiscent state; that is, it will force the journal transaction to close, suspend all filesystem activity, take a snapshot of the disk as if it had been unmounted, and then allow filesystem activity to continue. So if you look at an ext3 filesystem taken in this way, you will see that the NEEDS_RECOVERY flag is not set, since the ext3 journal is empty on the snapshot. So snapshots are also a great way of doing stable backups. For the purposes of stable backups, you'll also want to quiesce your application files, particularly databases. For example, in the case of mysql, send the server the sql commands flush tables with read lock; flush logs, take the snapshot, and then after the snapshot send the server the sql command unlock tables. For more information, see: http://forums.mysql.com/read.php?26,185026,185302#msg-185302 If you do this, you will get a snapshot of your disk where *both* the database and the filesystem is at a stable state, perfect for doing a backup. - Ted -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
Vous m'avez dit récemment : On 2008-01-08, John Stoffel [EMAIL PROTECTED] wrote: Look at your filesystems, using 'tune2fs' and see if the ext3 journal is actually turned on and used. If it's not, then I can see why you're having problems on reboots. Journalling is on, but it's no use because the superblock always has corrupted last-checked time at boot. File system check forced: 31352 days since last check or so. fix your hardware clock then -- Mathieu -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On Jan 9, 2008 1:25 PM, Theodore Tso [EMAIL PROTECTED] 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On 2008-01-09, Mathieu SEGAUD [EMAIL PROTECTED] 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On Jan 9, 2008 2:53 PM, Martin Schwidefsky [EMAIL PROTECTED] wrote: On Jan 9, 2008 1:25 PM, Theodore Tso [EMAIL PROTECTED] 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On Tue, 08 Jan 2008 22:21:02 EST, Kyle Moffett said:
> lvcreate -s -n "${VOLUME}-snap" "${VG}/${VOLUME}"
> Basically you can fsck the offline snapshot in the background.
Something the lvcreate manpage is specifically not clear about is:
Does this create a snapshot of the *disk* at that moment, or does it capture
"disk plus still-to-be-written blocks in the cache"? (Phrased differently, does
it Do The Right Thing regarding "blocks queued before lvcreate" and "blocks
queued for write after lvcreate")?
If the snapshot doesn't capture the blocks queued but still unwritten by
kjournald and similar, then you're still hitting the same old problems that
you always get when you fsck an "active disk".
pgpG1ij7TWtRK.pgp
Description: PGP signature
Re: The ext3 way of journalling
On Jan 08, 2008, at 15:51:53, Andi Kleen wrote:
Theodore Tso <[EMAIL PROTECTED]> writes:
Now, there are good reasons for doing periodic checks every N
mounts and after M months. And it has to do with PC class
hardware. (Ted's aphorism: "PC class hardware is cr*p").
If these reasons are good ones (some skepticism here) then the
correct way to really handle this would be to do regular background
scrubbing during runtime; ideally with metadata checksums so that
you can actually detect all corruption.
Poor man's background scrubbing:
(A) Use LVM like virtually all modern distros offer
(B) Leave some extra space in your LVM volume group (enough for 1
snapshot over the time it takes to do an FSCK).
(C) Periodically run the following scriptlet:
set -e
START="$(date +'%Y%m%d%H%M%S')"
lvcreate -s -n "${VOLUME}-snap" "${VG}/${VOLUME}"
if nice +20 fsck -fy "/dev/mapper/${VG}_${VOLUME}-snap"; then
echo 'Background scrubbing succeeded!'
tune2fs -T "${START}" "/dev/mapper/${VG}_${VOLUME}"
else
echo 'Background scrubbing failed! Reboot to fsck soon!'
tune2fs -C 16383 -T "19000101" "/dev/mapper/${VG}_${VOLUME}"
fi
lvremove "${VG}/${VOLUME}-snap"
Basically you can fsck the offline snapshot in the background. If it
succeeds you can adjust the "last checked" date to the time when the
snapshot was taken and if it fails you can schedule an FSCK at next
reboot (and possibly remount the filesystem read-only or reboot
immediately).
You can do the same thing for your /boot volume, although you
probably have to manually use dmsetup since most bootloaders can't
interpret LVM volumes.
I've always been surprised that distros like RedHat which
automatically use LVM don't stuff this in their weekly or monthly
checks on desktop systems. User experience could also be
dramatically improved with automated smartd configuration and user-
interactive logging and warning messages.
But since fsck is so slow and disks are so big this whole thing is
a ticking time bomb now. e.g. it is not uncommon to require tens of
minutes or even hours of fsck time and some server that reboots
only every few months will eat that when it happens to reboot. This
means you get a quite long downtime.
My servers all have an "interval-between-checks" of 2-6 weeks and are
configured to run nice +20 background "fsck" checks during off-hours
between once every few days and once every few weeks. I also have
the "max mount count" numbers set to primes between 7 and 37
(depending on the filesystem) so that troubled or frequently-rebooted
systems are more frequently verified. The end result is that I
almost never have the dreaded 4-hour-fsck-on-boot problem. A drive
has certainly been fscked within the last few weeks of operation, and
I will only ever have multiple large filesystems all fscked at the
same time very rarely (gcd of their max-mount-counts).
Cheers,
Kyle Moffett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
Sorry for feeding the troll: On Die, 2008-01-08 at 17:52 +, Tuomo Valkonen wrote: > On 2008-01-08, Andre Noll <[EMAIL PROTECTED]> wrote: > > Use tune2fs to deactivate checking. > > So, a workaround is the answer to a clear bug. Typical FOSS. At least you get a simple solution for your problem: Configure your system in a slightly different way (once!) and that's it. There are far too many commercial vendors out there where you probably wouldn't get an answer at all. And if, days or weeks later. And if a - in your opinion! - wrong default value (for whatever reason) is a bug in your universe, then you should probably adopt the interpretation of words of this universe. BTW changing the default value in the source now doesn't fix the sub-optimal default value on your system. > > Modify the init scripts or use another distro. > > Another typical FOSS answer. "You have the source, you can fix it." > With what time? If you don't have the time to fix your problems, why should anyone else have the time to fix your problems? That is BTW the typical "i'm your customer and you have to obey me" attitude. Perhaps you want to buy somewhere the time to fix your problems. 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
> > 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 /bootext2defaults,noatime 0 2 ... - snip - 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
