On Wed, Apr 18, 2018 at 10:20 AM, Bart Van Assche
wrote:
> On Wed, 2018-04-18 at 05:16 -0600, Tim Walker wrote:
>> It would be good if we could set up an informal meeting time and
>> location at LSFMM to discuss these dual actuator topics. so far you,
>> Doug, Hannes, and Christoph have expressed
On Wed, 2018-04-18 at 05:16 -0600, Tim Walker wrote:
> It would be good if we could set up an informal meeting time and
> location at LSFMM to discuss these dual actuator topics. so far you,
> Doug, Hannes, and Christoph have expressed the most interest, plus
> Damien. Can we set an hour aside one
On Sun, Apr 15, 2018 at 10:31 PM, Bart Van Assche
wrote:
> On Sun, 2018-04-15 at 19:35 -0600, Tim Walker wrote:
>> I also believe the dual-actuator, or any significant HDD parallelism,
>> would map well onto an NVMe target, or NVMe-oF behind nvmet. Maybe a
>> lightweight virtual NVMe controller th
On Sun, 2018-04-15 at 19:35 -0600, Tim Walker wrote:
> I also believe the dual-actuator, or any significant HDD parallelism,
> would map well onto an NVMe target, or NVMe-oF behind nvmet. Maybe a
> lightweight virtual NVMe controller that would efficiently present the
> HDD logs/mode pages/etc via
On Mon, Apr 9, 2018 at 10:02 AM, Douglas Gilbert wrote:
>
> On 2018-04-09 02:17 AM, Hannes Reinecke wrote:
>>
>> On 04/09/2018 04:08 AM, Tim Walker wrote:
>>>
>>> On Fri, Apr 6, 2018 at 11:09 AM, Douglas Gilbert
>>> wrote:
On 2018-04-06 02:42 AM, Christoph Hellwig wrote:
>
>>>
On 2018-04-09 02:17 AM, Hannes Reinecke wrote:
On 04/09/2018 04:08 AM, Tim Walker wrote:
On Fri, Apr 6, 2018 at 11:09 AM, Douglas Gilbert wrote:
On 2018-04-06 02:42 AM, Christoph Hellwig wrote:
On Fri, Apr 06, 2018 at 08:24:18AM +0200, Hannes Reinecke wrote:
Ah. Far better.
What about del
On Fri, Apr 06, 2018 at 01:09:08PM -0400, Douglas Gilbert wrote:
> So you found a document that outlines NVMe's architecture! Could you
> share the url (no marketing BS, please)?
You can always take a look at the actual spec:
http://nvmexpress.org/wp-content/uploads/NVM-Express-1_3a-20171024_rati
On 04/09/2018 04:08 AM, Tim Walker wrote:
> On Fri, Apr 6, 2018 at 11:09 AM, Douglas Gilbert
> wrote:
>>
>> On 2018-04-06 02:42 AM, Christoph Hellwig wrote:
>>>
>>> On Fri, Apr 06, 2018 at 08:24:18AM +0200, Hannes Reinecke wrote:
Ah. Far better.
What about delegating FORMAT UNIT to
On Fri, Apr 6, 2018 at 11:09 AM, Douglas Gilbert wrote:
>
> On 2018-04-06 02:42 AM, Christoph Hellwig wrote:
>>
>> On Fri, Apr 06, 2018 at 08:24:18AM +0200, Hannes Reinecke wrote:
>>>
>>> Ah. Far better.
>>> What about delegating FORMAT UNIT to the control LUN, and not
>>> implementing it for the
On 2018-04-06 02:42 AM, Christoph Hellwig wrote:
On Fri, Apr 06, 2018 at 08:24:18AM +0200, Hannes Reinecke wrote:
Ah. Far better.
What about delegating FORMAT UNIT to the control LUN, and not
implementing it for the individual disk LUNs?
That would make an even stronger case for having a control
On Fri, Apr 06, 2018 at 08:24:18AM +0200, Hannes Reinecke wrote:
> Ah. Far better.
> What about delegating FORMAT UNIT to the control LUN, and not
> implementing it for the individual disk LUNs?
> That would make an even stronger case for having a control LUN;
> with that there wouldn't be any prob
On Thu, 5 Apr 2018 17:43:46 -0600
Tim Walker wrote:
> On Tue, Apr 3, 2018 at 1:46 AM, Christoph Hellwig
> wrote:
> > On Sat, Mar 31, 2018 at 01:03:46PM +0200, Hannes Reinecke wrote:
> >> Actually I would propose to have a 'management' LUN at LUN0, who
> >> could handle all the device-wide comm
On 2018-04-05 07:43 PM, Tim Walker wrote:
On Tue, Apr 3, 2018 at 1:46 AM, Christoph Hellwig wrote:
On Sat, Mar 31, 2018 at 01:03:46PM +0200, Hannes Reinecke wrote:
Actually I would propose to have a 'management' LUN at LUN0, who could
handle all the device-wide commands (eg things like START S
On Tue, Apr 3, 2018 at 1:46 AM, Christoph Hellwig wrote:
> On Sat, Mar 31, 2018 at 01:03:46PM +0200, Hannes Reinecke wrote:
>> Actually I would propose to have a 'management' LUN at LUN0, who could
>> handle all the device-wide commands (eg things like START STOP UNIT,
>> firmware update, or even
On Sat, Mar 31, 2018 at 01:03:46PM +0200, Hannes Reinecke wrote:
> Actually I would propose to have a 'management' LUN at LUN0, who could
> handle all the device-wide commands (eg things like START STOP UNIT,
> firmware update, or even SMART commands), and ignoring them for the
> remaining LUNs.
T
On Mon, Apr 2, 2018 at 10:29 AM, Douglas Gilbert wrote:
> On 2018-04-02 11:34 AM, Tim Walker wrote:
>>
>> On Sat, Mar 31, 2018 at 10:52 AM, Douglas Gilbert
>> wrote:
>>>
>>> On 2018-03-30 04:01 PM, Bart Van Assche wrote:
On Fri, 2018-03-30 at 12:36 -0600, Tim Walker wrote:
>
>>
On 2018-04-02 11:34 AM, Tim Walker wrote:
On Sat, Mar 31, 2018 at 10:52 AM, Douglas Gilbert wrote:
On 2018-03-30 04:01 PM, Bart Van Assche wrote:
On Fri, 2018-03-30 at 12:36 -0600, Tim Walker wrote:
Yes I will be there to discuss the multi-LUN approach. I wanted to get
these interface detai
On Sat, Mar 31, 2018 at 10:52 AM, Douglas Gilbert wrote:
> On 2018-03-30 04:01 PM, Bart Van Assche wrote:
>>
>> On Fri, 2018-03-30 at 12:36 -0600, Tim Walker wrote:
>>>
>>> Yes I will be there to discuss the multi-LUN approach. I wanted to get
>>> these interface details out so we could have some
On 2018-03-30 04:01 PM, Bart Van Assche wrote:
On Fri, 2018-03-30 at 12:36 -0600, Tim Walker wrote:
Yes I will be there to discuss the multi-LUN approach. I wanted to get
these interface details out so we could have some background and
perhaps folks would come with ideas. I don't have much more
On 03/30/2018 08:07 PM, Tim Walker wrote:
> Hello-
>
> 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" i
On 03/30/2018 03:07 PM, Tim Walker wrote:
> Hi Doug-
>
> Currently, the dual actuator firmware safely spins the drive down if
> either LUN receives the START STOP UNIT command. In other words, if
> LUN1 receives the command, it will flush any dirty data from LUN1l and
> LUN0, then spin down, taki
On Fri, 2018-03-30 at 12:36 -0600, Tim Walker wrote:
> Yes I will be there to discuss the multi-LUN approach. I wanted to get
> these interface details out so we could have some background and
> perhaps folks would come with ideas. I don't have much more to put
> out, but I will certainly answer qu
Yes I will be there to discuss the multi-LUN approach. I wanted to get
these interface details out so we could have some background and
perhaps folks would come with ideas. I don't have much more to put
out, but I will certainly answer questions - either on this list or
directly.
Best regards,
-Ti
On Fri, 2018-03-30 at 12:21 -0600, Tim Walker wrote:
> 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 comm
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 als
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
Hello-
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 comma
Hi Doug-
Currently, the dual actuator firmware safely spins the drive down if
either LUN receives the START STOP UNIT command. In other words, if
LUN1 receives the command, it will flush any dirty data from LUN1l and
LUN0, then spin down, taking both LUN1 & LUN0 off line. Alternatively,
we've had
On 2018-03-26 11:08 AM, Hannes Reinecke wrote:
On Fri, 23 Mar 2018 08:57:12 -0600
Tim Walker wrote:
Seagate announced their split actuator SAS drive, which will probably
require some kernel changes for full support. It's targeted at cloud
provider JBODs and RAID.
Here are some of the drive's
On Fri, 23 Mar 2018 08:57:12 -0600
Tim Walker wrote:
> Seagate announced their split actuator SAS drive, which will probably
> require some kernel changes for full support. It's targeted at cloud
> provider JBODs and RAID.
>
> Here are some of the drive's architectural points. Since the two LUNs
Seagate announced their split actuator SAS drive, which will probably
require some kernel changes for full support. It's targeted at cloud
provider JBODs and RAID.
Here are some of the drive's architectural points. Since the two LUNs
share many common components (e.g. spindle) Seagate allocated so
31 matches
Mail list logo
