#7198 HIGH Never A: identically-named usb keys become invisible/unmountable (race)

[Zarro Boogs per Child]

#7198: identically-named usb keys become invisible/unmountable (race)
---------------------------+------------------------------------------------
 Reporter:  sj             |       Owner:  jg            
     Type:  defect         |      Status:  new           
 Priority:  high           |   Milestone:  Never Assigned
Component:  new component  |     Version:  Update.1      
 Keywords:                 |    Verified:  0             
 Blocking:                 |   Blockedby:                
---------------------------+------------------------------------------------
 For a new "USB" component:

 If I have two identically named USB keys (say, two new ones from the same
 manufacturer that are not identified by a hash but are given a name at the
 factory), and insert them both at roughly the same time into my XO, I can
 get the following scenario:

 1) Only one key is visible in the journal, although both keys are mounted
 by the OS.  I can unmount one from the journal, but can unmount both from
 the terminal.

 From the terminal, I can see both /media/<NAME> and /media/<NAME>_1 ...
 however, looking into /media/*/.olpc.store/metainfo, a slow race condition
 is visible.  I had two keys named MINI TD, and this is what it looked
 like:

 The metainfo for /media/MINI_TD :

  (dp1
  S'title'
  p2
  S'/media/MINI TD'
  ..
  p5
  sS'uri'
  p6
  S'/media/MINI TD_1'
  ...

 The metainfo for /media/MINI_TD_1 :

  S'title'
  p2
  S'/media/MINI TD'
  ..
  p5
  sS'uri'
  p6
  S'/media/MINI TD_2'
  ...


 If I am more measured, and insert the two keys many seconds apart, I get
 the slightly better situation:

 2) both keys are visible in the journal, but they are given the same name
 in Sugar. (in this case, both "MINI_TD")


 Sometimes, when arriving in state 1 and trying to get to state 2, I have
 plugged a key from 1) back into a new machine, waiting for it to be
 recognized, waiting another while (15 seconds?  half a minute?) and
 inserting the second key --- but the second key is still not recognized.
 I'm not sure why this is.  A sure way to resolve the issue seems to be to
 try a second time, making sure the first key of the pair inserted into a
 machine is the same one tried previously.

 This can be a significant issue when any group is trying to do bulk
 modifications involving usb keys with many machines and many keys in play.

-- 
Ticket URL: <http://dev.laptop.org/ticket/7198>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system