public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jan Dittmer <j.dittmer@portrix.net>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: linux-kernel@vger.kernel.org
Subject: Re: ext3 on raid5 failure
Date: Wed, 28 Jan 2004 11:54:44 +0100	[thread overview]
Message-ID: <401794F4.80701@portrix.net> (raw)
In-Reply-To: <20040127190813.GC22933@thunk.org>

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

Theodore Ts'o wrote:
> On Fri, Jan 23, 2004 at 09:22:25AM +0100, Jan Dittmer wrote:
> 
>>Okay, I fscked all filesystems in single user mode, thereby fscked up my 
>>root filesystem, though I didn't even check it - so I restored it from 
>>backup (grub wouldn't even load anymore).
> 
> 
> What messages were printed by e2fsck while it was running --- and was
> all of the filesystems unmounted, excepted for the root filesystem,
> which should have been mounted read-only?
> 
Yep it was all unmounted. But I don't have a transcript of this session. 
I was directly logged in, sorry.

> 
>>After 2 days in my freshly setup debian (2.6.1-bk6), same error. But 
>>this time at least I know it's because I tried to delete those files in 
>>the lost+found directory...
> 
> 
> How did you come to that conclusion?

sfhq:/mnt/data/1/lost+found# ls -l
total 76
d-wSr-----    2 1212680233 136929556    49152 Jun  7  2008 #16370
-rwx-wx---    1 1628702729 135220664    45056 May  4  1974 #16380
sfhq:/mnt/data/1/lost+found# rm *
rm: cannot remove `#16370': Operation not permitted
rm: cannot remove `#16380': Operation not permitted
sfhq:/mnt/data/1/lost+found# rm *
rm: cannot remove `#16370': Operation not permitted
rm: cannot remove `#16380': Operation not permitted
sfhq:/mnt/data/1/lost+found# rm *
rm: cannot remove `#16370': Operation not permitted
rm: cannot remove `#16380': Operation not permitted
sfhq:/mnt/data/1/lost+found# dmesg
EXT3-fs error (device dm-2): ext3_readdir: directory #16370 contains a 
hole at offset 8192
Aborting journal on device dm-2.
EXT3-fs error (device dm-2): ext3_readdir: directory #16370 contains a 
hole at offset 24576
ext3_abort called.
EXT3-fs abort (device dm-2): ext3_journal_start: Detected aborted journal
Remounting filesystem read-only

This is with 2.6.1-bk6 and no concurrent access. With 2.4.25-pre7-pac1 
this does not happen.
So I rechecked the filesystem (with 2.4), hoping it won't get corrupted 
  and I would be able to delete the files, but:

sfhq:~# fsck /dev/myraid/lvol1
fsck 1.35-WIP (07-Dec-2003)
e2fsck 1.35-WIP (07-Dec-2003)
/dev/myraid/lvol1 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Directory inode 16370 has an unallocated block #2.  Allocate<y>? yes

Directory inode 16370 has an unallocated block #6.  Allocate<y>? yes

Pass 3: Checking directory connectivity
Pass 3A: Optimizing directories
Pass 4: Checking reference counts
Pass 5: Checking group summary information

/dev/myraid/lvol1: ***** FILE SYSTEM WAS MODIFIED *****
/dev/myraid/lvol1: 2341/45514752 files (24.0% non-contiguous), 
82194611/91002880 blocks

still no luck with undeleting these files

sfhq:/mnt/data/1/lost+found# rm -rf *
rm: cannot remove directory `#16370': Operation not permitted
rm: cannot remove `#16380': Operation not permitted

sfhq:/mnt/data# dumpe2fs /dev/myraid/lvol1
dumpe2fs 1.35-WIP (07-Dec-2003)
Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          ba3f83cd-04c8-4c4d-82f7-990077aabb73
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal dir_index needs_recovery sparse_super
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              45514752
Block count:              91002880
Reserved block count:     3640115
Free blocks:              8808269
Free inodes:              45512411
First block:              0
Block size:               4096
Fragment size:            4096
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         16384
Inode blocks per group:   512
Filesystem created:       Thu Jul  3 13:57:02 2003
Last mount time:          Wed Jan 28 11:48:13 2004
Last write time:          Wed Jan 28 11:48:13 2004
Mount count:              2
Maximum mount count:      23
Last checked:             Wed Jan 28 11:47:06 2004
Check interval:           15552000 (6 months)
Next check after:         Mon Jul 26 12:47:06 2004
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               128
Journal inode:            8
Default directory hash:   tea
Directory Hash Seed:      a7fd0c53-efe9-4316-9fa6-e3206623f4fe
Journal backup:           inode blocks

Do you need the complete output? Btw. I have the same error on another 
partition (also on raid5, dm).

Thanks,

Jan


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

  reply	other threads:[~2004-01-28 10:55 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-18 10:27 ext3 on raid5 failure Jan Dittmer
2004-01-18 18:02 ` Mike Fedyk
2004-01-19 15:30   ` Theodore Ts'o
2004-01-23  8:22     ` Jan Dittmer
2004-01-27 19:08       ` Theodore Ts'o
2004-01-28 10:54         ` Jan Dittmer [this message]
2004-01-29 11:44           ` Theodore Ts'o
2004-02-04  9:24             ` Bas Mevissen
2004-02-04  9:43               ` Nigel Cunningham
2004-02-04 11:38                 ` Bas Mevissen
2004-02-04 20:49                   ` Nigel Cunningham
2004-02-17 23:14                     ` Pavel Machek
2004-02-17 23:58                       ` Kiko Piris
2004-02-06 19:18               ` Theodore Ts'o
2004-02-09  8:55                 ` Bas Mevissen
2004-02-18  3:07                   ` Bill Davidsen
2004-02-19  9:27                     ` Bas Mevissen
2004-02-19 19:47                       ` Bill Davidsen
2004-01-28 11:06         ` Jan Dittmer
2004-02-19  2:32     ` Leandro Guimarães Faria Corsetti Dutra
2004-02-19  8:07       ` Jan Dittmer
2004-02-19 13:50         ` Leandro Guimarães Faria Corcete Dutra
2004-02-19 14:58           ` Leandro Guimarães Faria Corsetti Dutra
  -- strict thread matches above, loose matches on Subject: below --
2004-02-25 17:45 Muhammad L.

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=401794F4.80701@portrix.net \
    --to=j.dittmer@portrix.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox