All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.