I think that I may have spotted a minor bug in the 2.6.23 kernel and its
relationship with the EXT3 file system. I apologize in advance if I am
mistaken, reporting a problem that is already known (I did not spot it
in Bugzilla) or if I am reporting it to the wrong forum. I made the
decision a just a few weeks ago to participate by running my system on
the newest kernels and this is the first issue I have attempted to
report.
And I know that you have stumble a few times before you get the hang of
it.
I note that on the 2.6.23-rc1, rc2 and rc2-git1 systems that when I boot
I receive the following message each and every time:
/dev/sda1: Superblock last write time is in the future. FIXED
This message is repeated once for each hard drive I have (three
traditional PATA and two of the newer SATA drives)
After the message is issued the system seems to run great.
This DOES NOT happen when I am coming up with a 2.6.22.1 kernel.
A thumbnail of my configuration is:
AMD-64 Dual Core 4600+ on a MSI motherboard
2 gig of memory
3 PATA hard disks in an integrated nVidia CK804 controller
2 SAS hard disks on an integrated nVidia CK804 controller
1 IDE DVD/CD driver
2 USB attached DVD/ CD burner
nVidia GeForce 7600 PCI video card
Thank you
Chris Holvenstot wrote:
> I think that I may have spotted a minor bug in the 2.6.23 kernel and its
> relationship with the EXT3 file system. I apologize in advance if I am
> mistaken, reporting a problem that is already known (I did not spot it
> in Bugzilla) or if I am reporting it to the wrong forum. I made the
> decision a just a few weeks ago to participate by running my system on
> the newest kernels and this is the first issue I have attempted to
> report.
>
> And I know that you have stumble a few times before you get the hang of
> it.
>
> I note that on the 2.6.23-rc1, rc2 and rc2-git1 systems that when I boot
> I receive the following message each and every time:
>
> /dev/sda1: Superblock last write time is in the future. FIXED
The problem here is that your clock is wrong either at mount (boot) time or
unmount (shutdown) time. There's nothing wrong with ext3, except that it
happens to be noticing this condition.
-- Chris
> Chris Snook wrote:
>
>The problem here is that your clock is wrong either at mount (boot)
>time or unmount (shutdown) time. There's nothing wrong with ext3,
>except that it happens to be noticing this condition.
Chris -
I appreciate the response but on the face of it I do not know if I
believe that this is the answer. I am not the sharpest knife in the
drawer but the following two items still cast a doubt on the answer.
1. This happens even when the system is rebooted via the shutdown -r
command - not much time for my fat fingers to get in there and dork up
the system clock.
2. As I stated in the original note, this does NOT happen with kernel
2.6.22.1 - so far I have only seen it with the 2.6.23-rc1, rc2, and
rc2-git1 kernels.
Other than this I would say you were spot on in your analysis. Maybe
there is something I don't understand here. If so, pardon me for being
"Thick as a brick"
Chris
On 8/9/07, Chris Holvenstot <[email protected]> wrote:
> > Chris Snook wrote:
> >
> >The problem here is that your clock is wrong either at mount (boot)
> >time or unmount (shutdown) time. There's nothing wrong with ext3,
> >except that it happens to be noticing this condition.
>
> 1. This happens even when the system is rebooted via the shutdown -r
> command - not much time for my fat fingers to get in there and dork up
> the system clock.
>
> 2. As I stated in the original note, this does NOT happen with kernel
> 2.6.22.1 - so far I have only seen it with the 2.6.23-rc1, rc2, and
> rc2-git1 kernels.
>
But very likely time keeping was broken between .22 and .23-rc.
Probably not ext3.
regards,
Benoit
Benoit -
Thank you for the response - I think that you are correct in your analysis that the probem has something to do with timing and not with EXT3 itself.
However, I have been thinking this through and this cold little shadow is now hanging over my head - there was a difference in the process used to build the system between 2.6.22.1 and 2.6.23-rcx and I would like to account for it before anyone burns their valuable time chasing ghosts I may have created.,
Specifically I am refering to the process I used ot build the initrd image.
Traditionally, I used the old standby mkinitrd whcih still builds a useable image. However, when tracking down a series of messages about a failure to mount devfs devices I discovered that the approved method is now to use mkinitramfs.
And mkinitramfs did eliminate the messages about devfs just as the documentation said it would.
However, the initrd image for my 2.6.22.1 was built using the older mkinitrd command and it DOES NOT seem to have the timestamp issue buring boot. With the 2.23.6-rcx series of kernels I used the mkinitramfs process - and my 2.6.23-rcx kernels is where I am seeing the problem.
I am at work now and don't have a way of seeing the early boot messages on my system at home. When I get home this afternoon I will build the initrd image for the 2.6.22.1 system using the mkinitramfs command and I will post an updated status at that time.
Chris
-------------- Original message ----------------------
From: "Benoit Boissinot" <[email protected]>
> On 8/9/07, Chris Holvenstot <[email protected]> wrote:
> > > Chris Snook wrote:
> > >
> > >The problem here is that your clock is wrong either at mount (boot)
> > >time or unmount (shutdown) time. There's nothing wrong with ext3,
> > >except that it happens to be noticing this condition.
> >
> > 1. This happens even when the system is rebooted via the shutdown -r
> > command - not much time for my fat fingers to get in there and dork up
> > the system clock.
> >
> > 2. As I stated in the original note, this does NOT happen with kernel
> > 2.6.22.1 - so far I have only seen it with the 2.6.23-rc1, rc2, and
> > rc2-git1 kernels.
> >
>
> But very likely time keeping was broken between .22 and .23-rc.
> Probably not ext3.
>
> regards,
>
> Benoit
Benoit -
I am a little unsure of the protocol involved here but I will respond to
this, the last message I received on the topic.
As I feared, I was giving an incomplete picture with my original report
and did not even realize it.
On the systems I was getting the error on I used the mkinitramfs
command to build the initrd.img file. This was basically the 2.6.23
systems. I did this because the documentation seemed to indicate that
this would clear up the "devfs unknown file system" messages I was
getting at boot.
Which it did.
However, when I rebuilt the 2.6.22.1 kernel's initrd.img file with
mkinitramfs instead of mkinitrd the 2.6.22.1 kernel started getting the
"superblock time stamp" errors too.
So the problem is NOT with the kernel code - it appears to be either
with mkinitramfs or my process. With the way my luck has been running
of late it is likely that the fault is with my process.
So I once again thank you for your response, and apologize for what now
appears to be a false alarm. Since the initramfs tool set was provided
with the Ubuntu release I am using as a base I will try to locate
someone there to assist with this issue.
Chris
On Thu, 2007-08-09 at 14:31 +0200, Benoit Boissinot wrote:
> On 8/9/07, Chris Holvenstot <[email protected]> wrote:
> > > Chris Snook wrote:
> > >
> > >The problem here is that your clock is wrong either at mount (boot)
> > >time or unmount (shutdown) time. There's nothing wrong with ext3,
> > >except that it happens to be noticing this condition.
> >
> > 1. This happens even when the system is rebooted via the shutdown -r
> > command - not much time for my fat fingers to get in there and dork up
> > the system clock.
> >
> > 2. As I stated in the original note, this does NOT happen with kernel
> > 2.6.22.1 - so far I have only seen it with the 2.6.23-rc1, rc2, and
> > rc2-git1 kernels.
> >
>
> But very likely time keeping was broken between .22 and .23-rc.
> Probably not ext3.
>
> regards,
>
> Benoit