On Mon, 22 Jun 2015, James Bottomley wrote: > 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. Dan Williams recently posted the content below to the Bugzilla report: > I have a drive with this problem and I tested 4.0.8 with this hunk > added to the patch above. > > UNUSUAL_DEV( 0x0bc2, 0x0888, 0x0000, 0x0000, > "Seagate", > "USB 2.0 Pocket Hard Drive", > USB_SC_DEVICE, USB_PR_DEVICE, NULL, > US_FL_NO_SYNCHRONIZE_CACHE), > > I don't have the linux-usb thread around so I can reply to > http://www.spinics.net/lists/linux-usb/msg126364.html, but here's the > result of: > > [dcbw@localhost ~]$ sudo hdparm -W 0 --prefer-ata12 /dev/sdb > > /dev/sdb: > setting drive write-caching to 0 (off) > SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 00 00 00 > 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 In English: "Illegal Request: Invalid command operation code". Apparently there's no way to tell the drive to change its caching. > SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 00 00 00 > 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 00 00 00 > 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 00 00 00 > 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 00 00 00 > 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > write-caching = not supported > > What was the upstream resolution on this one? So far there isn't any. Alan Stern -- 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
