Hi, On Tue, 17 Mar 2015 14:09:08 +0100, Christophe Vu-Brugier wrote : > I have found a regression in the LIO iSCSI targets that causes I/Os to > fail. I performed a `git bisect` between Linux v3.19 and v4.0-rc4 that > showed that the regression is caused by the following commit: > > fde9f50f80fe89a9115b4bfa773017272597d85d is the first bad commit > commit fde9f50f80fe89a9115b4bfa773017272597d85d > Author: Nicholas Bellinger <nab@xxxxxxxxxxxxxxx> > Date: Fri Feb 13 23:28:27 2015 +0000 > > target: Add sanity checks for DPO/FUA bit usage > > This patch adds a sbc_check_dpofua() function that performs sanity > checks for DPO/FUA command bits. > > It introduces checks to fail when either bit is set, but the backend > device is not advertising support for them. > > It also moves the existing cmd->se_cmd_flags |= SCF_FUA assignement > into the new helper function. > > Cc: Christoph Hellwig <hch@xxxxxx> > Signed-off-by: Nicholas Bellinger <nab@xxxxxxxxxxxxxxx> > > :040000 040000 ea7ec2dcaf1f052d260ef595576debd31b50ac72 39116e63d803b5710a385f3f47bad4a74262defc M drivers > > Here are the steps I follow to trigger the bug: > > 1/ create an iSCSI target with a block backstore > 2/ login to the target with open-iscsi > 3/ format the mapped LUN with an ext4 file system > 4/ mount the file system > 5/ create some files with `touch` > > The file creation fails because the file system is remounted > read-only due to I/O errors. Errors are displayed in `dmesg` output on > both the initiator and target: > > == initiator == > > [ 1564.577302] scsi6 : iSCSI Initiator over TCP/IP > [ 1564.831189] scsi 6:0:0:0: Direct-Access LIO-ORG block1 4.0 PQ: 0 ANSI: 5 > [ 1564.832221] sd 6:0:0:0: Attached scsi generic sg4 type 0 > [ 1564.832933] sd 6:0:0:0: [sdd] 209715200 512-byte logical blocks: (107 GB/100 GiB) > [ 1564.832935] sd 6:0:0:0: [sdd] 4096-byte physical blocks > [ 1564.834061] sd 6:0:0:0: [sdd] Write Protect is off > [ 1564.834063] sd 6:0:0:0: [sdd] Mode Sense: 43 00 10 08 > [ 1564.834429] sd 6:0:0:0: [sdd] Write cache: enabled, read cache: enabled, supports DPO and FUA > [ 1564.847764] sdd: unknown partition table > [ 1564.850051] sd 6:0:0:0: [sdd] Attached SCSI disk > [ 1584.684077] sdd: unknown partition table > [ 1593.360501] EXT4-fs (sdd): mounted filesystem with ordered data mode. Opts: (null) > [ 1600.709370] sd 6:0:0:0: [sdd] Invalid command failure > [ 1600.709377] sd 6:0:0:0: [sdd] > [ 1600.709378] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE > [ 1600.709380] sd 6:0:0:0: [sdd] > [ 1600.709382] Sense Key : Illegal Request [current] > [ 1600.709384] sd 6:0:0:0: [sdd] > [ 1600.709386] Add. Sense: Invalid field in cdb > [ 1600.709387] sd 6:0:0:0: [sdd] CDB: > [ 1600.709389] Write(10): 2a 08 06 44 00 20 00 00 08 00 > [ 1600.709393] end_request: critical target error, dev sdd, sector 105119776 > [ 1600.709397] end_request: critical target error, dev sdd, sector 105119776 > [ 1600.709417] Aborting journal on device sdd-8. > [ 1601.068860] EXT4-fs error (device sdd): ext4_journal_check_start:56: Detected aborted journal > [ 1601.068864] EXT4-fs (sdd): Remounting filesystem read-only > [ 1648.316509] EXT4-fs error (device sdd): ext4_put_super:790: Couldn't clean up the journal > [ 1652.339136] sd 6:0:0:0: [sdd] Synchronizing SCSI cache > > == target == > > [ 116.885007] TARGET_CORE[iSCSI]: Unsupported SCSI Opcode 0x85, sending CHECK_CONDITION. > [ 116.894395] TARGET_CORE[iSCSI]: Unsupported SCSI Opcode 0x85, sending CHECK_CONDITION. > [ 152.649728] Got CDB: 0x2a with FUA bit set, but device does not advertise support for FUA write > > Feel free to ask if you want me to provide more information or > perform additional tests. The command that fails is WRITE_10. The device has: dev->dev_attrib.emulate_fua_write = 1 dev->dev_attrib.emulate_write_cache = 0 I think the FUA flag is set by the "jbd" when the journal is committed. Moreover, when I disable the file system barriers with the "-o nobarrier" mount option, I manage to create and remove files on the file system. Maybe the FUA check is too strong? Hope that helps, -- Christophe Vu-Brugier -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
