All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@suse.de>
To: James Bottomley <James.Bottomley@SteelEye.com>
Cc: Jeff Garzik <jgarzik@pobox.com>, Doug Maxey <dwm@maxeymade.com>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>,
	SCSI Mailing List <linux-scsi@vger.kernel.org>
Subject: Re: [PATCH] scsi/sata write barrier support
Date: Fri, 28 Jan 2005 14:10:58 +0100	[thread overview]
Message-ID: <20050128131057.GM4800@suse.de> (raw)
In-Reply-To: <1106917600.5175.5.camel@mulgrave>

On Fri, Jan 28 2005, James Bottomley wrote:
> On Fri, 2005-01-28 at 10:38 +0100, Jens Axboe wrote:
> > +/*
> > + * snoop succesfull completion of mode select commands that update the
> > + * write back cache state
> > + */
> > +#define MS_CACHE_PAGE	0x08
> > +static void sd_snoop_cmd(struct scsi_cmnd *cmd)
> > +{
> > +	struct scsi_disk *sdpk;
> > +	char *page;
> > +
> > +	if (cmd->result)
> > +		return;
> > +
> > +	switch (cmd->cmnd[0]) {
> > +		case MODE_SELECT:
> > +		case MODE_SELECT_10:
> > +			page = cmd->request_buffer;
> > +			if (!page)
> > +				break;
> > +			if ((page[0] & 0x3f) != MS_CACHE_PAGE)
> > +				break;
> > +			sdpk = dev_get_drvdata(&cmd->device->sdev_gendev);
> > +			sdpk->WCE = (page[2] & 0x04) != 0;
> > +			break;
> > +	}
> > +}
> > +
> >  /**
> >   *	sd_rw_intr - bottom half handler: called when the lower level
> >   *	driver has completed (successfully or otherwise) a scsi command.
> > @@ -773,6 +831,9 @@ static void sd_rw_intr(struct scsi_cmnd 
> >  			SCpnt->sense_buffer[13]));
> >  	}
> >  #endif
> > +
> > +	sd_snoop_cmd(SCpnt);
> > +
> 
> Good grief no!
> 
> If you're going to try something like this, it needs to be a separate
> patch over the scsi-list for one thing.  And to save time:
> 
> 1) The patch is actually wrong.  There's more than one caching mode page
> and not all of them affect current behaviour.

It also gets the offset wrong :)

> 2) We have a current interface to update the WCE bit:  You twiddle all
> the disc parameters and then trigger a device rescan via sysfs (I'll
> check that this updates the cache bits, I think it does, but if it
> doesn't I'll make it).
> 3) If we think this is a quantity the users would like to see and alter,
> then reading and setting it should be exported via sysfs.
> 4) Snooping SCSI commands is really bad ... it can get you into all
> sorts of trouble which is why we prefer asking the device what state
> it's in to trying to guess ourselves.

I would _much_ prefer some sort of easily tweakable way to change the
write back mode, if this is something we want to support. As I wrote in
the original reply, I hate the concept of command snooping.

The barrier stuff works fine as-is, I'll just rely on scsi getting the
WCE updating correct.

-- 
Jens Axboe


  reply	other threads:[~2005-01-28 13:11 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-27 12:02 [PATCH] scsi/sata write barrier support Jens Axboe
2005-01-27 15:08 ` [PATCH] scsi/sata write barrier support #2 Jens Axboe
2005-01-27 23:02   ` Jeff Garzik
2005-01-27 22:42 ` [PATCH] scsi/sata write barrier support Doug Maxey
2005-01-27 23:00   ` Jeff Garzik
2005-01-28  6:54     ` Jens Axboe
2005-01-28  8:10       ` Jeff Garzik
2005-01-28  8:18         ` Jens Axboe
2005-01-28  9:38           ` Jens Axboe
2005-01-28 13:06             ` James Bottomley
2005-01-28 13:10               ` Jens Axboe [this message]
2005-01-28 13:12             ` James Bottomley
2005-01-28  6:58   ` Jens Axboe
2005-02-22  4:42 ` Greg Stark
2005-02-22  7:13   ` Jens Axboe
2005-02-22 17:06     ` Greg Stark
2005-03-01  8:47       ` Jens Axboe
2005-03-01 15:55         ` Greg Stark

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=20050128131057.GM4800@suse.de \
    --to=axboe@suse.de \
    --cc=B.Zolnierkiewicz@elka.pw.edu.pl \
    --cc=James.Bottomley@SteelEye.com \
    --cc=dwm@maxeymade.com \
    --cc=jgarzik@pobox.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.