Re: [PATCH] rbd: remove VLA usage

2018-03-30 Thread Gustavo A. R. Silva
On 03/30/2018 03:29 PM, Ilya Dryomov wrote: On Fri, Mar 30, 2018 at 9:17 PM, Gustavo A. R. Silva wrote: In preparation to enabling -Wvla, remove the use of stack VLA. In this particular case, variable buf_size is replaced with a constant expression that can be

Re: [PATCH] rbd: remove VLA usage

2018-03-30 Thread Ilya Dryomov
On Fri, Mar 30, 2018 at 9:17 PM, Gustavo A. R. Silva wrote: > In preparation to enabling -Wvla, remove the use of stack VLA. > > In this particular case, variable buf_size is replaced with a constant > expression that can be computed at preprocessing time. This avoids two

Re: Multi-Actuator SAS HDD First Look

2018-03-30 Thread Bart Van Assche
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

[PATCH] rbd: remove VLA usage

2018-03-30 Thread Gustavo A. R. Silva
In preparation to enabling -Wvla, remove the use of stack VLA. In this particular case, variable buf_size is replaced with a constant expression that can be computed at preprocessing time. This avoids two VLA warnings. Also, as a consequence of the mentioned change, some code was slightly

Re: Multi-Actuator SAS HDD First Look

2018-03-30 Thread Tim Walker
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,

Re: Multi-Actuator SAS HDD First Look

2018-03-30 Thread Bart Van Assche
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

Re: Multi-Actuator SAS HDD First Look

2018-03-30 Thread Tim Walker
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

Re: Multi-Actuator SAS HDD First Look

2018-03-30 Thread Bart Van Assche
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"

Re: Multi-Actuator SAS HDD First Look

2018-03-30 Thread Tim Walker
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

Re: v4.16-rc1 + dm-mpath + BFQ

2018-03-30 Thread Bart Van Assche
On Fri, 2018-03-30 at 10:23 +0200, Paolo Valente wrote: > Still 4.16-rc1, being that the version for which you reported this > issue in the first place. A vanilla v4.16-rc1 kernel is not sufficient to run the srp-test software since RDMA/CM support for the SRP target driver is missing from that

Re: Multi-Actuator SAS HDD First Look

2018-03-30 Thread Tim Walker
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

BUG at IP: blk_mq_get_request+0x23e/0x390 on 4.16.0-rc7

2018-03-30 Thread Yi Zhang
Hello I got this kernel BUG on 4.16.0-rc7, here is the reproducer and log, let me know if you need more info, thanks. Reproducer: 1. setup target #nvmetcli restore /etc/rdma.json 2. connect target on host #nvme connect-all -t rdma -a $IP -s 4420during my NVMeoF RDMA testing 3. do fio background

Re: 4.16-rc2+git: pata_serverworks: hanging ata detection thread on HP DL380G3

2018-03-30 Thread Meelis Roos
Added CC-s, start of the thread is at https://lkml.org/lkml/2018/2/26/165 > > > 4.16 git bootup on HP Proliant DL380 G3 pauses for a a minute or two and > > > then continues with "blocked for more than 120 seconds" message with > > > libata detection functions in ther stack - > > >

Re: v4.16-rc1 + dm-mpath + BFQ

2018-03-30 Thread Paolo Valente
+Jens, Mike > Il giorno 30 mar 2018, alle ore 01:16, Bart Van Assche > ha scritto: > > On Thu, 2018-03-29 at 11:02 +0200, Paolo Valente wrote: >>> Il giorno 01 mar 2018, alle ore 02:35, Bart Van Assche >>> ha scritto: >>> Thank you for having