Re: Multi-Actuator SAS HDD First Look

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Bart-

Yes, the header LUN field. Sorry!

We hadn't intended to broadcast - we expect to see a LUN specified.
For a device specific command both LUNs will be affected regardless of
which LUN is specified in the transport field. e.g. if we command LUN1
to stop (START STOP UNIT) then LUN0 will also be stopped.

Sorry if my terminology wasn't entirely clear - some jargon and
informal usage slipping through.

Best regards,
-Tim

-Tim

On Fri, Mar 30, 2018 at 12:17 PM, Bart Van Assche
<Bart.VanAssche@xxxxxxx> wrote:
> On Fri, 2018-03-30 at 12:07 -0600, Tim Walker wrote:
>> Concerning how we are currently allocating commands to LUNs or the
>> device as a whole, here is a list based on the current two LUN model.
>> This model has LUN0 & LUN1, both reporting 1/2 the total storage. Our
>> definition of "device based" is that it ignores the LUN field and
>> executes the command on the entire device. [ ... ]
>
> Hello Tim,
>
> Can you clarify what "LUN field" means in this context? Are you referring
> to a field in the SAS transport header or perhaps to the obsolete LUN
> field in the SCSI CDB? Additionally, as far as I know every SCSI command
> should be executed by exactly one SCSI LUN. I'm not aware of any support
> in the SCSI specs for broadcasting a single SCSI command to multiple LUNs.
>
> Thanks,
>
> Bart.
>
>
>
>



-- 
Tim Walker
Product Design Systems Engineering, Seagate Technology
(303) 775-3770



[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux