Hello, thanks for your info. That means it is a bug in ext3. It seems to ignore the errors=continue mount option, although according to the manpage it should support all the options that ext2 does. Unfortunately I'm not able to reproduce this exact behaviour, however I am able to produce a filesystem error and make ext3 remount the filesystem read-only, while ext2 continues on an error. Here is what happens with ext2:
May 26 15:46:25 nfstest1 kernel: attempt to access beyond end of device May 26 15:46:25 nfstest1 kernel: drbd1: rw=0, want=146538512, limit=146538496 May 26 15:46:25 nfstest1 kernel: EXT2-fs error (device drbd1): read_inode_bitmap: Cannot read inode bitmap - block_group = 559, inode_bitmap = 18317313 And this is with ext3: May 26 13:31:37 nfstest1 kernel: attempt to access beyond end of device May 26 13:31:37 nfstest1 kernel: drbd1: rw=0, want=146538512, limit=146538496 May 26 13:31:37 nfstest1 kernel: EXT3-fs error (device drbd1): read_inode_bitmap: Cannot read inode bitmap - block_group = 559, inode_bitmap = 18317313 May 26 13:31:37 nfstest1 kernel: Aborting journal on device drbd1. May 26 13:31:37 nfstest1 kernel: EXT3-fs error (device drbd1) in ext3_new_inode: IO failure May 26 13:31:37 nfstest1 kernel: EXT3-fs error (device drbd1) in ext3_create: IO failure May 26 13:31:37 nfstest1 kernel: ext3_abort called. May 26 13:31:37 nfstest1 kernel: EXT3-fs error (device drbd1): ext3_journal_start_sb:Detected aborted journal May 26 13:31:37 nfstest1 kernel: Remounting filesystem read-only May 26 13:31:37 nfstest1 kernel: __journal_remove_journal_head: freeing b_committed_data I would consider this a bug, maybe it's only a bug in the manpage ;) Peter -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
