--On Sunday, June 22, 2014 03:45:08 AM +0530 Ritesh Raj Sarraf
<[email protected]> wrote:
On 06/22/2014 02:38 AM, Sarraf, Ritesh wrote:
As long as I have not succeeded to construct a proper isolated reproducible
test case which fails consistently, there's not much reason to start changing
or trying anything I guess.
[rrs] Thanks. Please keep us posted once you have concluded on a persistent "steps
to reproduce".
Bill,
You reported this issue originally on a non NetApp box. From what we
suspect, this has more to do with the UNMAP implementation in the Linux
kernel, for which proper support was very recent.
Would you be in a position to verify this against a newer kernel ??
Apologies for being so slow in responding.
We have a working solution after iterating through multiple
configuration changes on both the NetApp box and the debian system.
Our first consistent success came after ALUA was disabled on the
NetApp. With a modified configuration we were able to subsequently
enable ALUA. Unfortunately I don't know that details of the changes
made to the NetApp boxes other than what I just told you. Here is the
working multiplath configuration we are using on the Debian systems.
devices {
device {
vendor "NETAPP"
product "LUN"
failback immediate
features "1 queue_if_no_path"
hardware_handler "1 alua"
path_checker directio
path_grouping_policy group_by_prio
path_selector "round-robin 0"
prio "alua"
rr_weight uniform
rr_min_io 128
}
}
As I said I am not sure exactly what modifications where made on the
NetApp, but I do know that as we upgraded our AFS servers to wheezy
we requested that the storage folks re-initialize the storage.
As to testing, we do have a system that we can make changes on, but I
am not sure it is useful at this point since we no longer see the
failure.
Bill
--
Bill MacAllister
Systems Programmer, Stanford University
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
