[En-Nut-Discussion] Improvement for faster mounting of

[Ulrich Prinz]

Hi! 
 
On Thu, 21 Jan 2010 13:36:11 -0200, Thiago A. Corrêa 
<thiago.correa at gmail.com> wrote: 
> Hi, 
>  
> On Thu, Jan 21, 2010 at 5:55 AM, Rob van Lieshout (PragmaLab) 
> <info at pragmalab.nl> wrote: 
>> Good proposal. This way we provide a flexible way to determine the 
moment 
>> to 
>> count the clusters, while still honoring the module and driver 
structure. 
>> Counting in a background task can be implemented using this ioctl() 
>> function 
>> if you would like the idea of a background task. I suppose your 
>> application 
>> will be leading in whether you counting in the background will help you 
>> or 
>> not, it's not a general rule. If the application starts writing right 
>> after 
>> mounting, a background task will not speed up things. If writing starts 
>> hours after mounting (like in our case), the counting is done when you 
>> need 
>> the result. 
>> 
>  
> What if this decision was made during build time? Then there is no 
> added code size for applications that use the card in read-only. 
> Also, if there is a background task, it could read-ahead, and maintain 
> a small list of known to be free clusters, and take a hint from 
> FSI_Nxt_Free when vol->vol_last_clust isn't initialized. 
 
Good idea! 
 
First give an option if the application is read-only at all. This could 
exclude any code not needed and exclude free cluster counting on mount at 
all. 
 
Second, if read-only is deselected, in most application it is enough to 
check-ahead if there is enough free space for n Bytes to be written now. So 
a write application just needs to know if there are n/cluster_size clusters 
are available. These clusters can be used for writing. The next write then 
will request m clusters, and collection for that count of clusters is just 
continued from the first scan. In normal live it is important to know that 
the actual data can be saved not if there might be space left for future. 
Or, if a data-logger should warn early befor all memory is eaten up, if can 
do a scan for n+safty_count of space. 
So the mount process would be the same like in read-only, the write process 
will take some µs more to scan for some clusters ahead instad of counting 
them all. 
 
Safety scan ahead may be established via  
 
int space_needed = 1345; 
ioctl( SCAN_FOR_FREE, &space_needed) 
 
(ioctl should round up to cluster size and divide by cluster size) 
 
Another mechanism could be to have an alert automatically if a min_free 
value is violated. So a write function will return -1 and the detailed 
error will state FS_LOW MEMORY or something like this. 
 
Best regards, Ulrich