[Top] [All Lists]

[Bug 385] xfs_force_shutdown(loop7,0x1) called from line 353 of file fs/

To: xfs-master@xxxxxxxxxxx
Subject: [Bug 385] xfs_force_shutdown(loop7,0x1) called from line 353 of file fs/xfs/xfs_rw.c
From: bugzilla-daemon@xxxxxxxxxxx
Date: Thu, 18 Nov 2004 15:50:39 -0800
Sender: linux-xfs-bounce@xxxxxxxxxxx

------- Additional Comments From evilninja@xxxxxxx  2004-18-11 15:50 PDT -------
hm, do you really mean #388?
it's about raid5 and "variable length transfers" and there is no error message
of the corruptions at all (but a patch?)

but i've looked at the bugs #376, #375, #321, #296, #272, #247 but all these
xfs_force_shutdown were called from fs/xfs/xfs_trans.c, xfs_bmap.c and
xfs_trans_cancel while this here was called from fs/xfs/xfs_rw.c. i did not find
these types of xfs_force_shutdown's on the net either.

the backing store for the loopback-device is a scsi-disk partition:
$ losetup -a
/dev/loop7: [0805]:389 (/dev/sdb1) encryption=twofish128 multi-key

the kernel said furthermore:
xfs_force_shutdown(loop7,0x1) called from line 353 of file fs/xfs/xfs_rw.c. 
Return address = 0xc021427c
Filesystem "loop7": I/O Error Detected.  Shutting down filesystem: loop7

hm, i thought, "i/o errors", could be hardware related then but it seemed
unlikely, because sdb2+sdb3 are both in heavy use too, no errors, but not loop
mounted too. badblocks showed no errors. i've reformatted loop7 (sdb1) with xfs
then, but the errors were still there.
right now i have to admit that the device is now formatted with another fs.
(erm, it's reiserfs now. i've tried reiserfs some years ago, with no luck and
wanted to give it another shot. but i can continue testing with xfs+loop-aes
too, if it helps).

thank you for your concern,

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

<Prev in Thread] Current Thread [Next in Thread>