Re: Flames over -- Re: Which is simpler?

[Phillip Susi <psusi@cfl.rr.com>]

Olivier Galibert wrote:
> 
> If I understand USB correctly, it's all point-to-point, there is no
> broadcast going on.  For enumeration purposes hubs are not
> transparent, and ports are separated.  But I wouldn't rely on the
> ports numbers on hubs to stay constant w.r.t the physical ports.  I
> don't think it's required.
> 

Hrm... that last part is crucial I think.  If the kernel can tell there 
is a device still physically connected to the same port after the 
suspend, then it could reconnect that device to the existing node, and 
maybe notify the filesystem that the disk may have changed, so it should 
attempt to verify it, the way windows does.

As for the heuristics, don't most filesystems keep a mount count in the 
superblock?  What better way to decide if things are changed than having 
the filesystem check that the superblock looks to be the same and 
specifically that it's mount count has not increased.  I don't think the 
tests need to be that complex to get rather reasonably accurate results, 
and trying to put them in user space is asking for a lot of race 
conditions that would be solved by having the filesystem handle it.

> Since it's an hotplug bus, enumeration before suspend happened as the
> devices were plugged in.  So the order a reboot enumeration will see
> them is unknown in practice.
> 

Ahh, right... I didn't think of that; the bus may have changed since the 
initial enumeration, so a re-enumeration will be different.  I was just 
thinking of the case where it didn't change while suspended.

> It may be fixable by storing some kind of physical address in the
> tree, but losing a filesystem because you replugged the usb drive in
> the wrong physical port between suspend and resume would be annoying.
> And I don't know how stable the "physical" positions are in the first
> place.