Filesystem corruption
Has anyone seen problems with fsck on the latest 2.4.0 kernel ? My filesystem gets corrupted from time to time when I use the latest 2.4.0 kernel.
/Carsten
--
_ _ ____ ___ Carsten Langgaard Mailto:[email protected] |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com
Quoted 5 lines · Carsten Langgaard
Has anyone seen problems with fsck on the latest 2.4.0 kernel ? My filesystem gets corrupted from time to time when I use the latest 2.4.0 kernel.
Hmm - nope - 2.4.0 Bigendian here
resume:~# uptime 3:50pm up 6 days, 10 min, 1 user, load average: 0.00, 0.00, 0.00 resume:~# uname -a Linux resume.rfc822.org 2.4.0 #3 Thu Jan 25 16:25:23 CET 2001 mips unknown
Flo
Signature · 2 lines
Florian Lohoff [email protected] +49-5201-669912 Why is it called "common sense" when nobody seems to have any?
Try use fsck.
/Carsten
Quoted 18 lines · Florian Lohoff
Quoted 5 lines · Carsten Langgaard
Has anyone seen problems with fsck on the latest 2.4.0 kernel ? My filesystem gets corrupted from time to time when I use the latest 2.4.0 kernel.
Hmm - nope - 2.4.0 Bigendian here
resume:~# uptime 3:50pm up 6 days, 10 min, 1 user, load average: 0.00, 0.00, 0.00 resume:~# uname -a Linux resume.rfc822.org 2.4.0 #3 Thu Jan 25 16:25:23 CET 2001 mips unknownFlo
--
Florian Lohoff [email protected] +49-5201-669912
Why is it called "common sense" when nobody seems to have any?
Quoted 3 lines · Carsten Langgaard
Try use fsck.
*Urgs* Trouble ...
resume:~# df Filesystem 1k-blocks Used Available Use% Mounted on /dev/sda1 2074328 1360061 607040 70% / /dev/sde1 3839092 217476 3426600 6% /chroot /dev/sdb1 4003992 3708044 89260 98% /home2 /dev/sdc1 4003992 449472 3347832 12% /home3 /dev/sdd1 4003992 1134620 2662684 30% /ftp.rfc822.org resume:~# umount /ftp.rfc822.org/ resume:~# fsck -f /dev/sdd1 Parallelizing fsck version 1.18 (11-Nov-1999) e2fsck 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09 Pass 1: Checking inodes, blocks, and sizes Inode 64654, i_blocks is 42696, should be 44744. Fix<y>? yes
Duplicate blocks found... invoking duplicate block passes. Pass 1B: Rescan for duplicate/bad blocks Duplicate/bad block(s) in inode 64654: 265881 ... ... ... Duplicate/bad block(s) in inode 193927: 265881 ... ... ... Pass 1C: Scan directories for inodes with dup blocks. Pass 1D: Reconciling duplicate blocks
(There are 2 inodes containing duplicate/bad blocks.)
File /kernel/kernel-image-2.4.0-ip22-r4k.tgz (inode #193927, mod time Thu Jan 25 11:17:00 2001)
has 251 duplicate block(s), shared with 1 file(s):
/devel/gcc-20000822-mips.tar.gz (inode #64654, mod time Mon Aug 28 17:14:56 2000)
Clone duplicate/bad blocks<y>? yes
File /devel/gcc-20000822-mips.tar.gz (inode #64654, mod time Mon Aug 28 17:14:56 2000)
has 251 duplicate block(s), shared with 1 file(s):
/kernel/kernel-image-2.4.0-ip22-r4k.tgz (inode #193927, mod time Thu Jan 25 11:17:00 2001)
Duplicated blocks already reassigned or cloned.
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences: +265876 +265877 +265878 +265879 +265880 Fix<y>? yes
Free blocks count wrong for group #0 (29960, counted=29709). Fix<y>? yes
Free blocks count wrong for group #8 (5, counted=0). Fix<y>? yes
Free blocks count wrong (717343, counted=717087).
Fix<y>? yes
/dev/sdd1: ***** FILE SYSTEM WAS MODIFIED *****/dev/sdd1: 6277/1034240 files (21.0% non-contiguous), 316359/1033446 blocks
I ran -test6 and -test9 before.
Flo
Signature · 2 lines
Florian Lohoff [email protected] +49-5201-669912 Why is it called "common sense" when nobody seems to have any?
Quoted 3 lines · Carsten Langgaard
Has anyone seen problems with fsck on the latest 2.4.0 kernel ? My filesystem gets corrupted from time to time when I use the latest 2.4.0 kernel.
2.4.1 is known to cause fs corruption for all architectures; 2.4.0 should actually be fine. I just reached 8 days of uptime on a 32p Origin 2000, so it can't be that bad.
Ralf
Quoted 3 lines
2.4.1 is known to cause fs corruption for all architectures; 2.4.0 should actually be fine. I just reached 8 days of uptime on a 32p Origin 2000, so it can't be that bad.
Im tracking fs corruption and worse on 2.4.0 as well (zero page corruptions since 2.4.0test10 for example)
I dont believe any 2.4 is currently 'safe'
Quoted 6 lines · Alan Cox
Quoted 3 lines
2.4.1 is known to cause fs corruption for all architectures; 2.4.0 should actually be fine. I just reached 8 days of uptime on a 32p Origin 2000, so it can't be that bad.
Im tracking fs corruption and worse on 2.4.0 as well (zero page corruptions since 2.4.0test10 for example)
Is the zero page mapped on non-m68k architectures?
Quoted 1 line
I dont believe any 2.4 is currently 'safe'
Ugh...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Quoted 1 line
Is the zero page mapped on non-m68k architectures?
It can certainly be hit by DMA and kernel memory ops
Quoted 2 lines
Quoted 1 line
I dont believe any 2.4 is currently 'safe'
Ugh...
We'll get there, its doing pretty well for most folks
Quoted 8 lines · Alan Cox
Quoted 1 line
Is the zero page mapped on non-m68k architectures?
It can certainly be hit by DMA and kernel memory ops
Quoted 2 lines
Quoted 1 line
I dont believe any 2.4 is currently 'safe'
Ugh...
We'll get there, its doing pretty well for most folks
I hope so. For many of us 2.2 is no longer an option. That is at least without heavy patching to add support for hardware that isn't supported by 2.2.
Ralf