[PATCH 2/2] dosfs: Lazy update of FAT32 FS info sector

[Claus, Ric]

On Nov 8, 2012, at 3:27 PM, Chris Johns wrote:

> Claus, Ric wrote:
>> On Nov 8, 2012, at 1:11 PM, Sebastian Huber wrote:
>> 
>>> On 08/11/12 19:34, Claus, Ric wrote:
>>>> Unlike as for Linux and Windows, there is no shutdown procedure for RTEMS.
>>> What about unmount()?
>> Who calls unmount()?
> 
> If you have removable media such as a USB stick or a Compact Flash card 
> you need to call it before the device is removed. There are RTEMS system 
> that do this. Other systems mount then unmount the file system rather 
> than leave it mounted.

In our system's case, it is a removable SD card, but it is in practice never removed.  We boot RTEMS and our application from it.  During the startup procedure I mount the device so that if users want to replace the application or store other data on it, they can just place the files on the SD, either through code or from the shell.  They then restart, often by "pushing the reset button" or power cycling, to get the new system.

So what you're saying here sounds like it is not a good idea to keep the disk permanently mounted and that we need to instill the discipline in our users to mount() and unmount() around their interactions with it.  I hadn't been thinking along these lines, so it's great that you pointed that out.  Thanks!

> 
>>>> Consequently, the unmount is in most cases never called.  Given that, what is the effect of this patch on FAT formatted persistent storage devices that have been modified during a boot cycle?
> 
> In relation to the boot cycle question I am sorry but I do not 
> understand it. Do you mean something in a boot monitor updates the disk 
> or is something in RTEMS's boot cycle updating the disk ?

No, I meant users updating the disk once RTEMS is up and running (usually via the shell), or the application that runs under RTEMS updating it. 

> 
> The relation to this patch the fatgen103 document I have handy on page 
> 23 states for FSI_Free_Count:
> 
>   "Contains the last known free cluster count on the volume. If
>    the value is 0xFFFFFFFF, then the free count is unknown and
>    must be computed. Any other value can be used, but is not
>    necessarily correct. It should be range checked at least to
>    make sure it is <= volume cluster count."
> 
> This means we set the value to 0xFFFFFFFF which is what the patch does 
> (well cleans up) and we set to the last known count when we unmount if 
> unmount is called. If it is not called the value is 0xFFFFFFFF, and if 
> unmount is called it is set. If the disk is mounted again and the file 
> system updated and unmount is not called the "but is not necessarily 
> correct." part comes into play. Therefore as Sebastian states it is a hint.
> 
> The usefulness of this value is questionable because it only provides 
> the last count of free clusters. The cluster table itself is the only 
> true record of the state and should be read and these value calculated 
> when mounting. The next FS info value in the table is FSI_Nxt_Free. The 
> cluster table can have holes therefore you need to search the table for 
> those holes. FAT-FS performance drops off when it becomes full because 
> of this and why compaction was widely adopted.
> 
> I have not reread the whole document so I do not know if other areas of 
> the spec relate or effect the quoted section.

My boot loader doesn't look at the FSI, but it would be unfortunate if due to the above usage pattern the performance of the disk degraded over time because RTEMS never got a chance to clean it up.  It would also be unfortunate if these lazy updates happened at uncontrolled times or were starved from happening due to application activity.  I like your idea of an option that allows the application developer to choose when to pay the cost of the clean-up.

	Ric

> 
> Chris