SyncMount

Summary

Mount removable storage devices with the 'sync' option. This will make the procedure of mounting/unmounting devices transparent to the end user, who will never need to learn what "mounting" is.

Rationale

The mount/unmount paradigm is merely a technicality. End users do not understand why devices should be mounted. The problem is particularly worrying in the case of removable devices and media (e.g. floppy disk). The data appears to be on the disk. Then, you remove the floppy without unmounting and wonder why no data has been written. As long as stuff can be removed, users will remove it. We should take this into account.

Use cases

* Mary connects a USB stick to her computer. She copies a file from her hard drive to the USB stick, but forgets to unmount the device. She goes to work with her presentation safely in her USB stick. Guess what ...

* Kontossis is a lifelong Windows User. He just installed Ubuntu and I'm showing him around his Desktop. He is impressed that floppies appear on the desktop. Then I tell him that before removing anything, he has to "unmount" it. It's quite embaressing to have to explain what unmounting is, why he needs to care and why he didn't have to do so on Windows.

Scope

This is a different spec from AutoUnmountNotifications. That specification deals with notifying users and convince them that they have to unmount their devices, this specification deals with removing the need for unmounting devices altogether and prompting users to reinsert the device in the event that they removed it during I/O.

Implementation

I am not exactly sure what needs to be changed and how. Whatever mounts these devices (g-v-m ?) should be modified to mount them with "-o sync". As far as I can currently see, we should:

- Modify the behaviour of g-v-m to mount everything with the 'sync' option enabled.

- Modify the behaviour of g-v-m (??) to detect when a device has been removed and remove the icon from the desktop.(really unmount the device)

- Modify the behaviour of g-v-m (?) to warn if a device has been removed during I/O work and demand that the user connects it again.

As noted by crimsun, we will have to discriminate between device classes, since it is expected to be able to disconnect USB audio devices while they are being used.

Outstanding issues

A major outstanding issue is the performance drop. Generally speaking, this is not so much of a problem because:

1. I'd take a performance hit over data loss any day. I don't think that there are many people who would argue otherwise.

2. People migrating from Windows will not be disappointed by the performance loss. This is because they will a) Blame the hardware b) Not know that "it could be faster", because they get similar speeds on Windows too.

  • From Sam Morris on ubuntu-devel: This is not true. Windows flushes write operations to the disk when a file is closed, thus one gets the performance benefit from the disk being cached without having to worry about uncommitted data hanging around when the disk is removed.

NicholasWheeler pointed out that there are some people that run their laptop off a USB hard drive. Of course, mounting '/' 'sync' will give these people terrible performance. This is a non-issue. We are not mounting all filesystems 'sync'. Filesystems that g-v-m mounts are not filesystems that are mounted as '/' anyway.

An argument was also made that this might not be the desired behaviour in the case of large USB hard disks. The counter-arguments are (1),(2) again, plus the important factor that few people extensively manipulate data on USB hard disks back-and-forth all the time, so that they would benefit from 'async'. They usually copy stuff from their HD to the USB device in large "chunks". ie. They seldomly make a large number of small changes - a situation in which the 'async' option would make a great difference.

SimonLaw pointed out that if we are to demand that users insert the device if it was removed during I/O, we might as well use async anyway. If I understand matters correctly, this is a different issue. If we mounted async and the user sees that "the file is on the floppy", removed it and then got prompted to insert the device "to complete the writing process" the user will be left wondering why it wasn't being written all this time.

* The biggest outstanding issue is that of MTBF. Flash devices can only be written two N times. Mounting devices 'sync' would thus decrease the lifetime of flash devices. The question here is how big is N. So far I haven't managed to find a reliable source, but from various sources I gather that N is minimum 10^5. Supposing that in the worst case a user performs 50 writes a day (which on average, is not that little), it gives them roughly 5.5 years of life, which is probabably OK considering that this is worst-case-analysis and that in 6 years today's flash devices will be obsolete anyway.

JohnDong adds that due to kernel VFAT behavior, mounting VFAT devices sync significantly increases the number of write cycles in a way to prematurely wear out flash devices. However, even then it's not realistic, if 10^6 is indeed the limit, for this to be a problem.

Many people claim that N=10^6. Here's something on the subject.

From http://www.bitmicro.com/press_resources_flash_ssd_db.php : "Most NAND Flash manufacturers today claim a write endurance of 1 million write cycles per block. "

BoF agenda and discussion

CategorySpec

SyncMount (last edited 2008-08-06 16:26:28 by localhost)