Re: [dm-devel] RE: dm-devel Digest, Vol 11, Issue 18

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 
> Noticed already.  I am advocating that detecting path-to-LU inconsistency
> be adopted generically by the multipath configuration software using one
> of the two methods described in previous email and not be implemented
> piecemeal or just for CLARiion, Symmetrix, or EMC storage.
> 
> This could mean that the storage system getuid callouts become functions
> like the checker callouts and that by default, a storage system's getuid
> callout be used also as that storage system's path checker.
> 
Some assumptions are not that clear to me, so let me confront them to
your knowledge :

1) A Logical Unit can change its H/B/T/L mapping.
1.1) H/B/T through LUN masking reconfiguration
1.2) L through a logical unit reconfiguration
2) These topology changes can happen between two checks of the affected path
3) No path failure is seen by the device mapper during the topology
reconfiguration
4) Not failing or isolating the changed path from its previous multipath
map will lead to unrecoverable data corruption at the first submitted
write IO routed through this path
5) HBA drivers see the LU remapping events

If all these assertions are legitimate, it might not be enough to check
uid changes at pathcheck interval.

It would seem safer to let the HBA driver error the first IO submitted to a 
changed LU *and* send an event (maybe through a transport class kobj) for
userspace to reconfigure the maps.

Please comment abundantly.

regards,
cvaroqui


[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux