-
Well, blocks are clearly getting written to the wrong location on disk, so that tends to indicate either some kind of hardware problem (or more likely in your case) some kind of kernel bug that is causing blocks to be written to the wrong location. It's certainly not normal and I haven't seen anyone else reporting problems like this with ext2/ext3.
2009-10-06 14:35:20 UTC in Ext2 Filesystems Utilities
-
Well, if you look at those numbers, and convert them into ASCII you get: " LOAD_DAT_ERV_ERROR: %s". So it's ascii text which is getting written into an indirect block, first of inode #2042 and then of inode #1002. do you have multiple partitions on that device (and if so, have you checked to make sure the partition table isn't corrupt), or some other OS that might be wrtiting...
2009-10-05 14:19:06 UTC in Ext2 Filesystems Utilities
-
This is normal but since you probably won't be the first person to be confused by this, here's an attached patch which clarifies the message to something like this:
Illegal indirect block (2324697516) in inode 176. CLEARED.
2009-10-04 22:13:19 UTC in Ext2 Filesystems Utilities
-
Well, your filesystem is corrupted, but it's not a really horrible thing. It's likely that the problem was merely caused by a corrupted double indirect block. Block #-1 simply means a corrupted indirect block.
2009-10-03 16:33:08 UTC in Ext2 Filesystems Utilities
-
Sorry, I'm having problems parsing your last comment into valid english sentences and extracting sense out of them. Could you rephrase and expand the following:
"I cannot yet believe, that there is a hardware problem, because blocks
could be cleared, but each time only the next 11."
and
"It is interesting, whether functions, that clear the stand alone block and all blocks in inode...
2009-09-09 00:20:03 UTC in Ext2 Filesystems Utilities
-
Fixed in the latest maint branch.
2009-09-09 00:17:30 UTC in Ext2 Filesystems Utilities
-
This is a convention used to protect header files from double inclusion. Some of them are absolutely required, since there are different versions of these header files provided by the Linux kernel, and the Linux kernel uses this naming convention. E2fsprogs isn't alone in using this convention. So does X11, for example.
2009-09-09 00:16:11 UTC in Ext2 Filesystems Utilities
-
Patch added to allocate extra memory in e2fsprogs's "maint" branch in git.
2009-09-07 20:30:14 UTC in Ext2 Filesystems Utilities
-
I've added documentation for flex_bg to the tune2fs man page.
2009-09-07 18:55:37 UTC in Ext2 Filesystems Utilities
-
If you can clear the inode using clri, and then after you close the filesystem, re-run debugfs, thus re-opening the filesystem, and using the debugfs stat command, you're still seeing the original inode contents, then there is almost certainly a hardware problem where the write block command is being ignored by the disk. There's nothing e2fsprogs can do about that kind of I/O error.
2009-09-07 18:43:22 UTC in Ext2 Filesystems Utilities
