Bug 597667
Summary: | ext4: journal corruption | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Dan Williams <dcbw> |
Component: | kernel | Assignee: | Eric Sandeen <esandeen> |
Status: | CLOSED CANTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 13 | CC: | anton, dougsland, gansalmon, itamar, jonathan, kernel-maint |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2010-06-04 12:58:21 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Dan Williams
2010-05-30 02:30:21 UTC
can you look at the dd image of the pre-fsck filesystem, and use debugfs to do a debugfs> stat <8> to see what that journal inode looks like? An e2image of the original fs might be useful too, then I can poke at it myself. Thanks, -Eric debugfs 1.41.10 (10-Feb-2009) debugfs: stat <8> Inode: 8 Type: regular Mode: 0600 Flags: 0x80000 Generation: 0 Version: 0x00000000 User: 0 Group: 0 Size: 67108864 File ACL: 0 Directory ACL: 0 Links: 1 Blockcount: 131072 Fragment: Address: 0 Number: 0 Size: 0 ctime: 0x49f21d55 -- Fri Apr 24 13:13:09 2009 atime: 0x00000000 -- Wed Dec 31 16:00:00 1969 mtime: 0x49f21d55 -- Fri Apr 24 13:13:09 2009 Size of extra inode fields: 0 EXTENTS: (0-16383): 360448-376831 /etc/fstab is mounting this volume like so: UUID=f89dd491-d9d6-43ba-a553-ab1c938c5ba0 / ext4 defaults 1 1 Trying to do an e2image of the FS resulted in: [dcbw@localhost ~]$ sudo e2image /dev/sdb1 - | bzip2 -9 > sdb1.e2i.bz2 e2image 1.41.10 (10-Feb-2009) lseek while writing header: Illegal seek [dcbw@localhost ~]$ dmesg | tail scsi 4:0:0:0: Direct-Access Seagate Portable 0130 PQ: 0 ANSI: 4 sd 4:0:0:0: Attached scsi generic sg2 type 0 sd 4:0:0:0: [sdb] 625142448 512-byte logical blocks: (320 GB/298 GiB) sd 4:0:0:0: [sdb] Write Protect is off sd 4:0:0:0: [sdb] Mode Sense: 2f 08 00 00 sd 4:0:0:0: [sdb] Assuming drive cache: write through sd 4:0:0:0: [sdb] Assuming drive cache: write through sdb: sdb1 sd 4:0:0:0: [sdb] Assuming drive cache: write through sd 4:0:0:0: [sdb] Attached SCSI disk note that the partition I dd-ed my original fs onto is 320GB; the original fs itself is only 110GB. I just did: [root@localhost ~]# dd if=/dev/sda5 of=/dev/sdb1 bs=4096 26950144+0 records in 26950144+0 records out 110387789824 bytes (110 GB) copied, 4140.14 s, 26.7 MB/s more or less, so the /dev/sdb1 is obviously larger than the original FS. Not sure if that's something that e2image is complaining about. Ok, thanks. For some reason I thought it was corrupt, but no ....
> Journal inode is not in use, but contains data. Clear<y>? yes
The problem is that the inode bitmap thought the journal inode was free. That's ... odd.
I assume that:
debugfs> testi <8>
shows it not in use?
I wonder if it's possible that something overwrote the first part of your partition.
Maybe you can:
dd if=/dev/$WHATEVER bs=4k count=256 of=first-one-meg
bzip2 that, and attach it? I can see what the first part of the block device looks like, maybe we'll recognize something that stomped on it.
However, I guess in the total scope of the repair, not much looked damaged. So maybe that theory is off base ...
-Eric
for e2image you'll need to do the -r option to zip it etc:
> e2image -r /dev/hda1 - | bzip2 > hda1.e2i.bz2
etc...
(In reply to comment #4) > Ok, thanks. For some reason I thought it was corrupt, but no .... > > > Journal inode is not in use, but contains data. Clear<y>? yes > > The problem is that the inode bitmap thought the journal inode was free. > That's ... odd. > > I assume that: > > debugfs> testi <8> > > shows it not in use? [dcbw@localhost ~]$ sudo debugfs /dev/sdb1 debugfs 1.41.10 (10-Feb-2009) debugfs: testi <8> Inode 8 is marked in use I looked at this a bit yesterday, and it seems that nothing other than the journal was affected; somehow the first part appears to have been overwritten by 0s. The 2 blocks preceding the journal weren't listed as belonging to any existing file, so there was no clue there. Since we have no reproducer, and this has never been seen before, I don't know that we can resolve this one with the information we have now. So, sadly closing CANTFIX. If you see this again, though, please speak up! Thanks, -Eric |