[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.44L0.1110031548310.1882-100000@iolanthe.rowland.org>
Date: Mon, 3 Oct 2011 15:53:45 -0400 (EDT)
From: Alan Stern <stern@...land.harvard.edu>
To: James Bottomley <James.Bottomley@...senPartnership.com>
cc: Douglas Gilbert <dgilbert@...erlog.com>,
Amit Sahrawat <amit.sahrawat83@...il.com>,
<linux-usb@...r.kernel.org>, <linux-scsi@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <linux-fsdevel@...r.kernel.org>,
Christoph Hellwig <hch@...radead.org>
Subject: Re: Re: BUG in kernel: Wrong Handling of USB HDD’s
in scsiglue(slave_configure) and scsi/sd(sd_read_cache_type)
On Mon, 3 Oct 2011, James Bottomley wrote:
> On Mon, 2011-10-03 at 14:10 -0400, Alan Stern wrote:
> > > No. You need to also take into account the RBC
> > > device parameters mode page if present. See above.
> >
> > All right, suppose neither page is present. Does it then make sense to
> > assume by default that write caching is enabled?
>
> You're the USB expert ... if we do that, we'll start sending
> SYNCHRONIZE_CACHE commands down to a whole slew of devices we didn't
> before ... is that going to cause problems with any USB SATLs?
Hmmm... Actually, I doubt it would bother any SATLs, but it might well
bother other sorts of USB translation layers. No way to tell without
trying it, and I don't really want to deal with the fallout.
Maybe a better question to be asking is this: What happens when one of
these drives (the ones that report their caching capabilities
incorrectly) is plugged into a Windows system?
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists