FAT32 marked as dirty flag - dosfsck

Onno Benschop onno at itmaze.com.au
Tue Jan 2 11:34:11 GMT 2007


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

A number of current bugs[1] exist related to dosfsck within Ubuntu.
Stefan Potyra[2] and I[3] have been working through issues that are
causing file corruption and deadlocks on some FAT32 partitions with
some files.

    1.
https://bugs.launchpad.net/distros/ubuntu/+bugs?field.tag=dosfstools
    2. https://launchpad.net/people/sistpoty
    3. https://launchpad.net/people/onno-itmaze

There are suggestions[4] to stop checking FAT32 volumes altogether and
suggestions[5] to prompt for changes. The first suggestion does not
make much sense to me, the latter appears to be a valid concern.

    4. https://launchpad.net/bugs/48806
    5. https://launchpad.net/bugs/55121

In addition to those bugs and concerns, I have a question to ask about
how dosfsck interacts with its environment. Under DOS/Windows, there
is historically a check[6] to determine if the file system needs to
have scandisk run, in my limited understanding, similar to the mounted
dirty flag on an ext2/3 file system.

    6. http://www.geocities.com/thestarman3/DOS/DirtyShutdownFlag.html

Regardless of other considerations, such as checking every x mounts or
y days, prompting for file system changes, existing bugs in dosfsck
and configuration of any options, does anyone have any comment to make
about a dirty flag implementation for FAT32 under Linux?

Things I have little or no awareness of include questions that Stefan
put to me:

    If the file system can only be corrupted, if the dirty flag is
    set, then it makes sense. Does linux set this flag? Also: can
    other circumstances (e.g. bug in the driver, power failure) lead
    to a corrupted file system w.o. having this flag set? If these
    exists, it isn't all a black and white decision any longer: there
    might be legitimate reasons to have the file system checked. OTOH,
    if such occasions, where the dirty flag is not set, but the file
    system is indeed corrupted, are only very rare, it might also make
    sense to have such a check.

What I'm hoping to receive from this email is responses about some of
the existing mechanisms that deal with this.

My understanding of how this would normally be implemented is that if
a file system is mounted rw, then the dirty flag is set and only if
the file system is cleanly unmounted, is this flag cleared. Of course
it's entirely possible that I'm biting off way more than I can chew,
but I figured I should at least find out.

As Stefan also put to me, I've cc'd upstream on this for their
consideration and comment.

- --
Onno Benschop

Connected via Optus B3 at S31° 55' 22.77" - E115° 50' 5.13" (Mt
Hawthorn, WA)...
- --
()/)/)()        ..ASCII for Onno..
|>>?            ..EBCDIC for Onno..
- --- -. -. ---   ..Morse for Onno..

Proudly supported by Skipper Trucks, Highway1, Concept AV, Sony
Central, Dalcon
ITmaze   -   ABN: 56 178 057 063   -  ph: 04 1219 8888   -  
onno at itmaze.com.au
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFmkMz7KM5a8raIGERAuCTAJ9V30DeQmdpyLkGyVmgGMDuLJvJsQCfQkvM
6rzEzockAabLuAPOSx4pE0o=
=Y3Q7
-----END PGP SIGNATURE-----




More information about the ubuntu-devel mailing list