Re: [MiNT] file system check

[Evan Langlois <evan@coolrunningconcepts.com>]

On Fri, 2005-09-30 at 00:17 +0200, Ingo Schmidt wrote:
> Hi all!
> 
> 
> I have a question on fsck.ext2:
> 
> How does it know if the filesystem is clean or not?

It's stored in the filesystem.  Basically, when its mounted, its set
dirty.  When you do a clean unmount, its set clean.  That's all there is
to it!

When fsck runs it looks at the flag.  If it says dirty, then you haven't
unmounted yet.  Anyone ported ext3 (or reiserfs) yet?  I hate fsck,
especially on large drives.  Journaling is WONDERFUL - hit the power
button, and you don't fry your filesystem and don't have to wait on
fsck!  You lose whatever data wasn't flushed to disk (what sync does),
but thats usually not that big of a deal compared to the massive
corruption you can get from skipping your fsck passes.  For atari users
that aren't used to orchestrated shutdown procedures, a journaled
filesystem would be much more "in-tune" with the system.

> I guess htere is some kind of "clean flag". Who sets this flag to
> "clean" and when does this flag get set?

Filesystem driver sets it when you unmount it.

> What happens at a "sync"? Is the filesystem marked as "clean" after a
> sync or not?

Sync just flushes all unsaved buffers to disk.

Everything is flushed to disk that is pending, but you can still have
open files and such.  Unix is multitasking, so while it may technically
be clean the moment you do a sync, there is no guarantee that some
process hasn't written a byte to some buffer a nanosecond after the sync
call.  It wouldn't make much sense to update the dirty flag every time
buffers are flushed - you'd just thrash your heads around on the disk
with no real benefit.  Therefore, it isn't clean until its unmounted as
that is the only time you can be guaranteed that there are no process
will suddenly open one a millisecond later.

Also, you can delete a file while its still open, and any process that
has a filehandle to it can read/write data.  This is stored to disk, but
the directory entry and filename are already gone.  The storage won't be
reclaimed until every process closes the file.  If you sync it, the
buffers are flushed to disk, but the space isn't reclaimed since the
file is open.  If you reboot without unmounting it, fsck will have to
find that data and reclaim the storage space.

> Or is it only marked as clean upon a shutdown?

Yes, but only because umount is called during shutdown.  Shutdown just
tells init to start the procedure, and the scripts take care of shutting
down the services, syncing the disks, and then calling umount.

I believe that a filesystem can be marked clean if you remount it read-
only, but I'm not 100% sure on that one.  Many shutdown scripts will
retry a few times to umount all the drives hoping that whatever process
stopped it from succeeding has died.  When all else fails, it just tries
to remount whatever it can't unmount as read-only and then
halts/reboots.  Any open handles trying to write to it from that point
get an error message, but at least the system is in a "known state".
For all filesystems it can't umount, it basically does :

mount -o remount,ro /filesystem
mount -o remount,ro /another/filesystem
mount -o remount,ro /

Now you know why removable media like CDs, floppies, and USB drives have
traditionally been somewhat of a pain under Unix systems.

-- Evan