2.3. I Lost Data When I Removed My Floppy/Memory Stick
With older computers, floppy disks were sometimes a challenge for Linux. When you wrote a file to a floppy, the actual data might not get written to the disk for several minutes or more. If you ejected a disk before the write, you would lose the data that you thought you saved.
This is now an even bigger problem. Common options include USB keys or flash drives, as well as external hard drives that plug into a USB or IEEE 1394 (FireWire) port. When you copy data to one of these devices, Linux may not actually write the data to the media for minutes.
Thus, if you eject a floppy disk from its drive, disconnect an external hard drive, or remove a flash drive from its port before its time, you may lose data that you thought you saved.
To minimize this risk, you should change associated settings in your /etc/fstab and automounter (/etc/auto.*) configuration files. This annoyance provides just the briefest overview of how you can configure each of these files. For more information on the automounter, see "Regular Users Can't Mount the CD/DVD Drive" in Chapter 7.
In the next section, I'll show you how you can make it easier for regular users to manage floppy disks and USB keys, while minimizing the risks of data loss.
2.3.1. Modifying /etc/fstab for Removable Media
The default /etc/fstab configuration for removable media leaves something to be desired. Unless otherwise specified, reads and writes to all filesystems are done asynchronously. That's acceptable when the media is local, and permanently attached. But it's a problem for removable media.
It's also a problem for network media. You may lose data that you think you've saved to a network drive if the network fails. That is why Red Hat recommends the use of the sync directive for all mounted NFS drives, as network problems can interrupt file writes at any time.
Naturally, users are unpredictable. Accidents happen even to the most experienced administrators. USB keys may be knocked out of their slots. FireWire connections may come loose. One option is to make sure your /etc/fstab synchronizes data as quickly as possible. For this purpose, I've changed the defaults on several of my systems to include the sync option, including:
The managed directive is associated with automated updates, as driven by HAL through the fstab-sync command.
However, synchronous reads and writes can affect performance. Most flash drives have limits in the number of writes they can handle. While a typical flash drive is supposed to be able to handle several million write cycles, I wouldn't keep a flash drive plugged in all day. Nevertheless, the HAL system associated with SUSE Linux mounts USB drives with the sync option.
2.3.2. Automatic Mounts
As Linux moves forward, distributions are integrating the Hardware Abstraction Layer (HAL) daemon, which automatically detects and configures new hardware components. For example, when some distributions detect new drives such as cameras and USB keys, they add an appropriate directive to your /etc/fstab configuration file. As HAL is fairly new in many Linux distributions, it may not work with all of your hardware. Here, I show you how you can customize HAL. If you still have problems, I also illustrate how you can disable HAL.
One useful tool to see what HAL has detected is the HAL Device Manager, which is part of the Debian hal-device-manager package and the Red Hat/Fedora and SUSE hal-gnome packages. When you start the tool with the hal-device-manager command, you'll see a graphical overview of your hardware, similar to Figure 2-1.
Figure 2-1. The Hardware Device Manager
This section applies primarily to Red Hat/Fedora and Debian Linux; if you have a SUSE system, read the next section, "Other Hotplug Update Methods."
18.104.22.168. Customizing HAL
If you just want HAL to add the sync directive when it synchronizes detected hardware, you'll want to add a file, with an .fdi extension, to the /usr/share/hal/fdi/95userpolicy directory. For example, I've added the sync.fdi file, with the following entries, in the same XML format associated with other .fdi files:
<deviceinfo version="0.2"> <!-- Default policies merged onto computer root object --> <device> <match key="info.udi" string="/org/freedesktop/Hal/devices/computer"> <merge key="storage.policy.default.mount_option.sync" type="bool">true</merge> </match> </device> </deviceinfo>
To create sync.fdi, I've taken the pattern of XML directives from the storage-policy.fdi file in the /usr/share/hal/fdi/90defaultpolicy directory.
The deviceinfo directive specifies the default policies associated with detected removable drives. The second line, which starts with <!, is a comment. The third line, associated with the info.udi key, defines detected removable devices. The next line is key because it adds sync to the mount options in /etc/fstab for detected removable devices.
The next time you boot Linux, or the next time you restart the HAL daemon, you should see the sync directive in the mount options for the devices you chose to add it to in your /etc/fstab.
22.214.171.124. Disabling HAL on Red Hat/Fedora
After you tinker with HAL, it may not work as desired on your particular configuration. If you're running Red Hat/Fedora, you can disable HAL's effect on /etc/fstab by running the following commands. You can then edit /etc/fstab to meet your needs:
rm /etc/hal/device.d/50-fstab-sync.hal ln -s /bin/false /etc/hal/device.d/50-fstab-sync.hal
If you want to restore HAL's effect on /etc/fstab, just run the following commands:
rm /etc/hal/device.d/50-fstab-sync.hal ln -s /usr/sbin/fstab-sync /etc/hal/device.d/50-fstab-sync.hal
2.3.3. Other Hotplug Update Methods
SUSE and Debian Linux take different approaches with HAL, as they do not update /etc/fstab when HAL detects newly connected hardware.
On my SUSE system, I did not have to change the hotplug defaults for my external FireWire hard drive. These defaults are stored in the hotplug.subfs.functions file, in the /etc/hotplug directory, and this file is already configured to mount detected hotplugged drives with the sync directive.
SUSE automatically mounts removable hard drive partitions once they're connected to and detected by your system. However, unlike with Red Hat/Fedora, it does not update the /etc/fstab configuration file.
Debian Sarge does not configure HAL to automatically mount newly attached drives. In this case, you'll need to mount those drives yourself. For example, after I plug a USB key drive into my Debian system, I make it recognizable to the system with the following command:
mount -o sync /dev/sda1 /mnt/usbkey
You can also verify through mount that the sync directive is in effect. When I run the mount command by itself, I find the following entry for my USB key drive:
/dev/sda1 on /mnt/usbkey type ext3 (rw,sync)
When you run the mount command on any of your Linux systems, you should be able to confirm that the sync directive is in effect for any mounted removable media.
2.3.4. Configuring the Automounter for Removable Media
The Automounter supports temporary mounts of removable media, by issuing the proper mount commands when the devices start up and unmounting the devices if they are idle for a while. For detailed information on configuring the Automounter, see Chapter 7. Briefly, all you need to do is configure any mount points in your automounter configuration files, /etc/auto.master and /etc/auto.misc, and include the sync directive in the associated options. The automounter package also includes the /misc directory for mounts defined in /etc/auto.misc. For example, the following directive in my Red Hat Enterprise Linux 4 /etc/auto.misc configuration file supports synchronous read/write access:
floppy -fstype=auto,rw,sync :/dev/fd0
I've added the rw and sync directives to the floppy command line; after I restart the automounter daemon and run the ls /misc/floppy command, I see the following output from the mount command:
/dev/fd0 on /misc/floppy type vfat (rw,sync)
If you've enabled rw (read/write) access but see ro (read-only) mounting, your media may not support read/write access. Check your media. The tab on the floppy may be disabled, or the DVD drive may not support write access.