On Tue, Jun 15, 2010 at 01:53:51PM -0400, carl [ at ] heyendal [ dot ] ca wrote:
> My understanding is that Linux sets flags on the SD card's
> filesystem when accessed (or mounted?).
Mounted. But this only applies to some filesystems, such as
ext2 and ext3.
When you mount an ext2 or ext3 filesystem read-write, it marks it as
"dirty", such that any attempt to subsequently mount it will result
in a forced fsck (ext2) or journal recovery (ext3). When you unmount
it cleanly, it's marked as "clean", such that it can be remounted
without issue.
However, FAT has no such check -- or at least, none that Linux
notices, from my testing.
> Once the script that's accessing the SD card completes, Linux
> changes these flags back to indicate a good filesystem state.
Only if the script unmounts the SD card as it completes. I don't know
of any Linux filesystem that marks a filesystem as dirty/clean based on
access, only at mount and unmount time.
> But if the watchdog fires within the script and the SD card is re-
> accessed after it reboots, the SD card filesystem is improperly
> marked and Linux will set the SD card file system to 'read only',
> thereby rendering the CM incapable of being written to, which is a
> problem in our application.
This part is incorrect. For ext2, you'll get a warning if you try to
mount a dirty filesystem, but it'll go ahead and do it anyway. Ext3
doesn't even seem to give a warning, presumably because it can self-
repair based on the journal.
I only know two situations where a filesystem will be mounted read-only
when asked to mount read-write:
1. If the media itself is read-only, e.g. a CD-ROM.
2. Certain versions of the NTFSv3 driver would behave as you
describe, presumably because they lacked the ability to correct
the drive at startup. But that won't apply to FAT.
> The SD filesystem is FAT. Here's what Linux says when re-accessing
> the file on the SD card after a watchdog timeout:
>
> FAT: Filesystem error (dev mmcblk0p1)
> fat_free_clusters: deleting FAT entry beyond EOF
> File system has been set read-only
This is a standard behaviour when a filesystem error is encountered --
in this case, presumably an invalid attempt to delete a FAT entry.
Such errors probably indicate you've hard-rebooted (probably due to
the watchdog) while something is writing to the device, leaving the
filesystem in an inconsistent state. When something else tries to
work with it, it finds the damage, and the device is remounted read-
only to prevent further damage.
So it's not because the filesystem is marked as dirty (and I don't
think FAT even has such a concept), but rather, because there's a
genuine error with the filesystem.
You'll want to run 'fsck' on the filesystem to repair any errors. In
the long term, you're going to want one of two things:
1. Keep the filesystem mounted read-only.
With nothing writing to the filesystem, it can't become corrupted.
If you're just using the card to get a URL or run a script, you
don't need write access. Put the downloaded file in a temporary
location, like a mounted 'tmpfs', which is just an in-memory
filesystem.
2. Unmount the filesystem before the watchdog can kill the system.
Read the URL into memory and/or copy the script to a tmpfs, then
unmount the device. (This option obviously won't work if the device
is your root filesystem.)
Of course, this pretty much implies doing #1 as well, since you can't
really download to the card if you've unmounted it.
One tempting (but misguided) option would be to just fsck the
filesystem every boot. But that can just lead to unpredictable
behaviour, since you don't know what kind of errors might have
occurred, or what the automatic resolution is going to be.
The bottom line is, if you routinely hard-reboot a machine with
filesystems in read-write mode, you're doing it wrong, and you can
expect to start accumulating filesystem errors. Especially if you're
actually writing to them at the time, e.g. downloading files to them.
If you really *have* to support the current behaviour, you may want
to move from FAT to ext3. It's not going to solve all your problems,
but it should be a bit more robust in the face of random reboots than
FAT will be.
> Is my accessment correct or is there another problem here? Note: the
> access described above is a read access only. Later on the downloaded
> executeable may have to write some data to the SD card.
y overall suggestion would be to start with the card mounted read-only,
extract the URL from it, download it, and once you're definitely ready,
go to read-write mode.
> but how can the script detect that the SD card filesystem has been
> set to read only? The command 'stat -f' doesn't provide that kind of
> information from what i can tell.
I would check /proc/mounts. It should have the current status of
the device.
Attachment:
signature.asc
Description: Digital signature