Re: [PATCH 5/8] target: Add sanity checks for DPO/FUA bit usage

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, 2015-02-22 at 15:19 -0500, Douglas Gilbert wrote:
> On 15-02-22 11:41 AM, Christoph Hellwig wrote:
> > On Sat, Feb 14, 2015 at 03:27:40AM +0000, Nicholas A. Bellinger wrote:
> >> From: Nicholas Bellinger <nab@xxxxxxxxxxxxxxx>
> >>
> >> 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.
> >
> > This causes I/O errors with ext4 on tcm_loop on what seems to be the first
> > journal commit:
> >
> > [   41.818126] EXT4-fs (sdc): mounted filesystem with ordered data mode. Opts: (null)
> > [   48.919107] Got CDB: 0x2a with FUA bit set, but device does not advertise support for FUA write

Where is this coming from?  It's not a message I can find in the current
kernel.

> > [   48.920245] sd 3:0:0:0: [sdc] tag#113 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
> > [   48.921219] sd 3:0:0:0: [sdc] tag#113 Sense Key : Illegal Request [current]
> > [   48.921980] sd 3:0:0:0: [sdc] tag#113 Add. Sense: Invalid field in cdb
> 
> Setting (or clearing) the FUA bit on READ or WRITE commands
> does not cause an error according to sbc4r05 irrespective of
> the LU's support for volatile and non-volatile caches. I'm
> pretty sure that hasn't changed recently (say 15 years).

Well, firstly, that doesn't change the fact that sending FUA commands to
a non-FUA supporting device is a bug because the stable storage
guarantee the filesystem is relying on is broken.

However, your characterisation of the standards isn't quite correct:
you've forgotten SAT.  SAT allows a non FUA supporting ATA device to
return illegal request ... and I bet this is what's happening.

James


--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux