#6532 BLOC Update1: SD Card Corruption

[Zarro Boogs per Child]

#6532: SD Card Corruption
----------------------+-----------------------------------------------------
  Reporter:  haralds  |       Owner:  dsaxena          
      Type:  defect   |      Status:  assigned         
  Priority:  blocker  |   Milestone:  Update1.1 (8.1.1)
 Component:  kernel   |     Version:                   
Resolution:           |    Keywords:  release?         
  Verified:  0        |    Blocking:  6893             
 Blockedby:           |  
----------------------+-----------------------------------------------------

Comment(by PierreOssman):

 Replying to [comment:26 dsaxena]:
 > Chris, how hard would it be as a short-term measure to have our
 userspace either unmount the SD card or force a sync to the SD card before
 suspend?
 >

 Just remember that many filesystems mark the filesystem as dirty until it
 is unmounted. You'll probably remove the greatest risk for corruption
 using a sync though. Also, FAT will be fine using just sync. You should
 also note ticket #4013.

 > > The OLPC has a hardware bug that makes the system behave as if
 MMC_UNSAFE_RESUME is always disabled.
 >
 > Do you/we have any details/documentation on this?
 >

 Ticket #1339.

 Replying to [comment:27 cjb]:
 >
 > I'm still pretty confused about this, though. Why is sync(2) required to
 avoid *partition table corruption*, and why doesn't this happen on USB?
 >

 The partition table problem is most likely something else. The only so far
 known problem is lost writes, which should not cause any partition table
 issues. My first guess would be something power related.

 Replying to [comment:28 mstone]:
 >
 >Must we also pay attention to whether we're booted off of the peripheral
 storage device in question?
 >

 I have some faint recollection of suspend being actively crippled when
 booting of SD because of this problem.

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