Re: Issue with Open-iSCSI on Fedora 18 & Ext4

[Mike Christie]

On 4/8/13 5:17 PM, erik...@gmail.com wrote:
>
> As I understand it WRITE SAME is an optional command to improve performance
> not supported by every device. Is it possible to disable its use, or at the
> very least, stop the kernel/driver from filling the logs with these
> messages?
>

The open-iscsi driver has no control over this. I think there is a ext4
mounting option to control the feature. I think in newer kernels the
scsi layer will disable the use of the feature when you get the first
illegal request error but am not sure.

Or, I think you can disable it from sysfs if you set the
write_same_blocks file to 0.

[erik...@gmail.com]

On Tuesday, April 9, 2013 8:40:32 AM UTC-4, Mike Christie wrote:

The open-iscsi driver has no control over this. I think there is a ext4
mounting option to control the feature. I think in newer kernels the
scsi layer will disable the use of the feature when you get the first
illegal request error but am not sure.

Or, I think you can disable it from sysfs if you set the
write_same_blocks file to 0.

Mike,

Thanks very much! The kernel is a fairly new one (3.8.5) so any patch to do that would have had to be pretty recent, but it would be nice that's for sure.

# echo 0 > ./devices/platform/host11/session1/target11:0:0/11:0:0:0/scsi_disk/11:0:0:0/max_write_same_blocks

# echo 0 > ./devices/platform/host12/session2/target12:0:0/12:0:0:0/scsi_disk/12:0:0:0/max_write_same_blocks 

Setting the max_write_same_blocks to zero on both devices did work. The log spam has stopped and things appear to be working fine.

I assume this is lost on reboot and needs to be done at startup? Is there a mapping somewhere between the SCSI disk no (11, 12) and the UUID that I could use to ensure I get the right disks in a startup script?

Thanks

[Mike Christie]

On 04/09/2013 07:58 AM, erik...@gmail.com wrote:
>
>
> On Tuesday, April 9, 2013 8:40:32 AM UTC-4, Mike Christie wrote:
>
> The open-iscsi driver has no control over this. I think there is a ext4
> mounting option to control the feature. I think in newer kernels the
> scsi layer will disable the use of the feature when you get the first
> illegal request error but am not sure.
>
> Or, I think you can disable it from sysfs if you set the
> write_same_blocks file to 0.
>
>
> Mike,
> Thanks very much! The kernel is a fairly new one (3.8.5) so any patch to
> do that would have had to be pretty recent, but it would be
> nice that's for sure.
>
> # echo 0 >
> ./devices/platform/host11/session1/target11:0:0/11:0:0:0/scsi_disk/11:0:0:0/max_write_same_blocks
> # echo 0 >
> ./devices/platform/host12/session2/target12:0:0/12:0:0:0/scsi_disk/12:0:0:0/max_write_same_blocks
>
> Setting the max_write_same_blocks to zero on both devices did work. The
> log spam has stopped and things appear to be working fine.
>
> I assume this is lost on reboot and needs to be done at startup? Is

Yes.

> there a mapping somewhere between the SCSI disk no (11, 12) and the UUID
> that I could use to ensure I get the right disks in a startup script?
>

For your target does it export the UUID you see in /dev/disk/by-id in
some sort of management screen? If so then you can modify a udev hotplug
script to do what you want every reboot.

You can get the iscsi to sdX mappings by running iscsiadm -m session -P
3. In recent udevs you might be able to see the mapping in dev name form
in the /dev/disk/by-path.

Or, you might want to contact your target vendor. They might have a
updated firmware that fixes the problem.

[erik...@gmail.com]

I know there's a lot of assumptions made here, but they should be safe in my specific situation (like all my targets require this fix). I don't expect to be adding additional targets anytime soon so I think something as simple as this at startup would work for me:

for I in `iscsiadm -m session -P 3 | grep "Host Number" | awk '{RS="\n"; print $3}'`

do

 for SESSION in `ls /sys/devices/platform/host$I | grep session`

 do

  echo 0 > /sys/devices/platform/host$I/$SESSION/target$I:0:0/$I:0:0:0/scsi_disk/$I:0:0:0/max_write_same_blocks

 done

done

Thanks again. Maybe Synology will correct this in a future version of DSM, but as it stands I have the most current version.