public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Patrick Mansfield <patmans@us.ibm.com>
To: James Bottomley <James.Bottomley@SteelEye.com>
Cc: Alan Stern <stern@rowland.harvard.edu>,
	Linus Torvalds <torvalds@osdl.org>, Ruud Linders <rkmp@xs4all.nl>,
	Christoph Hellwig <hch@infradead.org>,
	Matthew Dharm <mdharm-usb@one-eyed-alien.net>,
	David Brownell <david-b@pacbell.net>, Greg KH <greg@kroah.com>,
	USB development list <linux-usb-devel@lists.sourceforge.net>,
	SCSI development list <linux-scsi@vger.kernel.org>,
	Andries.Brouwer@cwi.nl
Subject: Re: [linux-usb-devel] Re: USB storage problems on OHCI..
Date: Fri, 3 Oct 2003 14:35:18 -0700	[thread overview]
Message-ID: <20031003143518.A16624@beaverton.ibm.com> (raw)
In-Reply-To: <1065193559.1887.52.camel@mulgrave>; from James.Bottomley@SteelEye.com on Fri, Oct 03, 2003 at 10:05:52AM -0500

On Fri, Oct 03, 2003 at 10:05:52AM -0500, James Bottomley wrote:

> Well, the patch isn't quite correct because if it's not going to probe
> the cache it should set up a write through cache (or disabled cache) as
> the default.

Alan's original patch is included in my patch.

> Patrick's patch
> 
> http://marc.theaimsgroup.com/?l=linux-scsi&m=106366112221507
> 
> Does get this right.

I am re-rolling the patch based on current 2.6, plus a couple comments
Christoph had, I'll resend to you and linux-scsi.

> But my principle objection, as I've stated before, is that it isn't true
> that we don't need to manage the caches of hot pluggable devices, fibre
> channel being the counter example.

I agree - the type of transport does not indicate the capabilties of the
device. If connectors were free and took no space (yeh never), we would
have usb, firewire, spi, and fcp available on all disk drives.

But for some reason with USB, we are more likely to have devices that
cannot handle mode sense page 8 (cache). So shove some code into the
usb-storage driver, and make it possible to set policy allowing us to
disable page 8 for any device.

Though I do not see the utility in syncing the cache, especially given the
failure to figure out the caching method. 

High end storage won't care (probably battery backed ram, redundant
storage, and separate out-of-band monitoring facilities). 

If the cache sync fails, the best we can do is notify the user, we can't
reissue the write or even tell the user what block failed to make it to
disk, the best we can do is say "your hosed".

-- Patrick Mansfield

  reply	other threads:[~2003-10-03 21:37 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20030922004943.E32009@one-eyed-alien.net>
2003-09-22 14:25 ` [linux-usb-devel] Re: USB storage problems on OHCI Alan Stern
2003-09-22 14:31   ` Christoph Hellwig
2003-09-22 15:11     ` Christoph Hellwig
2003-09-22 15:49       ` Patrick Mansfield
2003-09-22 16:09         ` [linux-usb-devel] " Linus Torvalds
2003-09-22 16:42           ` Alan Stern
2003-09-22 17:23           ` Patrick Mansfield
2003-09-22 17:41             ` [linux-usb-devel] " Linus Torvalds
2003-09-22 17:55               ` James Bottomley
2003-09-22 19:55                 ` [linux-usb-devel] " Linus Torvalds
2003-09-23 17:47                   ` Ruud Linders
2003-09-23 18:16                     ` Linus Torvalds
2003-09-24 16:40                       ` Ruud Linders
2003-09-24 16:53                         ` Linus Torvalds
2003-09-26 18:43                           ` Alan Stern
2003-10-03 14:18                             ` Alan Stern
2003-10-03 15:05                               ` James Bottomley
2003-10-03 21:35                                 ` Patrick Mansfield [this message]
2003-09-22 18:46           ` Alan Cox
2003-09-22 16:37         ` [linux-usb-devel] " Christoph Hellwig
2003-09-22 16:44           ` Patrick Mansfield
2003-09-22 17:21             ` Christoph Hellwig
2003-09-22 19:01               ` Alan Stern
2003-09-22 15:50       ` Alan Stern
2003-09-22 15:58         ` Patrick Mansfield
2003-09-22 16:36           ` [linux-usb-devel] " Alan Stern
2003-09-22 16:38         ` Christoph Hellwig
2003-09-22 15:29   ` [linux-usb-devel] " Linus Torvalds
2003-09-22 16:22     ` David Brownell
2003-09-22 16:31       ` [linux-usb-devel] " Linus Torvalds
2003-09-22 17:13         ` David Brownell
2003-09-22 17:29           ` Linus Torvalds
2003-09-22 17:49             ` [linux-usb-devel] " David Brownell
2003-09-22 18:40               ` Linus Torvalds
2003-09-22 19:14                 ` Alan Stern
2003-09-22 16:58       ` [linux-usb-devel] " Martin Diehl
2003-09-22 17:19         ` David Brownell
2003-09-22 18:55 Andries.Brouwer
2003-09-22 19:28 ` [linux-usb-devel] " James Bottomley
  -- strict thread matches above, loose matches on Subject: below --
2003-09-22 19:56 Andries.Brouwer
2003-09-22 20:48 ` Alan Stern
2003-09-22 20:51 ` Matthew Dharm
2003-09-23 14:04 ` James Bottomley
2003-09-22 22:55 Pat LaVarre
2003-09-29 14:54 ` Pat LaVarre
2003-09-22 23:07 Andries.Brouwer
2003-09-23 14:37 Andries.Brouwer
2003-09-23 14:51 ` James Bottomley
2003-09-23 15:46 ` Linus Torvalds
2003-09-23 15:23 Alan Stern
2003-09-24 14:10 ` [linux-usb-devel] " James Bottomley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20031003143518.A16624@beaverton.ibm.com \
    --to=patmans@us.ibm.com \
    --cc=Andries.Brouwer@cwi.nl \
    --cc=James.Bottomley@SteelEye.com \
    --cc=david-b@pacbell.net \
    --cc=greg@kroah.com \
    --cc=hch@infradead.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=linux-usb-devel@lists.sourceforge.net \
    --cc=mdharm-usb@one-eyed-alien.net \
    --cc=rkmp@xs4all.nl \
    --cc=stern@rowland.harvard.edu \
    --cc=torvalds@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox