2.5.0 breakage even with fix?

2.5.0 breakage even with fix?

[Petr Vandrovec]

Hi Al,
  I'm now running 2.5.0 with fix you posted - and now during dselect
run I received:

Unpacking replacement manpages ...
EXT2-fs error (device ide0(3,3)): ext2_check_page: bad entry in directory
  #3801539: unaligned directory entry - offset=0, inode=1801675088,
  rec_len=26465, name_len=101
Remounting filesystem read-only
rm: cannot remove directory `/var/lib/dpkg/tmp.ci': Read-only file system
...

and system is obviously unusable. I'll probably reboot and run fsck again.
If someone can show me how I can dump contents of some inode by number
(and not by name) in debugfs, I can look into inode itself... I found
only 'ncheck', to convert number to name, and this is running and running...

System was running 2.5.0 without patch for some time, but I followed
your guidelines for rebooting:

fuser -k /
sync
mount -o remount,ro /
sync
reboot

After reboot fsck was NOT run, so it is possible that there
might be some corruption - but I ran fsck on my non-root partition
after boot, and it did not show any problems.
                                        Thanks,
                                                    Petr Vandrovec
                                                    vandrove@vc.cvut.cz
                                                    
                                                    

Re: 2.5.0 breakage even with fix?

[Alexander Viro]

On Sat, 24 Nov 2001, Petr Vandrovec wrote:

> After reboot fsck was NOT run, so it is possible that there
> might be some corruption - but I ran fsck on my non-root partition
> after boot, and it did not show any problems.

fsck -f

Filesystem _is_ marked clean, so unless you do forced fsck no checks
are done.

Moreover, attempt to work with corrupted fs can break in very interesting
ways, so unless you do fsck -f even correct kernel (be it patched 2.4.15
or something earlier than 2.4.15-pre9) will not help.

Re: 2.5.0 breakage even with fix?

[Robert Boermans]

Alexander Viro wrote:

> fsck -f
>
> Filesystem _is_ marked clean, so unless you do forced fsck no checks
> are done.
>
> Moreover, attempt to work with corrupted fs can break in very interesting
> ways, so unless you do fsck -f even correct kernel (be it patched 2.4.15
> or something earlier than 2.4.15-pre9) will not help.

If the filesystem is marked clean, does that mean that people with
journalling file systems are fscked? (since there might be no journal entry
of what hasn't finished.)

just guessing, I don't know how these work, but if ext2 gets the 'clean' bit
set, i can imagine the journaling file systems refusing to check anything...

Robert.

Re: 2.5.0 breakage even with fix?

[Alexander Viro]

On Sun, 25 Nov 2001, Robert Boermans wrote:

> If the filesystem is marked clean, does that mean that people with
> journalling file systems are fscked? (since there might be no journal entry
> of what hasn't finished.)

Well, if filesystem doesn't have a recovery tool that would allow forced
check mode - you _are_ screwed.  As you will be again and again if you get
memory corruption/driver bugs/fs bugs/RAID bugs/physical disk problems/etc.

Again, if filesystem trusts clear bit to the extent that you have no way
to convince it that checks _are_ needed - it's unfit for any serious use.
I suspect that by now everybody had learnt that much - that used to be
a permanent source of problems with early journalling filesystems and AFAIK
all of them had been fixed since then.

Re: 2.5.0 breakage even with fix?

[Jeff Merkey]

Al,

I am not seeing any more breakage with this fix with NWFS.

Jeff

----- Original Message -----
From: "Alexander Viro" <viro@math.psu.edu>
To: "Robert Boermans" <boermans@tfn.net>
Cc: "Petr Vandrovec" <VANDROVE@vc.cvut.cz>; <linux-kernel@vger.kernel.org>
Sent: Saturday, November 24, 2001 4:03 PM
Subject: Re: 2.5.0 breakage even with fix?


>
>
> On Sun, 25 Nov 2001, Robert Boermans wrote:
>
> > If the filesystem is marked clean, does that mean that people with
> > journalling file systems are fscked? (since there might be no journal
entry
> > of what hasn't finished.)
>
> Well, if filesystem doesn't have a recovery tool that would allow forced
> check mode - you _are_ screwed.  As you will be again and again if you get
> memory corruption/driver bugs/fs bugs/RAID bugs/physical disk
problems/etc.
>
> Again, if filesystem trusts clear bit to the extent that you have no way
> to convince it that checks _are_ needed - it's unfit for any serious use.
> I suspect that by now everybody had learnt that much - that used to be
> a permanent source of problems with early journalling filesystems and
AFAIK
> all of them had been fixed since then.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.5.0 breakage even with fix?

[Andreas Dilger]

On Nov 24, 2001  00:54 +0000, Petr Vandrovec wrote:
>   I'm now running 2.5.0 with fix you posted - and now during dselect
> run I received:
> 
> Unpacking replacement manpages ...
> EXT2-fs error (device ide0(3,3)): ext2_check_page: bad entry in directory
>   #3801539: unaligned directory entry - offset=0, inode=1801675088,
>   rec_len=26465, name_len=101
> Remounting filesystem read-only
> rm: cannot remove directory `/var/lib/dpkg/tmp.ci': Read-only file system

Did you run e2fsck -f after running unpatched 2.4.15/2.5.0?  This may be
left-over garbage from the other problem.

> and system is obviously unusable. I'll probably reboot and run fsck again.
> If someone can show me how I can dump contents of some inode by number
> (and not by name) in debugfs, I can look into inode itself... I found
> only 'ncheck', to convert number to name, and this is running and running...

debugfs> stat <inum>
debugfs> dump <inum> /tmp/file


Note that you need to include the <> around the inode number.

> System was running 2.5.0 without patch for some time, but I followed
> your guidelines for rebooting:
> 
> fuser -k /
> sync
> mount -o remount,ro /
> sync
> reboot
> 
> After reboot fsck was NOT run, so it is possible that there
> might be some corruption - but I ran fsck on my non-root partition
> after boot, and it did not show any problems.

Ah, yes.  Definitely sounds like left over corruption.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

Re: 2.5.0 breakage even with fix?

[Petr Vandrovec]

On 24 Nov 01 at 0:54, viro@math.psu.edu wrote:
> Hi Al,
>   I'm now running 2.5.0 with fix you posted - and now during dselect
> run I received:
> 
> Unpacking replacement manpages ...
> EXT2-fs error (device ide0(3,3)): ext2_check_page: bad entry in directory
>   #3801539: unaligned directory entry - offset=0, inode=1801675088,
>   rec_len=26465, name_len=101
> Remounting filesystem read-only
> rm: cannot remove directory `/var/lib/dpkg/tmp.ci': Read-only file system

Well, ncheck finished.

debugfs: stat /var/lib/dpkg/tmp.ci
Inode: 3801539  Type: directory  Mode: 0755  Flags: 0x0  Generation: 537829
User:     0   Group:   0    Size: 4096
File ACL: 0   Directory ACL: 0
Links: 2  Blockcount: 8
Fragment: Address: 0   Number: 0   Size: 0
ctime: 0x3bfede00 -- Sat Nov 24 00:38:40 2001
atime: dtto
mtime: dtto
BLOCKS:
(0):7603845
TOTAL: 1

debugfs: cat /var/lib/dpkg/tmp.ci
Package: diff
Version: 2.7-28
Section: base
Priority: required
Architecture: i386
...

It does not look like a directory to me. Unfortunately, as we
do not have coherent /dev/hda3 cache, I have no idea how to read
real contents of /var/lib/dpkg/tmp.ci, but
ls -l /var/lib/dpkg/tmp.ci/ reemited error message about
ext2-fs error, so I think that it is real problem, and my tmp.ci directory
contains some file contents instead. And I'm 100% sure that
/var/lib/dpkg/tmp.ci was created with patched kernel :-(
                                            Petr Vandrovec
                                            vandrove@vc.cvut.cz