Talk:Using XFS instead of ext3 (network performance boost)
==Conflict between XFS, JFS and an AudioCD app?== Davy gravy 22:00, 17 December 2006 (EST)
Posted by davy_gravy - conversation between him & mindbender
a followup after a week or so of testing and use...
some bad news on the jfs (it could be a random problem (not replicable/reproduceable), it could be because of using fsconvert, or it could be a problem w/ jfs - my guess is that it was caused by the conversion - there is perhaps something that we forgot to do/check as a last step - but I have no idea what that could be...)
After a very good week of use, my hda3 jfs partition no longer mounts. Rebooting doesn't help. running jfs_fsck doesn't help. Attempting to mount manually yields a complaint of "mount: Structure needs cleaning", yet jfs_fsck shows this
jfs_fsck /dev/hda3 jfs_fsck version 1.1.7, 22-Jul-2004 processing started: 12/10/2006 10.39.45 Using default parameter: -p The current device is: /dev/hda3 Block size in bytes: 4096 Filesystem size in blocks: 59605166 **Phase 0 - Replay Journal Log Filesystem is clean.
dmesg seems to show that some aspect of the system seems to believe that it should be using XFS:
EXT3 FS on hda1, internal journal JFS: nTxBlock = 988, nTxLock = 7907 sr0: scsi3-mmc drive: 8x/48x writer cd/rw xa/form2 cdda tray Uniform CD-ROM driver Revision: 3.20 sr 0:0:0:0: Attached scsi CD-ROM sr0 sr 0:0:0:0: Attached scsi generic sg0 type 5 sd 1:0:0:0: Attached scsi generic sg1 type 0 EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended end_request: I/O error, dev sr0, sector 1397120 Buffer I/O error on device sr0, logical block 174640 end_request: I/O error, dev sr0, sector 1397120 Buffer I/O error on device sr0, logical block 174640 end_request: I/O error, dev sr0, sector 1397032 Buffer I/O error on device sr0, logical block 174629 end_request: I/O error, dev sr0, sector 1397032 Buffer I/O error on device sr0, logical block 174629 end_request: I/O error, dev sr0, sector 1397032 Buffer I/O error on device sr0, logical block 174629 end_request: I/O error, dev sr0, sector 1396888 Buffer I/O error on device sr0, logical block 174611 r8169: eth0: link up eth0: 1000Mbps Full-duplex operation. NET: Registered protocol family 10 lo: Disabled Privacy Extensions IPv6 over IPv4 tunneling driver Capability LSM initialized eth0: no IPv6 routers present sg_write: data in/out 56/56 bytes for SCSI command 0x12--guessing data in; program cdparanoia not setting count and/or reply_len properly sg_write: data in/out 26/26 bytes for SCSI command 0x5a--guessing data in; program cdparanoia not setting count and/or reply_len properly sg_write: data in/out 12/12 bytes for SCSI command 0x43--guessing data in; program cdparanoia not setting count and/or reply_len properly sg_write: data in/out 12/12 bytes for SCSI command 0x43--guessing data in; program cdparanoia not setting count and/or reply_len properly sg_write: data in/out 12/12 bytes for SCSI command 0x43--guessing data in; program cdparanoia not setting count and/or reply_len properly sg_write: data in/out 12/12 bytes for SCSI command 0x43--guessing data in; program cdparanoia not setting count and/or reply_len properly sg_write: data in/out 12/12 bytes for SCSI command 0x43--guessing data in; program cdparanoia not setting count and/or reply_len properly sg_write: data in/out 12/12 bytes for SCSI command 0x43--guessing data in; program cdparanoia not setting count and/or reply_len properly sg_write: data in/out 12/12 bytes for SCSI command 0x43--guessing data in; program cdparanoia not setting count and/or reply_len properly sg_write: data in/out 12/12 bytes for SCSI command 0x43--guessing data in; program cdparanoia not setting count and/or reply_len properly SGI XFS with ACLs, security attributes, no debug enabled SGI XFS Quota Management subsystem XFS mounting filesystem hda3 Starting XFS recovery on filesystem: hda3 (logdev: internal) Filesystem "hda3": xfs_inode_recover: Bad inode magic number, dino ptr = 0xc15a1400, dino bp = 0xc330 6840, ino = 132 Filesystem "hda3": XFS internal error xlog_recover_do_inode_trans(1) at line 2364 of file fs/xfs/xfs_log_ recover.c. Caller 0xc9300e10 Call Trace: [C29EF930] [C000C248] show_stack+0x4c/0x194 (unreliable) [C29EF970] [C92E9A50] xfs_error_report+0x60/0x64 [xfs] [C29EF980] [C9300874] xlog_recover_do_inode_trans+0x72c/0x80c [xfs] [C29EF9F0] [C9300E10] xlog_recover_do_trans+0x13c/0x154 [xfs] [C29EFA20] [C9300F2C] xlog_recover_commit_trans+0x60/0x7c [xfs] [C29EFA40] [C930106C] xlog_recover_process_data+0xf4/0x1c8 [xfs] [C29EFA80] [C9301D98] xlog_do_recovery_pass+0x1e8/0x810 [xfs] [C29EFB30] [C930243C] xlog_do_log_recovery+0x7c/0xac [xfs] [C29EFB60] [C9302484] xlog_do_recover+0x18/0x148 [xfs] [C29EFB80] [C9302650] xlog_recover+0x9c/0xd8 [xfs] [C29EFBB0] [C92FA6D0] xfs_log_mount+0xa8/0x124 [xfs] [C29EFBE0] [C9303B1C] xfs_mountfs+0x5a4/0xaf8 [xfs] [C29EFC90] [C92F681C] xfs_ioinit+0x38/0x4c [xfs] [C29EFCB0] [C930ABA4] xfs_mount+0x258/0x3e8 [xfs] [C29EFCE0] [C9320040] vfs_mount+0x44/0x5c [xfs] [C29EFCF0] [C931FE6C] xfs_fs_fill_super+0x9c/0x200 [xfs] [C29EFD90] [C00664FC] get_sb_bdev+0x128/0x16c [C29EFDE0] [C931FFEC] xfs_fs_get_sb+0x1c/0x2c [xfs] [C29EFDF0] [C00667E8] vfs_kern_mount+0xb0/0x158 [C29EFE20] [C00668D0] do_kern_mount+0x40/0x64 [C29EFE50] [C007FE4C] do_new_mount+0x94/0xc4 [C29EFE80] [C0080674] do_mount+0x1ac/0x1f4 [C29EFF00] [C0080A50] sys_mount+0xa4/0xf4 [C29EFF40] [C0004100] ret_from_syscall+0x0/0x38 XFS: log mount/recovery failed: error 117 XFS: log mount failed XFS mounting filesystem hda3
My gut feel is that in the conversion process, something was left out...?
Double-checking /etc/fstab shows jfs...
cat /etc/fstab # /etc/fstab: static file system information. # # <file system> <mount point> <type> <options> <dump> <pass> /dev/hda1 / ext3 defaults,noatime,errors=remount-ro 0 0 proc /proc proc defaults 0 0 none /dev/pts devpts gid=5,mode=20 0 0 /dev/hda2 swap swap defaults 0 0 /dev/hda3 /mnt jfs defaults,noatime 0 0
davy_gravy - member
OK. It is working again, but there is apparently some unexpected/undesirable behavior here. It is trying to mount the CDROM as XFS, and that is just not going to work. This seems to happen whenever an audio cd is in the tray at boot time.
I'm concerned that during conversion something was left in the wrong state.
mindbender, do we need to mention this on the XFS hda3 conversion article page?
===================
mindbender - Moderator
Quote
Quoting: davy_gravy
what did you do to fix it?
===================
davy_gravy - member
Simple to fix/workaround. I just make sure that there is no CD in the USB/CDROM drive when it boots. But why should a CD (an audio CD) in the drive trigger an attempt to mount something as XFS, when there is no XFS system on the hard drive anymore.
Not simple to figure out why it happend. Very unexpected that it happened. It *is* odd.
Has lb_worm seen anything like this? Anyone else who is using XFS or JFS, or has used convertfs seen this type of behavior?
I suspect that one of my apps (Mediaripper or one of its dependencies) may be an unwitting accomplice in this...
Do you think if I had a line in the fstab for the USB/CDburner it might keep it from happening? But, that would only make it try to mount the CD to the specified mount point...?