Re: [PATCH 4/6] sim: read EFiidf

[Denis Kenzior <denkenz@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1679 bytes --]

Hi Kristen,

>> My initial feeling is that we should treat blocks just like we treat
>> records today. We should not write them to separate files.
>>
>> Can we unify the two approaches somehow?  Perhaps by storing a bitmap in
>> the cache header, and update the bitmap every time we write the record /
>> block to the cache.  We can use idmap.c for bitmap management easily
>> enough...
> 
> The complication is that you can read blocks out of order.  For example,
> say you want to retrieve an image that is contained in blocks 4 and 5
> of the EFiidf.  But you don´t care about blocks 1,2,3 and we don´t

That is not really a complication, you handle this already...

> read them.  So to cache blocks 4 and 5 when blocks 1, 2, 3 don´t exist
> in the same file would mean either writing blocks 4 and 5 before blocks
> 1,2,3 and then keeping a map of where each block would be located in
> the file (which would require more space than a bit), or leaving a lot
> of blank space for blocks 1, 2, 3 and putting blocks 4 and 5 into the file
> after the blank space, which seems wasteful to me since we may never
> need to read 1, 2, 3.

I'm actually not worried about wasting space.  These files are max 65k,
most likely less and there's a few of them.  Devices these days come
with 16G+ of flash...  Also, it is not like directories are 'free'.
Most file systems allocate at least several KB for that...  Given how
tiny these files are, we'd probably come out ahead more often than not.

And if we ever support EFext for EFfdn, EFbdn, EFadn, etc we'll need
selective record caching as well.  This leads to 'wasted space' too.

Regards,
-Denis