Ticket #2413 (closed defect: duplicate)

Opened 7 years ago

Last modified 7 years ago

User should not know about "unmounting"

Reported by: Zack Owned by: Eben
Priority: high Milestone: Trial-3
Component: interface-design Version:
Keywords: Cc: Eben, Zack, bcsaller
Action Needed: Verified: no
Deployments affected: Blocked By:
Blocking:

Description

Currently the journal relies on the user unmounting a given removable storage device when they're done using it. This is both broken and fixable; the easiest way would be to just mount media with the sync option, so that every write is immediately committed to the device. There may be other fancy ways to go about this, but I think we should at least to something to get "unmount" out of Trial-2.

Change History

Changed 7 years ago by tomeu

  • cc Eben added

I tried to discuss this issue here: http://lists.laptop.org/pipermail/devel/2007-June/005585.html

I would like for somebody nearer to the kernel say if using sync for removable devices is safe and won't have negative consequences in big capacity devices, etc.

Please note also that the mount man page says that the sync option is only for ext2(3)fs and ufs, I expect to find a majority of sticks with a FAT fs.

As the datastore service will be the only process to write to those devices, perhaps it could ask the OS to sync the buffers for that device after every write?

Regarding how to avoid having half written content (sync doesn't solve this issue), I think we can implement Ivan's proposal after trial2.

Eben, have you already thought about the user experience part of it? Can we avoid the unmount option somehow?

Changed 7 years ago by marco

I don't think this is Trial-2 really. There are enough problems with usb devices in the journal that we should focus on these and leave user experience refinements for later.

Changed 7 years ago by coderanger

Adding reporter to CC list

Changed 7 years ago by coderanger

  • cc Zack added

Adding reporter to CC list

Changed 7 years ago by Zack

Marco, the reason I think this is so serious is the high potential for data loss.

Changed 7 years ago by jg

  • priority changed from blocker to high
  • milestone changed from Untriaged to Trial-3

At least part of this is not soluble even if you make this synchronous; a truncated file is corrupted at an application level, and you can't avoid that, or that kids may pull USBs out without warning.

At best, we can indicate it is safe to unplug a device.

VFAT, for all its warts, is pretty synchronous for its meta-data (file name, dates, etc); its relatively robust to such behavior, though it pays for this in lower performance than a UNIX/Linux file system such as ext3 or others. It does cache data writes, and you can end up with short files if you pull it out.

The reason the "sync" options exist for ext3 is exactly because those file systems allow and are expected to cache meta-data writes (for performance).

So, to first order, I don't think we need to do anything right now (except to ensure the system doesn't hang if a device is unplugged mid-stream).

I think there is a separate discussion about whether we should try to deal with transactional semantics and the datastore at some future time; but not for Trial-2. This is a feature, and a complex one.

Changed 7 years ago by J5

We went through this when implementing automounting USB sticks in Linux. Sync kills flash disks. A disk that would last years being written to can die within a month with using sync with any filesystem using a file allocation table. The issue is that each memory block can only be erased a certain amount of times. Since the FAT is contained on a fixed portion of the disk every time you do a write you are erasing and writing to blocks in that fixed portion. jffs2 avoids this by generating its table in memory every time you boot. Forcing people to format their usb sticks doesn't work so we are stuck with FAT. The fix here is both short term and long term. The short term fix is make it prevalent in the UI, not just the journal. The long term fix would be to somehow write a caching file system which could resume if the user pulls out the key, i.e. user pulls drive, sugar yells at them, user puts drive back in, sugar repairs the file system, flushes its cache and unmounts the drive. For now we can just yell at them.

Changed 7 years ago by tomeu

  • cc bcsaller added

So Eben, if our best bet here for trial3 is to just inform the user of when the device is busy, can you spec it and attach the needed icons?

Need to do something when the user pulls out the device before unmounting first? This could be a chance to educate the user and prevent data loss in future occasions.

Ben, you think implementing something like [1] is feasible for trial3? This could be a compromise between just yelling and J5's proposal of caching in flash and resuming interrupted writes.

[1] http://lists.laptop.org/pipermail/devel/2007-June/005586.html

Changed 7 years ago by marco

  • owner changed from tomeu to Eben
  • component changed from journal-activity to interface-design

Reassigning to Eben. I think for Gen1 we should just "solve" this at the UI level.

Changed 7 years ago by Eben

  • status changed from new to closed
  • resolution set to duplicate

This ticket is basically a duplicate of #2630. In that ticket I will cover:

  • badge for busy state
  • badge for early removal state
  • visual spec for device icon

Most of this is already spec'd at the experience level, but the icons aren't yet provided.

Note: See TracTickets for help on using tickets.