On Fri, Apr 24, 2009 at 01:09:43AM -0600, Andreas Dilger wrote: > On Apr 23, 2009 23:20 -0400, Theodore Ts'o wrote: > > On Thu, Apr 23, 2009 at 03:15:10PM -0700, Christian Kujau wrote: > > > On Thu, 23 Apr 2009, Theodore Tso wrote: > > > > Eventually I might need a raw e2image dump, i.e.: > > > > > > > > e2image -r /dev/md0 - | bzip2 > /var/tmp/md0.e2i.bz2 > > > > > > I've put the raw e2image dump on http://nerdbynature.de/bits/2.6.30-rc2/ > > > Do you still need the dump without the "-r"? > > > > Nope, the raw e2image file was perfect. This was actually a problem I > > knew about, and wanted to get fixed before the e2fsprogs 1.41.5 > > release. The problem was that i_file_acl_high was set and the kernel > > unconditionally checks for it even though the INCOMPAT_64_BITS flag is > > not set. > > Maybe I'm missing something, but how can i_file_acl_high being used > cause a problem with the file extent maps? It didn't; what had happened was that a garbage block had got written into the inode table. This caused the kernel to complain about eh_magic being wrong in the inode table. E2fsck 1.41.3 fixed those problems, but it ignored i_file_acl_high because the 64 bit feature flag was not set. The kernel always pays attention to i_file_acl_high, regardless of whether the 64-bit feature flag is set or not. Hence, the kernel was complaining and refused to touch those inodes. Actually, on a 2.6.30 kernel it causes the kernel to loop forever with kernel messages "__find_get_block_slow() failed." In any case, with e2fsck 1.41.5, I added code to fix i_file_acl_high getting set, and I was then able to mount the raw e2image file and not have any problems accessing the files in question, so I'm pretty sure that was the problem. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
