Re: [PATCH update] firewire: fix "kobject_add failed for fw* with -EEXIST"

[Stefan Richter <stefanr@s5r6.in-berlin.de>]

Jarod Wilson wrote:
> We may have another issue there though, as when this happened to me, the md 
> layer apparently never noticed (after ~6 hours) that one of the array members 
> had disappeared -- not sure if that's firewire's fault or md's though... This 
> will presumably avoid this situation entirely, but worth noting that there 
> may still be somewhere we need to better communicate status to an upper 
> layer.

I don't know how md ticks, so I have no idea what might have happened there.

Somewhat related:  What if
  - we lose connection to disk "A", represented by scsi_device "a",
  - the SCSI core sets "a" offline,
  - we gain connection to disk "A" again (i.e. it only shortly
    disappeared from the bus from firewire-core's and -sbp2's point
    of view),
  - and firewire-sbp2 adds it as scsi_device "b", even before SCSI
    core got rid of "a"?
No big problem for stand-alone volumes (unless it happens when the
volume is in use), but maybe trouble for md managed volumes.

To smooth such issues out, my longer term goal was to allow brief
periods of disconnection in (firewire-)sbp2.  I.e. the SCSI core
wouldn't notice that "A"/"a" went away, it would only notice that "a"
wasn't accessible for a short time.  I think the Fibre Channel drivers
already support this.  The ieee1394 driver even has a "limbo" for
devices which went away, in order to remember them until they come back,
but sbp2 doesn't use this feature.  (Nobody did the work to enhance sbp2
to utilize the feature.)

BTW, if you unplug and replug a FireWire disk under Mac OS X fairly
quickly, OS X will pretend that nothing happened and let the user
continue using the disk if he hadn't "ejected" it before the brief
connection loss.

Anyhow, we have a few more urgent problems to solve in firewire-sbp2's
reconnection handling before we can think about such extras.
-- 
Stefan Richter
-=====-==--- ---= ===--
http://arcgraph.de/sr/