From: Jeff Garzik <jgarzik@pobox.com>
To: Tejun Heo <htejun@gmail.com>
Cc: axboe@suse.de, James.Bottomley@steeleye.com, bzolnier@gmail.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH Linux 2.6.12-rc5-mm2 06/09] blk: update SCSI to use the new blk_ordered
Date: Sun, 05 Jun 2005 03:08:55 -0400 [thread overview]
Message-ID: <42A2A507.8060600@pobox.com> (raw)
In-Reply-To: <20050605055337.3CC8625A@htj.dyndns.org>
Tejun Heo wrote:
> 06_blk_update_scsi_to_use_new_ordered.patch
>
> All ordered request related stuff delegated to HLD. Midlayer
> now doens't deal with ordered setting or prepare_flush
> callback. sd.c updated to deal with blk_queue_ordered
> setting. Currently, ordered tag isn't used as SCSI midlayer
> cannot guarantee request ordering.
>
> Signed-off-by: Tejun Heo <htejun@gmail.com>
>
> drivers/scsi/hosts.c | 9 -----
> drivers/scsi/scsi_lib.c | 46 --------------------------
> drivers/scsi/sd.c | 79 +++++++++++++++++++--------------------------
> include/scsi/scsi_driver.h | 1
> include/scsi/scsi_host.h | 1
> 5 files changed, 34 insertions(+), 102 deletions(-)
>
> Index: blk-fixes/drivers/scsi/sd.c
> ===================================================================
> --- blk-fixes.orig/drivers/scsi/sd.c 2005-06-05 14:53:32.000000000 +0900
> +++ blk-fixes/drivers/scsi/sd.c 2005-06-05 14:53:35.000000000 +0900
> @@ -103,6 +103,7 @@ struct scsi_disk {
> u8 write_prot;
> unsigned WCE : 1; /* state of disk WCE bit */
> unsigned RCD : 1; /* state of disk RCD bit, unused */
> + unsigned DPOFUA : 1; /* state of disk DPOFUA bit */
> };
>
> static DEFINE_IDR(sd_index_idr);
> @@ -122,8 +123,7 @@ static void sd_shutdown(struct device *d
> static void sd_rescan(struct device *);
> static int sd_init_command(struct scsi_cmnd *);
> static int sd_issue_flush(struct device *, sector_t *);
> -static void sd_end_flush(request_queue_t *, struct request *);
> -static int sd_prepare_flush(request_queue_t *, struct request *);
> +static void sd_prepare_flush(request_queue_t *, struct request *);
> static void sd_read_capacity(struct scsi_disk *sdkp, char *diskname,
> struct scsi_request *SRpnt, unsigned char *buffer);
>
> @@ -138,8 +138,6 @@ static struct scsi_driver sd_template =
> .rescan = sd_rescan,
> .init_command = sd_init_command,
> .issue_flush = sd_issue_flush,
> - .prepare_flush = sd_prepare_flush,
> - .end_flush = sd_end_flush,
> };
>
> /*
> @@ -346,6 +344,7 @@ static int sd_init_command(struct scsi_c
>
> if (block > 0xffffffff) {
> SCpnt->cmnd[0] += READ_16 - READ_6;
> + SCpnt->cmnd[1] |= blk_fua_rq(rq) ? 0x8 : 0;
> SCpnt->cmnd[2] = sizeof(block) > 4 ? (unsigned char) (block >> 56) & 0xff : 0;
> SCpnt->cmnd[3] = sizeof(block) > 4 ? (unsigned char) (block >> 48) & 0xff : 0;
> SCpnt->cmnd[4] = sizeof(block) > 4 ? (unsigned char) (block >> 40) & 0xff : 0;
> @@ -360,11 +359,12 @@ static int sd_init_command(struct scsi_c
> SCpnt->cmnd[13] = (unsigned char) this_count & 0xff;
> SCpnt->cmnd[14] = SCpnt->cmnd[15] = 0;
> } else if ((this_count > 0xff) || (block > 0x1fffff) ||
> - SCpnt->device->use_10_for_rw) {
> + SCpnt->device->use_10_for_rw || blk_fua_rq(rq)) {
This seems suspicious, like it would cause unwanted use of READ(10) for
some devices that prefer READ(6) ?
> if (this_count > 0xffff)
> this_count = 0xffff;
>
> SCpnt->cmnd[0] += READ_10 - READ_6;
> + SCpnt->cmnd[1] |= blk_fua_rq(rq) ? 0x8 : 0;
> SCpnt->cmnd[2] = (unsigned char) (block >> 24) & 0xff;
> SCpnt->cmnd[3] = (unsigned char) (block >> 16) & 0xff;
> SCpnt->cmnd[4] = (unsigned char) (block >> 8) & 0xff;
> @@ -739,43 +739,12 @@ static int sd_issue_flush(struct device
> return sd_sync_cache(sdp);
> }
>
> -static void sd_end_flush(request_queue_t *q, struct request *flush_rq)
> +static void sd_prepare_flush(request_queue_t *q, struct request *rq)
> {
> - struct request *rq = flush_rq->end_io_data;
> - struct scsi_cmnd *cmd = rq->special;
> - unsigned int bytes = rq->hard_nr_sectors << 9;
> -
> - if (!flush_rq->errors) {
> - spin_unlock(q->queue_lock);
> - scsi_io_completion(cmd, bytes, 0);
> - spin_lock(q->queue_lock);
> - } else if (blk_barrier_postflush(rq)) {
> - spin_unlock(q->queue_lock);
> - scsi_io_completion(cmd, 0, bytes);
> - spin_lock(q->queue_lock);
> - } else {
> - /*
> - * force journal abort of barriers
> - */
> - end_that_request_first(rq, -EOPNOTSUPP, rq->hard_nr_sectors);
> - end_that_request_last(rq, -EOPNOTSUPP);
> - }
> -}
> -
> -static int sd_prepare_flush(request_queue_t *q, struct request *rq)
> -{
> - struct scsi_device *sdev = q->queuedata;
> - struct scsi_disk *sdkp = dev_get_drvdata(&sdev->sdev_gendev);
> -
> - if (sdkp->WCE) {
> - memset(rq->cmd, 0, sizeof(rq->cmd));
> - rq->flags |= REQ_BLOCK_PC | REQ_SOFTBARRIER;
> - rq->timeout = SD_TIMEOUT;
> - rq->cmd[0] = SYNCHRONIZE_CACHE;
> - return 1;
> - }
> -
> - return 0;
> + memset(rq->cmd, 0, sizeof(rq->cmd));
> + rq->flags |= REQ_BLOCK_PC | REQ_SOFTBARRIER;
> + rq->timeout = SD_TIMEOUT;
> + rq->cmd[0] = SYNCHRONIZE_CACHE;
> }
>
> static void sd_rescan(struct device *dev)
> @@ -1433,10 +1402,13 @@ sd_read_cache_type(struct scsi_disk *sdk
> sdkp->RCD = 0;
> }
>
> + sdkp->DPOFUA = (data.device_specific & 0x10) != 0;
> +
> ct = sdkp->RCD + 2*sdkp->WCE;
>
> - printk(KERN_NOTICE "SCSI device %s: drive cache: %s\n",
> - diskname, types[ct]);
> + printk(KERN_NOTICE "SCSI device %s: drive cache: %s%s\n",
> + diskname, types[ct],
> + sdkp->DPOFUA ? " with forced unit access" : "");
This is IMO a bit verbose. Just " w/ FUA" might be better.
> return;
> }
> @@ -1469,6 +1441,7 @@ static int sd_revalidate_disk(struct gen
> struct scsi_device *sdp = sdkp->device;
> struct scsi_request *sreq;
> unsigned char *buffer;
> + unsigned ordered;
>
> SCSI_LOG_HLQUEUE(3, printk("sd_revalidate_disk: disk=%s\n", disk->disk_name));
>
> @@ -1514,7 +1487,22 @@ static int sd_revalidate_disk(struct gen
> sreq, buffer);
> sd_read_cache_type(sdkp, disk->disk_name, sreq, buffer);
> }
> -
> +
> + /*
> + * We now have all cache related info, determine how we deal
> + * with ordered requests. Note that as the current SCSI
> + * dispatch function can alter request order, we cannot use
> + * QUEUE_ORDERED_TAG_* even when ordered tag is supported.
> + */
> + if (sdkp->WCE)
> + ordered = sdkp->DPOFUA
> + ? QUEUE_ORDERED_DRAIN_FUA : QUEUE_ORDERED_DRAIN_FLUSH;
Certainly 'DPO and FUA' implies we have FUA, but I wonder if this test
is unnecessarily narrow.
Jeff
next prev parent reply other threads:[~2005-06-05 7:09 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-05 5:57 [PATCH Linux 2.6.12-rc5-mm2 00/09] blk: ordered request reimplementation (take 2, for review) Tejun Heo
2005-06-05 5:57 ` [PATCH Linux 2.6.12-rc5-mm2 01/09] blk: add @uptodate to end_that_request_last() and @error to rq_end_io_fn() Tejun Heo
2005-06-05 5:57 ` [PATCH Linux 2.6.12-rc5-mm2 02/09] blk: make scsi use -EOPNOTSUPP instead of -EIO on ILLEGAL_REQUEST Tejun Heo
2005-06-05 7:10 ` Jeff Garzik
2005-06-07 1:34 ` Tejun Heo
2005-06-05 5:57 ` [PATCH Linux 2.6.12-rc5-mm2 03/09] blk: make ide use -EOPNOTSUPP instead of -EIO on ABRT_ERR Tejun Heo
2005-06-05 5:57 ` [PATCH Linux 2.6.12-rc5-mm2 04/09] blk: separate out bio init part from __make_request Tejun Heo
2005-06-05 5:57 ` [PATCH Linux 2.6.12-rc5-mm2 05/09] blk: reimplement handling of barrier request Tejun Heo
2005-06-05 5:57 ` [PATCH Linux 2.6.12-rc5-mm2 06/09] blk: update SCSI to use the new blk_ordered Tejun Heo
2005-06-05 7:08 ` Jeff Garzik [this message]
2005-06-07 1:58 ` Tejun Heo
2005-06-05 5:57 ` [PATCH Linux 2.6.12-rc5-mm2 07/09] blk: update libata " Tejun Heo
2005-06-05 7:02 ` Jeff Garzik
2005-06-07 2:11 ` Tejun Heo
2005-06-05 5:57 ` [PATCH Linux 2.6.12-rc5-mm2 08/09] blk: update IDE " Tejun Heo
2005-06-05 6:47 ` Jeff Garzik
2005-06-05 14:14 ` Bartlomiej Zolnierkiewicz
2005-06-07 2:26 ` Tejun Heo
2005-06-05 5:57 ` [PATCH Linux 2.6.12-rc5-mm2 09/09] blk: debug messages Tejun Heo
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=42A2A507.8060600@pobox.com \
--to=jgarzik@pobox.com \
--cc=James.Bottomley@steeleye.com \
--cc=axboe@suse.de \
--cc=bzolnier@gmail.com \
--cc=htejun@gmail.com \
--cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox