Re: [PATCH] USB: storage: add "no SYNCHRONIZE CACHE" quirk

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

 



On Mon, 2015-06-22 at 13:48 -0400, Alan Stern wrote:
> On Mon, 22 Jun 2015, James Bottomley wrote:
> 
> > On Mon, 2015-06-22 at 13:30 -0400, Alan Stern wrote:
> > > On Mon, 22 Jun 2015, James Bottomley wrote:
> > > 
> > > > I'm not sure I entirely like this:  we are back again treating data
> > > > corruption problems silently.
> > > > 
> > > > However, I also believe treating a single flush failure as a critical
> > > > filesystem error is also wrong:  The data's all there correctly; all it
> > > > does is introduce a potential window were the FS could get corrupted in
> > > > the unlikely event the system crashed.
> > > > 
> > > > Obviously, for a disk with a writeback cache that can't do flush, that
> > > > window is much wider and the real solution should be to try to switch
> > > > the cache to write through.
> > > 
> > > I agree.  Doing the switch manually (by writing to the "cache_type" 
> > > attribute file) works, but it's a nuisance to do this when you have a 
> > > portable USB drive that gets moved among a bunch of machines.
> > 
> > Perhaps it might be wise to do this to every USB device ... for external
> > devices, the small performance gain doesn't really make up for the
> > potential data loss.
> > 
> > > > How about something like this patch?  It transforms FS FLUSH into a log
> > > > warning from an error but preserves the error on any other path.  You'll
> > > > still get a fairly continuous dump of warnings for one of these devices,
> > > > though ... do they respond to mode selects turning off the writeback?
> > > 
> > > I would be very surprised if any of those drives support MODE SELECT at 
> > > all.
> > 
> > I assume the cache type attribute file you refer to above is just
> > pretending their cache is write through rather than actually setting it
> > to be so?
> 
> Yes; I'm referring to cache_type_store() in sd.c, and writing
> "temporary write through", which does not issue a MODE SELECT command.  
> It would be easy enough for people to try leaving out the "temporary", 
> but I don't expect it to work.
> 
> >  The original IDE device had no way of turning their cache
> > types to write through either, but the manufacturers were eventually
> > convinced of the error of their ways.
> 
> In this case the stupidity resides in the USB-ATA bridge.  You can see 
> the gory details at
> 
> 	https://bugzilla.kernel.org/show_bug.cgi?id=89511#c19

OK, so that says the SAT in the bridge doesn't know what to do with
MODE_SELECT (probably unsurprising given that it's a usb bridge).  the
SATA disk should respond to the ATA command SET FEATURES, though.
Presuming we can get it through the bridge.

You can try it with

hdparm -W 0 <dev>

optionally with --prefer_ata_12 to do the 12 instead of 16 byte
encapsulation and see if that makes a difference.

James



--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in



[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