Hi Christ,
On Wed, 2016-03-16 at 19:36 -0700, Schlacta, Christ wrote:
> I have most of my targets exported to Windows desktops at the moment.
> My first goal is to centralize big games onto a central file server
> with an SSD cache (Check). I have a few desktops running emulex
> cards, and using OneCommand Manager to manage them all, and on the
> server side, most volumes are snapshot+clone images from a single
> shared master, so that updates take up space, but the original install
> is shared (Right now cerca 1GB per machine, but 250GB shared). Works
> well, but I've encountered some strange problems on the management
> side, and I want to know where the problem lies, is it with LIO in
> general, is it with my LIO Config, or is it with OneCommand Manager
> from Emulex, or possibly, with the Windows Emulex drivers. If it is a
> client bug, and there's not an easy server-side workaround, I'll
> contact Emulex, but I'm hopeful someone knows exactly what's wrong and
> can tell me how to fix it.
Just curious if you where able to sort out this Emulex OCM + MSFT host
side with issue using block_size=4k..?
Btw, AFAICT 4k sector support is a Windows 8 + Servers 2012 feature, I
assume you're running one of those, right..?
>
> The problem is twofold. First, any LUN exported as 4K shows in OCM
> with "n/a" in EVERY field of the LUN INformation tab. It's as if
> OCM acknowledges that it exists, but knows nothing about it. Other
> than this, it functions sufficiently at the OS level, in that I can
> read and write data to the drive.
>
> Second, If LUN 0 is a 4K drive, OCM shows absolutely no information
> about any LUNs, and actually goes so far as to say "No Luns are
> available", as I happily run Diablo 3 from my SAN. I actually assume
> this second facet is in fact a OCM bug and not a LIO or COnfig bug,
> but I hope fixing 1 will resolve this as well.
>
> Finally, worth noting, 4K volumes perform in excess of 4x faster on
> random IOPS and Sequential Read, in large part because of the backing
> ZFS filesystem and COW operations on a wide raidz pool. I'd get
> better performance with a larger block size, but alas, I also
> introduce other issues on the Windows side.
Interesting..
>
> Below is an inline of my config file, with some superfuous snippets
> removed. All attributes and parameters are preserved so as to ensure
> nothing important is omitted.
>
> Thank you for any and all assistance. I'll probably have 1 more
> request for help after this one is resolved. Wish there was something
> like an issue tracker to make this easier.
>
> storage fileio {
> disk common.empty {
> buffered no
> path /vdisk/common/img
> size 1.0GB
> wwn 31b83880-1ea3-40d6-a72e-3547361a6e15
> attribute {
> block_size 512
> emulate_3pc yes
> emulate_caw yes
> emulate_dpo yes
> emulate_fua_read yes
> emulate_fua_write yes
> emulate_model_alias yes
> emulate_rest_reord no
> emulate_tas yes
> emulate_tpu no
> emulate_tpws no
> emulate_ua_intlck_ctrl no
> emulate_write_cache no
> enforce_pr_isids yes
> fabric_max_sectors 8192
> is_nonrot yes
> max_unmap_block_desc_count 1
> max_unmap_lba_count 8192
> max_write_same_len 4096
> optimal_sectors 16384
> queue_depth 128
> unmap_granularity 1
> unmap_granularity_alignment 0
> }
> }
> disk izanami.games {
> buffered no
> path /vdisk/izanami/games/img
> size 256.0GB
> wwn 4aba9819-afa7-4746-b03b-d6456d4fb802
> attribute {
> block_size 4096
> emulate_3pc yes
> emulate_caw yes
> emulate_dpo yes
> emulate_fua_read yes
> emulate_fua_write yes
> emulate_model_alias yes
> emulate_rest_reord no
> emulate_tas yes
> emulate_tpu no
> emulate_tpws no
> emulate_ua_intlck_ctrl no
> emulate_write_cache no
> enforce_pr_isids yes
> fabric_max_sectors 8192
> is_nonrot yes
> max_unmap_block_desc_count 1
> max_unmap_lba_count 8192
> max_write_same_len 4096
> optimal_sectors 2048
Might be worth-while to try with optimal_sectors=4096..
Beyond that, the backend configuration looks as expected.
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
