Re: [PATCH 0/4] scsi: 64-bit LUN support

[Hannes Reinecke]

On 02/21/2013 05:15 PM, Elliott, Robert (Server Storage) wrote:

Regarding changes like this:
-   printk(MYIOC_s_NOTE_FMT "[%d:%d:%d:%d] "
+   printk(MYIOC_s_NOTE_FMT "[%d:%d:%d:%llu] "
"FCP_ResponseInfo=%08xh\n", ioc->name,
sc->device->host->host_no, sc->device->channel,
sc->device->id, sc->device->lun,

It might be preferable to print the LUN values in hex rather than decimal,

> particularly if they are large values.  SAM-5 includes some guidance for
> displaying LUNs, shown below.


One important goal is to match the format, if any, that the user must use

> in a configuration file or command line argument, so cutting-and-pasting
> the LUN value works.  So, the answer might differ for prints from 
different

> drivers.  If a driver expects decimal input values, then print decimal.



Yes. And no.

The patchset is meant to be as a drop-in replacement, ie with _no_ user 
visible changes.

So I retained the original output.

Also, the above number is identical to the sysfs representation, where
the user will find a device like

/sys/class/scsi_device/X:Y:Z:L

with each X, Y, Z, and L being a decimal number.

_If_ we were to change that we would have to do it consistently for all 
instances, plus the sysfs layout.


But I guess we need to have a discussion about this, as I think not 
everybody agrees with that assessment.


Would be a nice topic for LSF, though.

Cheers,

Hannes

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] block: Avoid invoking blk_run_queue() recursively

[Bart Van Assche]

On 02/22/13 20:01, Jens Axboe wrote:

That'd be fine. I agree with Tejun that just returning is error prone
and could cause hard-to-debug hangs or stalls. So something ala

 if (blk_queue(dead))
 return;
 else if (q->request_fn_active) {
 blk_delay_queue(q, 0);
 return;
 }

would work. Alternatively, you could mark the queue as needing a re-run,
so any existing runner of it would notice and clear this flag and re-run
the queue. But that's somewhat more fragile, and since it isn't a
hot/performance path, I suspect the simple "just re-run me soon" is good
enough.


I'm worried that in the device mapper the approach using 
blk_delay_queue() could trigger a queue run after the final dm_put(). 
And I'm also afraid that that approach could trigger several needless 
context switches before q->request_fn_active finally drops to zero. So 
the approach with the "need re-run" flag seems preferable to me. But 
maybe I'm overlooking something ?


Bart.


--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html