Failures in e2fsprogs-1.39-tyt3 'make check'
Hi all, I'm getting some errors in the 'make check' step when building e2fsprogs-1.39-tyt3. Many of the errors look to be as a result of missing image files, for example: f_orphan_dotdot_ft: filetype of .. in orphaned directories: ../../tests/run_e2fsck: line 43: ../../tests/f_orphan_dotdot_ft/image.gz: No such file or directory rm: cannot remove `./test.img': No such file or directory Sorry if this is a documented, known issue. I'm just being paranoid and don't want to do a 'make install' if it will hose up the box. Thanks, Kirk - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Failures in e2fsprogs-1.39-tyt3 'make check'
On Mon, Jun 04, 2007 at 01:18:23AM -0700, Kirk True wrote: Hi all, I'm getting some errors in the 'make check' step when building e2fsprogs-1.39-tyt3. Many of the errors look to be as a result of missing image files, for example: f_orphan_dotdot_ft: filetype of .. in orphaned directories: ../../tests/run_e2fsck: line 43: ../../tests/f_orphan_dotdot_ft/image.gz: No such file or directory rm: cannot remove `./test.img': No such file or directory Sorry if this is a documented, known issue. I'm just being paranoid and don't want to do a 'make install' if it will hose up the box. Yes, it's known. Note that e2fsprogs 1.39-tyt3 is really only meant for ext4 developers. If you're not trying to use ext4 (and it's really not meant for production use yet), you should be using e2fsprogs.1.39 or e2fsprogs WIP-20070407. Regards, - Ted - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Failures in e2fsprogs-1.39-tyt3 'make check'
Hi Theodore, Sorry if this is a documented, known issue. I'm just being paranoid and don't want to do a 'make install' if it will hose up the box. Yes, it's known. Note that e2fsprogs 1.39-tyt3 is really only meant for ext4 developers. If you're not trying to use ext4 (and it's really not meant for production use yet), you should be using e2fsprogs.1.39 or e2fsprogs WIP-20070407. Thanks for the quick reply. Yes - I'm trying to get into ext4 development, so I'll assume these aren't fatal and proceed. Thanks! Kirk - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH] Set JBD2_FEATURE_INCOMPAT_64BIT on filesystems larger than 32-bit blocks (take 2).
On Jun 04, 2007 11:32 -0500, Jose R. Santos wrote:
Set the journals JBD2_FEATURE_INCOMPAT_64BIT on devices with more
than 32bit block sizes during mount time. This ensure proper record
lenth when writing to the journal.
Signed-off-by: Jose R. Santos [EMAIL PROTECTED]
---
fs/ext4/super.c | 11 +++
1 file changed, 11 insertions(+)
Index: linux-2.6.22-rc3/fs/ext4/super.c
===
--- linux-2.6.22-rc3.orig/fs/ext4/super.c 2007-06-04 11:01:20.028360650
-0500
+++ linux-2.6.22-rc3/fs/ext4/super.c 2007-06-04 11:05:11.389126418 -0500
@@ -1824,6 +1824,17 @@ static int ext4_fill_super (struct super
goto failed_mount3;
}
+/*
+ * Make sure to set JBD2_FEATURE_INCOMPAT_64BIT on filesystems
+ * with more that 32-bit block counts
+ */
+ if(es-s_blocks_count_hi
+!jbd2_journal_set_features(EXT4_SB(sb)-s_journal, 0, 0,
+ JBD2_FEATURE_INCOMPAT_64BIT)){
+ printk(KERN_ERR ext4: Failed to set 64-bit journal feature\n);
+ goto failed_mount4;
+ }
+
/* We have now updated the journal if required, so we can
* validate the data journaling mode. */
switch (test_opt(sb, DATA_FLAGS)) {
This is fine, but Linux CodingStyle would have if ( and have )) {.
Don't bother reposting, but whoever adds this to the ext4 git tree and/or
sending it to Andrew should make the fix.
Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.
-
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH] Set JBD2_FEATURE_INCOMPAT_64BIT on filesystems larger than 32-bit blocks (take 2).
On Jun 04, 2007 16:01 -0700, Mingming Cao wrote:
Set the journals JBD2_FEATURE_INCOMPAT_64BIT on devices with more
than 32bit block sizes during mount time. This ensure proper record
lenth when writing to the journal.
Signed-off-by: Mingming Cao [EMAIL PROTECTED]
Signed-off-by: Jose R. Santos [EMAIL PROTECTED]
You can add Signed-off-by: Andreas Dilger [EMAIL PROTECTED] also.
Index: linux-2.6.22-rc3/fs/ext4/super.c
===
--- linux-2.6.22-rc3.orig/fs/ext4/super.c 2007-06-04 11:01:20.028360650
-0500
+++ linux-2.6.22-rc3/fs/ext4/super.c 2007-06-04 11:05:11.389126418 -0500
@@ -1824,6 +1824,17 @@ static int ext4_fill_super (struct super
goto failed_mount3;
}
+/*
+ * Make sure to set JBD2_FEATURE_INCOMPAT_64BIT on filesystems
+ * with more that 32-bit block counts
+ */
+ if (le32_to_cpu(es-s_blocks_count_hi)
+!jbd2_journal_set_features(EXT4_SB(sb)-s_journal, 0, 0,
+ JBD2_FEATURE_INCOMPAT_64BIT)){
+ printk(KERN_ERR ext4: Failed to set 64-bit journal feature\n);
+ goto failed_mount4;
+ }
+
/* We have now updated the journal if required, so we can
* validate the data journaling mode. */
switch (test_opt(sb, DATA_FLAGS)) {
Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.
-
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH ext3/ext4] orphan list check on destroy_inode
On Mon, 04 Jun 2007 09:18:55 +0400 Vasily Averin [EMAIL PROTECTED] wrote:
Customers claims to ext3-related errors, investigation showed that ext3
orphan list has been corrupted and have the reference to non-ext3 inode. The
following debug helps to understand the reasons of this issue.
Signed-off-by:Vasily Averin [EMAIL PROTECTED]
diff --git a/fs/ext3/super.c b/fs/ext3/super.c
index 6e30629..46e2fa6 100644
--- a/fs/ext3/super.c
+++ b/fs/ext3/super.c
@@ -459,6 +459,21 @@ static struct inode *ext3_alloc_inode(struct super_block
*sb)
static void ext3_destroy_inode(struct inode *inode)
{
+ if (!list_empty((EXT3_I(inode)-i_orphan))) {
+ int i, imax;
+ unsigned int *p;
+
+ p = (unsigned int *)EXT3_I(inode);
+ imax = sizeof(struct ext3_inode_info) / sizeof(unsigned int);
+ printk(Inode %p: orphan list check failed!\n, EXT3_I(inode));
+ for (i = 0; i imax; i++) {
+ if (i ((i % 8) == 0))
+ printk(\n);
+ printk(%08x , *p++);
+ }
+ printk(\n);
+ dump_stack();
umm, OK, but please use the new lib/hexdump.c for this.
-
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH ext3/ext4] orphan list check on destroy_inode
Vasily Averin wrote: Customers claims to ext3-related errors, investigation showed that ext3 orphan list has been corrupted and have the reference to non-ext3 inode. The following debug helps to understand the reasons of this issue. Vasily, does your customer have this patch in place? http://www.mail-archive.com/linux-ext4@vger.kernel.org/msg00889.html If not, perhaps it could be leading to the same error, because the inode will not be properly removed from the orphan inode list when it is freed, and could then be recycled... -Eric - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH ext3/ext4] orphan list corruption due bad inode
Vasily Averin wrote:
After ext3 orphan list check has been added into ext3_destroy_inode() (please
see my previous patch) the following situation has been detected:
EXT3-fs warning (device sda6): ext3_unlink: Deleting nonexistent file
(37901290), 0
Inode 0101a15b7840: orphan list check failed!
0773 6f665f00 74616d72 0573 65725f00 06737270 6600 616d726f
...
Call Trace: [80211ea9] ext3_destroy_inode+0x79/0x90
[801a2b16] sys_unlink+0x126/0x1a0
[80111479] error_exit+0x0/0x81
[80110aba] system_call+0x7e/0x83
First messages said that unlinked inode has i_nlink=0, then ext3_unlink() adds
this inode into orphan list.
Second message means that this inode has not been removed from orphan list. Inode
dump has showed that i_fop = bad_file_ops and it can be set in
make_bad_inode() only. Then I've found that ext3_read_inode() can call
make_bad_inode() without any error/warning messages, for example in the following
case:
...
if (inode-i_nlink == 0) {
if (inode-i_mode == 0 ||
!(EXT3_SB(inode-i_sb)-s_mount_state EXT3_ORPHAN_FS)) {
/* this inode is deleted */
brelse (bh);
goto bad_inode;
...
Bad inode can live some time, ext3_unlink can add it to orphan list, but
ext3_delete_inode() do not deleted this inode from orphan list. As
result we can have orphan list corruption detected in ext3_destroy_inode().
Ah, I see - so you have confirmed that this inode does have bad ops...?
I did notice on another orphan inode bug investigation that
ext3_inode_delete won't clear orphan from a bad_inode...
However it is not clear for me how to fix this issue correctly.
As far as i see is_bad_inode() is called after iget() in all places excluding
ext3_lookup() and ext3_get_parent(). I believe it makes sense to add bad inode
check to these functions too and call iput if bad inode detected.
That seems reasonable to me in any case, though as Andrew said, do you
know for sure how the bad inodes were getting on the orphan list...?
Is it possible that they were recycled after being freed while still on
the orphan list, as in my previous reply to your previous message?
-Eric
-
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH ext3/ext4] orphan list corruption due bad inode
On Jun 04, 2007 19:03 -0700, Andrew Morton wrote: What caused those inodes to be bad, anyway? Memory allocation failures? This can happen if e.g. NFS has a stale file handle - it will look up the inode by inum, but ext3_read_inode() will create a bad inode due to i_nlink = 0. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
