Ubuntu Wiki

Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.

• Created: 20 March, 2007

• Author: [:OnnoBenschop: Onno Benschop]

• Launchpad entry: [https://blueprints.launchpad.net/ubuntu/+spec/dos-dirty-flag dos-dirty-flag]

• Packages affected: dosfstools

Summary

Make dosfstools aware of the status of a (v)FAT file system, stopping it from checking a known clean partition.

Rationale

As more and more users have access to USB sticks, external drives, digital cameras and larger drives that co-exist with other operating systems, dosfstools needs to participate in the existing file system integrity procedures, rather than just fix every (v)FAT partition it encounters.

Use cases

• Peter has a large drive with many partitions. When he boots Ubuntu, the process takes forever because his Ubuntu checks his Windows Recovery Partition each time Ubuntu boots (even though Windows itself doesn't.)
• Paul has an external USB thumb drive. When he inserts the key then boots Ubuntu, the drive content is changed because the mount process checks the drive regardless of its state.
• Mary has a digital camera. When she connects the camera, her computer attempts to check the file system at startup because the camera shows itself to the computer as an external flash drive.

Scope

This specification purposefully only addresses changes made to dosfstools, not to the kernel.

Design

• The dirty flag is documented here: http://www.geocities.com/thestarman3/DOS/DirtyShutdownFlag.html

Implementation

• The implementation initially should check only those file systems that are marked dirty, skipping a clean file system.
• A command line parameter should be added to force a check on a clean file system. Perhaps -c for "check clean", rather than -F for "force check", since -f is used for "salvage to files"

Code

Data preservation and migration

The dirty flag does not currently get used. Some suggestions have been made to create a configuration file on the file system being checked, or in the appropriate location in the system tree. This would create more problems than it solves. There should be no additional configuration files at all. The existing system as used by other operating systems, for example Windows, should be used to maintain integrity.

Unresolved issues

• The kernel provides the actual access to the file system. It should maintain the dirty flag when changes to the file system are made. This specification says nothing about the kernel.
• * So maybe we should edit this spec to have it recommend the changes we would need made to the kernel?
• If a file system is dirty, it is checked. After the check, the file system is clean. How do we update the partition to note this, given that the kernel doesn't appear to support a dirty flag?
• If we resolve the dirty flag write, we will likely have a solution for the kernel to maintain the dirty flag as well.
• Auto mounted file systems should be checked if they are dirty. That is, those devices that are connected after boot and detected by various sub-systems and consequently mounted.

BoF agenda and discussion

CategorySpec