I wont say that I am absolutely 100% sure that ext3 was never tried on
this filesystem. I am pretty certain, but I'm guessing it doesn't really
make much difference at this point. Your scenario of the corruption
makes sense. I'll see if I can test your patch at some point (but I most
likely cannot).
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: <none>
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal filetype sparse_super
Filesystem state: not clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 1015808
Block count: 2028288
Reserved block count: 101414
Free blocks: 368490
Free inodes: 688732
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
Last mount time: Thu Nov 15 10:07:12 2001
Last write time: Thu Nov 15 18:29:55 2001
Mount count: 2
Maximum mount count: 20
Last checked: Thu Nov 15 08:48:40 2001
Check interval: 15552000 (6 months)
Next check after: Tue May 14 09:48:40 2002
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Journal UUID: <none>
Journal inode: 48
Journal device: 0x0000
First orphan inode: 0
-- .----------=======-=-======-=========-----------=====------------=-=-----. / Ben Collins -- Debian GNU/Linux \ ` bcollins@debian.org -- bcollins@openldap.org -- bcollins@linux.com ' `---=========------=======-------------=-=-----=-===-======-------=--=---' - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/