ext3 under MIPS?

ext3 under MIPS?

[Hartvig Ekner]

Hi,

I have been using ext3 with MIPS, and it seems to work fine during normal operations. However, when
doing an unclean shutdown things don't exactly behave the way I believe they should. Does anybody
know how the ext3 recovery is supposed to work?

Basically I just reset the system mid-stream to see what happens. This means the rc.sysinit "control
file "/.autofsck" is on the filesystem to indicate an unclean shutdown. During the next boot I get:

... stuff deleted

ttyS02 at 0xb1300000 (irq = 2) is a 16550
ttyS03 at 0xb1400000 (irq = 3) is a 16550
EXT3-fs: INFO: recovery required on readonly filesystem.
EXT3-fs: write access will be enabled during recovery.
kjournald starting.  Commit interval 5 seconds
EXT3-fs: recovery complete.
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 64k freed
Algorithmics/MIPS FPU Emulator v1.5
INIT: version 2.84 booting

So, it seems the kernel ext3 filesystem code runs some kind of recovery based on the
journal prior to the actual mount of / occurring, which is exactly what I would expect
to happen, right?

Then bootup continues with:


               Welcome to Red Hat Linux
                Press 'I' to enter interactive startup.
Mounting proc filesystem:  [  OK  ]
Configuring kernel parameters:  [  OK  ]
Cannot access the Hardware Clock via any known method.
Use the --debug option to see the details of our search for an access method.
Setting clock  (localtime): Thu Jan  1 01:00:13 CET 1970 [  OK  ]
Activating swap partitions:  [  OK  ]
Setting hostname copau01:  [  OK  ]
modprobe: Can't open dependencies file /lib/modules/2.4.21-pre4/modules.dep (No
such file or directory)
modprobe: Can't open dependencies file /lib/modules/2.4.21-pre4/modules.dep (No
such file or directory)
Your system appears to have shut down uncleanly
Press Y within 3 seconds to force file system integrity check...y
Checking root filesystem
/dev/hdc2: Inodes that were part of a corrupted orphan linked list found.

/dev/hdc2: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
        (i.e., without -a or -p options)
[/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a -f /dev/hdc2

[FAILED]

*** An error occurred during the file system check.
*** Dropping you to a shell; the system will reboot
*** when you leave the shell.
Give root password for maintenance
(or type Control-D for normal startup):


So can somebody tell me what the heck just happened? After the ext3 recovery done before the mount,
.autofsck is still on the disk, so the rc.sysinit script of course assumes the shutdown was unclean,
and pops the 5-second question. However, if I to be safe push "Y" here to get my filesystem check (which
I guess should be unnecessary, due to the ext3 recovery just run, right?), strange things happen and
fsck reports the "corrupted orphan list... " error.

Is there something wrong here, or how should the system behave?

/Hartvig

Re: ext3 under MIPS?

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 4560 bytes --]

On Thu, 2003-04-10 12:24:17 +0200, Hartvig Ekner <hartvig@ekner.info>
wrote in message <3E954651.C7AECB90@ekner.info>:
> Hi,
> 
> I have been using ext3 with MIPS, and it seems to work fine during normal operations. However, when
> doing an unclean shutdown things don't exactly behave the way I believe they should. Does anybody
> know how the ext3 recovery is supposed to work?
> 
> Basically I just reset the system mid-stream to see what happens. This means the rc.sysinit "control
> file "/.autofsck" is on the filesystem to indicate an unclean shutdown. During the next boot I get:
> 
> ... stuff deleted
> 
> ttyS02 at 0xb1300000 (irq = 2) is a 16550
> ttyS03 at 0xb1400000 (irq = 3) is a 16550
> EXT3-fs: INFO: recovery required on readonly filesystem.
> EXT3-fs: write access will be enabled during recovery.
> kjournald starting.  Commit interval 5 seconds
> EXT3-fs: recovery complete.
> EXT3-fs: mounted filesystem with ordered data mode.

It recovers the journal. That's fine (and works as expected).

> VFS: Mounted root (ext3 filesystem) readonly.
> Freeing unused kernel memory: 64k freed
> Algorithmics/MIPS FPU Emulator v1.5
> INIT: version 2.84 booting
> 
> So, it seems the kernel ext3 filesystem code runs some kind of recovery based on the
> journal prior to the actual mount of / occurring, which is exactly what I would expect
> to happen, right?

Jupp.

> Then bootup continues with:
> 
> 
>                Welcome to Red Hat Linux
>                 Press 'I' to enter interactive startup.
> Mounting proc filesystem:  [  OK  ]
> Configuring kernel parameters:  [  OK  ]
> Cannot access the Hardware Clock via any known method.
> Use the --debug option to see the details of our search for an access method.
> Setting clock  (localtime): Thu Jan  1 01:00:13 CET 1970 [  OK  ]
> Activating swap partitions:  [  OK  ]
> Setting hostname copau01:  [  OK  ]
> modprobe: Can't open dependencies file /lib/modules/2.4.21-pre4/modules.dep (No
> such file or directory)
> modprobe: Can't open dependencies file /lib/modules/2.4.21-pre4/modules.dep (No
> such file or directory)
> Your system appears to have shut down uncleanly
> Press Y within 3 seconds to force file system integrity check...y
> Checking root filesystem
> /dev/hdc2: Inodes that were part of a corrupted orphan linked list found.
> 
> /dev/hdc2: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
>         (i.e., without -a or -p options)
> [/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a -f /dev/hdc2
> 
> [FAILED]
> 
> *** An error occurred during the file system check.
> *** Dropping you to a shell; the system will reboot
> *** when you leave the shell.
> Give root password for maintenance
> (or type Control-D for normal startup):
> 
> So can somebody tell me what the heck just happened? After the ext3 recovery done before the mount,
> .autofsck is still on the disk, so the rc.sysinit script of course assumes the shutdown was unclean,

This ".autofsck" file seems to be a userland approach to detect a system
which wasn't shutted down completely. Even this is fine. What's *not*
okay is that there are still errors remaining. It seems your filesystem
has been damaged before (and in no means which could have been handled
by the journal).

> and pops the 5-second question. However, if I to be safe push "Y" here to get my filesystem check (which
> I guess should be unnecessary, due to the ext3 recovery just run, right?), strange things happen and
> fsck reports the "corrupted orphan list... " error.

Wrong. The journal should prevent you from actually loosing things at
hard-power-off situations. It does *not* cover things like silent data
corruption, which may have lead to this breakage.

> Is there something wrong here, or how should the system behave?

Everything with journal recovery is fine here. The failing fsck is a
different problem (a journal doesn't preven you to do a fsck at a
regular basis. It's only to not be forced to to it if you don't have the
time to do this *now* (on crash)).

So there seems do be some corruption (caused by whatever) going on at
your system:-(

Watch out if this happens again soon after you've completed the fsck.

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
      ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: ext3 under MIPS?

[Karsten Merker]

On Thu, Apr 10, 2003 at 12:24:17PM +0200, Hartvig Ekner wrote:

> I have been using ext3 with MIPS, and it seems to work fine during normal operations. However, when
> doing an unclean shutdown things don't exactly behave the way I believe they should. Does anybody
> know how the ext3 recovery is supposed to work?

Hm, at least ext3 has worked properly on a DECstation. I had a hard crash
and the journal recovery seemed to have worked. I got no fsck-errors.

HTH,
Karsten
-- 
#include <standard_disclaimer>
Nach Paragraph 28 Abs. 3 Bundesdatenschutzgesetz widerspreche ich der Nutzung
oder Uebermittlung meiner Daten fuer Werbezwecke oder fuer die Markt- oder
Meinungsforschung.

Re: ext3 under MIPS?

[Hartvig Ekner]

Jan-Benedict Glaw wrote:

> >
> > So can somebody tell me what the heck just happened? After the ext3 recovery done before the mount,
> > .autofsck is still on the disk, so the rc.sysinit script of course assumes the shutdown was unclean,
>
> This ".autofsck" file seems to be a userland approach to detect a system
> which wasn't shutted down completely. Even this is fine. What's *not*
> okay is that there are still errors remaining. It seems your filesystem
> has been damaged before (and in no means which could have been handled
> by the journal).
>
> > and pops the 5-second question. However, if I to be safe push "Y" here to get my filesystem check (which
> > I guess should be unnecessary, due to the ext3 recovery just run, right?), strange things happen and
> > fsck reports the "corrupted orphan list... " error.
>
> Wrong. The journal should prevent you from actually loosing things at
> hard-power-off situations. It does *not* cover things like silent data
> corruption, which may have lead to this breakage.
>
> > Is there something wrong here, or how should the system behave?
>
> Everything with journal recovery is fine here. The failing fsck is a
> different problem (a journal doesn't preven you to do a fsck at a
> regular basis. It's only to not be forced to to it if you don't have the
> time to do this *now* (on crash)).
>
> So there seems do be some corruption (caused by whatever) going on at
> your system:-(
>
> Watch out if this happens again soon after you've completed the fsck.
>

I can reproduce this anytime by just pushing the reset button and checking the filesystem
at reboot after ext3 recovery has run. However, if I just do regular fsck's (without unclean
shutdowns) nothing seems to be wrong. So I am pretty sure it is something which
goes wrong in conjunction with the unclean shutdowns.

Is ext3 journal recovery really supposed to recover everything to a state where fsck returns no
errors, or is it potentially leaving non-fatal errors in the filesystem (e.g. lost inodes which just
reduces capacity, but does not cause further corruption if the filesystem is used) which will then
be picked up by a later fsck when one has time to run it?

What does the error "Inodes that were part of a corrupted orphan linked list found." actually
mean? Is this a fatal error, or a non-critical error along the lines I described above (an error
which does not get any worse if the filesystem is used)?

Is there anybody with ext3 up and running who would volunteer to do a couple of unclean
shutdowns and see if the recovery works without any fsck errors present afterwards?

/Hartvig

Re: ext3 under MIPS?

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 3021 bytes --]

On Thu, 2003-04-10 22:17:49 +0200, Hartvig Ekner <hartvig@ekner.info>
wrote in message <3E95D16D.1671BA5A@ekner.info>:
> Jan-Benedict Glaw wrote:

[ext3 fs corruption after journal recovery]

> I can reproduce this anytime by just pushing the reset button and checking the filesystem
> at reboot after ext3 recovery has run. However, if I just do regular fsck's (without unclean
> shutdowns) nothing seems to be wrong. So I am pretty sure it is something which

How do you invoce fsck?

> goes wrong in conjunction with the unclean shutdowns.

That's bad then:-(

> Is ext3 journal recovery really supposed to recover everything to a state where fsck returns no
> errors, or is it potentially leaving non-fatal errors in the filesystem (e.g. lost inodes which just

No. The concept is different.

Such a journal will log things like:

- File creation/deletion
- Owner/timestamp/access changes

These informations are restored during journal recovery. Most
filesystems do /not/ store the actual data you're writing to a file into
the journal. So, after you've issued a write() and presses the reset
button, the journal contains the new filesize, but by possibility
__not__ the data you've written to the file. So file size is okay, but
file content isn't. It's basically the job of the journal to keep your
filesystem intact, but not your data.

If you do this:

	- Boot with / mounted r/o
	- e2fsck -f /dev/your-root-device
	- Reset
	- Boot with / mounted r/w
	- Write something
	- Reset

You shouldn't see fsck failing (except it may replay the journal for
filesystems which hadn't been mounted on /).

If you see corruption here (ie. fsck finds problems after replaying the
journal), something is serverely broken.


> reduces capacity, but does not cause further corruption if the filesystem is used) which will then
> be picked up by a later fsck when one has time to run it?

It should present you a f/s with no *known* problems. If corruption
(broken DMA transfers, ...) took place, this hasn't eventually logget
into the journal so this isn't recovered:-)

> What does the error "Inodes that were part of a corrupted orphan linked list found." actually
> mean? Is this a fatal error, or a non-critical error along the lines I described above (an error
> which does not get any worse if the filesystem is used)?

I think this basically means that fsck found files of a (destroyed)
directory. But for exact statements here, read e2fsck's sources...

> Is there anybody with ext3 up and running who would volunteer to do a couple of unclean
> shutdowns and see if the recovery works without any fsck errors present afterwards?

:-)

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
      ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: ext3 under MIPS?

[Brian Murphy]

Hartvig Ekner wrote:

>Is there anybody with ext3 up and running who would volunteer to do a couple of unclean
>shutdowns and see if the recovery works without any fsck errors present afterwards?
>
>  
>

Works every time here:

EXT3-fs: INFO: recovery required on readonly 
filesystem.                       
EXT3-fs: write access will be enabled during 
recovery.                         
kjournald starting.  Commit interval 5 
seconds                                 
EXT3-fs: recovery 
complete.                                                    
EXT3-fs: mounted filesystem with ordered data 
mode.                            
VFS: Mounted root (ext3 filesystem) 
readonly.                                  
Freeing unused kernel memory: 64k 
freed                                        
modprobe: modprobe: Can't open dependencies file 
/lib/modules/2.4.21-pre4/modul)
INIT: version 2.84 
booting                                                     
Activating 
swap.                                                               
Adding Swap: 131532k swap-space (priority 
-1)                                  
Checking root file 
system...                                                   
fsck 1.27 
(8-Mar-2002)                                                         
/dev/hda2: clean, 34571/1235456 files, 175807/2469096 
blocks                   
EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,2), internal 
journal              
System time was Fri Apr 11 07:45:01 UTC 
2003.                                  

mqpro:~# e2fsck 
/dev/hda2                                                      
e2fsck 1.27 
(8-Mar-2002)                                                       
/dev/hda2: clean, 34565/1235456 files, 175809/2469096 
blocks                   
mqpro:~# e2fsck -f 
/dev/hda2                                                   
e2fsck 1.27 
(8-Mar-2002)                                                       
Pass 1: Checking inodes, blocks, and 
sizes                                     
Pass 2: Checking directory 
structure                                           
Pass 3: Checking directory 
connectivity                                        
Pass 4: Checking reference 
counts                                              
Pass 5: Checking group summary 
information                                     
/dev/hda2: 34565/1235456 files (1.1% non-contiguous), 175809/2469096 
blocks    
mqpro:~#


/Brian

Re: ext3 under MIPS?

[Brian Murphy]

Kevin D. Kissell wrote:

>Could you guys please specify which endianness you're running?
>  
>
Little.

/Brian

Re: ext3 under MIPS?

[Kevin D. Kissell]

Could you guys please specify which endianness you're running?
This is just the sort of situation where that can end up being an issue.

----- Original Message ----- 
From: "Brian Murphy" <brian@murphy.dk>
To: "Hartvig Ekner" <hartvig@ekner.info>
Cc: <linux-mips@linux-mips.org>
Sent: Friday, April 11, 2003 9:50 AM
Subject: Re: ext3 under MIPS?


> Hartvig Ekner wrote:
> 
> >Is there anybody with ext3 up and running who would volunteer to do a couple of unclean
> >shutdowns and see if the recovery works without any fsck errors present afterwards?
> >
> >  
> >
> 
> Works every time here:
> 
> EXT3-fs: INFO: recovery required on readonly 
> filesystem.                       
> EXT3-fs: write access will be enabled during 
> recovery.                         
> kjournald starting.  Commit interval 5 
> seconds                                 
> EXT3-fs: recovery 
> complete.                                                    
> EXT3-fs: mounted filesystem with ordered data 
> mode.                            
> VFS: Mounted root (ext3 filesystem) 
> readonly.                                  
> Freeing unused kernel memory: 64k 
> freed                                        
> modprobe: modprobe: Can't open dependencies file 
> /lib/modules/2.4.21-pre4/modul)
> INIT: version 2.84 
> booting                                                     
> Activating 
> swap.                                                               
> Adding Swap: 131532k swap-space (priority 
> -1)                                  
> Checking root file 
> system...                                                   
> fsck 1.27 
> (8-Mar-2002)                                                         
> /dev/hda2: clean, 34571/1235456 files, 175807/2469096 
> blocks                   
> EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,2), internal 
> journal              
> System time was Fri Apr 11 07:45:01 UTC 
> 2003.                                  
> 
> mqpro:~# e2fsck 
> /dev/hda2                                                      
> e2fsck 1.27 
> (8-Mar-2002)                                                       
> /dev/hda2: clean, 34565/1235456 files, 175809/2469096 
> blocks                   
> mqpro:~# e2fsck -f 
> /dev/hda2                                                   
> e2fsck 1.27 
> (8-Mar-2002)                                                       
> Pass 1: Checking inodes, blocks, and 
> sizes                                     
> Pass 2: Checking directory 
> structure                                           
> Pass 3: Checking directory 
> connectivity                                        
> Pass 4: Checking reference 
> counts                                              
> Pass 5: Checking group summary 
> information                                     
> /dev/hda2: 34565/1235456 files (1.1% non-contiguous), 175809/2469096 
> blocks    
> mqpro:~#
> 
> 
> /Brian
> 
> 
> 

Re: ext3 under MIPS?

[Kevin D. Kissell]

Could you guys please specify which endianness you're running?
This is just the sort of situation where that can end up being an issue.

----- Original Message ----- 
From: "Brian Murphy" <brian@murphy.dk>
To: "Hartvig Ekner" <hartvig@ekner.info>
Cc: <linux-mips@linux-mips.org>
Sent: Friday, April 11, 2003 9:50 AM
Subject: Re: ext3 under MIPS?


> Hartvig Ekner wrote:
> 
> >Is there anybody with ext3 up and running who would volunteer to do a couple of unclean
> >shutdowns and see if the recovery works without any fsck errors present afterwards?
> >
> >  
> >
> 
> Works every time here:
> 
> EXT3-fs: INFO: recovery required on readonly 
> filesystem.                       
> EXT3-fs: write access will be enabled during 
> recovery.                         
> kjournald starting.  Commit interval 5 
> seconds                                 
> EXT3-fs: recovery 
> complete.                                                    
> EXT3-fs: mounted filesystem with ordered data 
> mode.                            
> VFS: Mounted root (ext3 filesystem) 
> readonly.                                  
> Freeing unused kernel memory: 64k 
> freed                                        
> modprobe: modprobe: Can't open dependencies file 
> /lib/modules/2.4.21-pre4/modul)
> INIT: version 2.84 
> booting                                                     
> Activating 
> swap.                                                               
> Adding Swap: 131532k swap-space (priority 
> -1)                                  
> Checking root file 
> system...                                                   
> fsck 1.27 
> (8-Mar-2002)                                                         
> /dev/hda2: clean, 34571/1235456 files, 175807/2469096 
> blocks                   
> EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,2), internal 
> journal              
> System time was Fri Apr 11 07:45:01 UTC 
> 2003.                                  
> 
> mqpro:~# e2fsck 
> /dev/hda2                                                      
> e2fsck 1.27 
> (8-Mar-2002)                                                       
> /dev/hda2: clean, 34565/1235456 files, 175809/2469096 
> blocks                   
> mqpro:~# e2fsck -f 
> /dev/hda2                                                   
> e2fsck 1.27 
> (8-Mar-2002)                                                       
> Pass 1: Checking inodes, blocks, and 
> sizes                                     
> Pass 2: Checking directory 
> structure                                           
> Pass 3: Checking directory 
> connectivity                                        
> Pass 4: Checking reference 
> counts                                              
> Pass 5: Checking group summary 
> information                                     
> /dev/hda2: 34565/1235456 files (1.1% non-contiguous), 175809/2469096 
> blocks    
> mqpro:~#
> 
> 
> /Brian
> 
> 
> 

Re: ext3 under MIPS?

[Hartvig Ekner]

I think you are right, something else is wrong, very wrong, probably not related to ext3 recovery at all.
It might be as simple as the way I converted the root ext2 to ext3 was done wrongly. Take a look
here:

When the system starts up (after the fake crash) with root in RO mode, I get (as previously
explained):

Checking root filesystem
/dev/hdc2: Inodes that were part of a corrupted orphan linked list found.  [/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a -f /dev/hdc2
/dev/hdc2: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
        (i.e., without -a or -p options)
xxx The return code from fsck was 4
[FAILED]

*** An error occurred during the file system check.
*** Dropping you to a shell; the system will reboot
*** when you leave the shell.
Give root password for maintenance
(or type Control-D for normal startup):

I then login and run the fsck manually:

(Repair filesystem) 1 # fsck.ext3 -y /dev/hdc2
e2fsck 1.27 (8-Mar-2002)
/dev/hdc2 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Inodes that were part of a corrupted orphan linked list found.  Fix? yes
Inode 653 was part of the orphaned inode list.  FIXED.
Inode 33040 was part of the orphaned inode list.  FIXED.
... stuff deleted
Inode 434395 was part of the orphaned inode list.  FIXED.
Inode 465769 was part of the orphaned inode list.  FIXED.
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

/dev/hdc2: ***** FILE SYSTEM WAS MODIFIED *****
/dev/hdc2: 43937/513024 files (0.1% non-contiguous), 188654/1024002 blocks

Now one would believe the disk is fine, as in eg:

(Repair filesystem) 2 # fsck.ext3 -y /dev/hdc2
e2fsck 1.27 (8-Mar-2002)
/dev/hdc2: clean, 43937/513024 files, 188654/1024002 blocks

So, I thought everything was fine. WRONG. If I force another filesystem check, I get:

(Repair filesystem) 11 # fsck.ext3 -y -f /dev/hdc2
e2fsck 1.27 (8-Mar-2002)
Pass 1: Checking inodes, blocks, and sizes
Inodes that were part of a corrupted orphan linked list found.  Fix? yes

Inode 653 was part of the orphaned inode list.  FIXED.
Inode 33040 was part of the orphaned inode list.  FIXED.
Inode 33225 was part of the orphaned inode list.  FIXED.
Inode 70198 was part of the orphaned inode list.  FIXED.
Inode 129443 was part of the orphaned inode list.  FIXED.
...
Inode 434395 was part of the orphaned inode list.  FIXED.
Inode 465769 was part of the orphaned inode list.  FIXED.
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

/dev/hdc2: ***** FILE SYSTEM WAS MODIFIED *****
/dev/hdc2: 43937/513024 files (0.1% non-contiguous), 188654/1024002 blocks

In short, exactly the same errors again. And if I force the check again, I get 100% identical
errors again. So something is fundamentally broken. Looking to what the system believes it has mounted:

(Repair filesystem) 14 # mount -l
/dev/hdc2 on / type ext3 (rw) []            <========= Is this really right?
none on /proc type proc (rw)

(Repair filesystem) 20 # more /proc/mounts
rootfs / rootfs rw 0 0                <=========== Is this really right?
/dev/root / ext3 ro 0 0
/proc /proc proc rw 0 0

Now I'm beginning to suspect that my conversion from ext2 to ext3 (tune2fs -j on a running system, and
just modifying ext2 to ext3 in fstab) is somehow not correct, or something else which I overlooked?
How did you guys (the ones without any ext3 problems) initially get the ext3 root partition in place
(was it born as ext3 or converted from ext2?) and anything special one needs to do in fstab?

/Hartvig


Jan-Benedict Glaw wrote:

> On Thu, 2003-04-10 22:17:49 +0200, Hartvig Ekner <hartvig@ekner.info>
> wrote in message <3E95D16D.1671BA5A@ekner.info>:
> > Jan-Benedict Glaw wrote:
>
> [ext3 fs corruption after journal recovery]
>
> > I can reproduce this anytime by just pushing the reset button and checking the filesystem
> > at reboot after ext3 recovery has run. However, if I just do regular fsck's (without unclean
> > shutdowns) nothing seems to be wrong. So I am pretty sure it is something which
>
> How do you invoce fsck?
>
> > goes wrong in conjunction with the unclean shutdowns.
>
> That's bad then:-(
>
> > Is ext3 journal recovery really supposed to recover everything to a state where fsck returns no
> > errors, or is it potentially leaving non-fatal errors in the filesystem (e.g. lost inodes which just
>
> No. The concept is different.
>
> Such a journal will log things like:
>
> - File creation/deletion
> - Owner/timestamp/access changes
>
> These informations are restored during journal recovery. Most
> filesystems do /not/ store the actual data you're writing to a file into
> the journal. So, after you've issued a write() and presses the reset
> button, the journal contains the new filesize, but by possibility
> __not__ the data you've written to the file. So file size is okay, but
> file content isn't. It's basically the job of the journal to keep your
> filesystem intact, but not your data.
>
> If you do this:
>
>         - Boot with / mounted r/o
>         - e2fsck -f /dev/your-root-device
>         - Reset
>         - Boot with / mounted r/w
>         - Write something
>         - Reset
>
> You shouldn't see fsck failing (except it may replay the journal for
> filesystems which hadn't been mounted on /).
>
> If you see corruption here (ie. fsck finds problems after replaying the
> journal), something is serverely broken.
>
> > reduces capacity, but does not cause further corruption if the filesystem is used) which will then
> > be picked up by a later fsck when one has time to run it?
>
> It should present you a f/s with no *known* problems. If corruption
> (broken DMA transfers, ...) took place, this hasn't eventually logget
> into the journal so this isn't recovered:-)
>
> > What does the error "Inodes that were part of a corrupted orphan linked list found." actually
> > mean? Is this a fatal error, or a non-critical error along the lines I described above (an error
> > which does not get any worse if the filesystem is used)?
>
> I think this basically means that fsck found files of a (destroyed)
> directory. But for exact statements here, read e2fsck's sources...
>
> > Is there anybody with ext3 up and running who would volunteer to do a couple of unclean
> > shutdowns and see if the recovery works without any fsck errors present afterwards?
>
> :-)
>
> MfG, JBG

Re: ext3 under MIPS?

[Brian Murphy]

Hartvig Ekner wrote:

>Now I'm beginning to suspect that my conversion from ext2 to ext3 (tune2fs -j on a running system, and
>just modifying ext2 to ext3 in fstab) is somehow not correct, or something else which I overlooked?
>How did you guys (the ones without any ext3 problems) initially get the ext3 root partition in place
>(was it born as ext3 or converted from ext2?) and anything special one needs to do in fstab?
>
>  
>
I did the same: "tune2fs -j" also on a running system, nothing special 
in fstab:

/dev/hda2       /               ext3            defaults        0       1

/Brian

Re: ext3 under MIPS?

[Karsten Merker]

On Fri, Apr 11, 2003 at 12:05:22PM +0200, Hartvig Ekner wrote:

> Now I'm beginning to suspect that my conversion from ext2 to ext3 (tune2fs -j on a running system, and
> just modifying ext2 to ext3 in fstab) is somehow not correct, or something else which I overlooked?
> How did you guys (the ones without any ext3 problems) initially get the ext3 root partition in place
> (was it born as ext3 or converted from ext2?) and anything special one needs to do in fstab?

On my mipsel box it was created as ext3 from scratch, on i386 it was
converted from ext2.

Regards,
Karsten
-- 
#include <standard_disclaimer>
Nach Paragraph 28 Abs. 3 Bundesdatenschutzgesetz widerspreche ich der Nutzung
oder Uebermittlung meiner Daten fuer Werbezwecke oder fuer die Markt- oder
Meinungsforschung.

Re: ext3 under MIPS?

[Karsten Merker]

On Fri, Apr 11, 2003 at 10:28:31AM +0200, Kevin D. Kissell wrote:
> Could you guys please specify which endianness you're running?
> This is just the sort of situation where that can end up being an issue.

Little endian.

Regards,
Karsten
-- 
#include <standard_disclaimer>
Nach Paragraph 28 Abs. 3 Bundesdatenschutzgesetz widerspreche ich der Nutzung
oder Uebermittlung meiner Daten fuer Werbezwecke oder fuer die Markt- oder
Meinungsforschung.