Brendan wrote:A more optimized implementation could try to use free space between files. For example, if the data area looks like:
[tt]
[00]: -----
[05]: 11111
[10]: 111--
[15]: --222
[20]: -----
[25]: -----[/tt]
oh, and btw, it all depends on how those "-" are encoded. say the former fig is actually represented by:
Code: Select all
index[0]={L1_FILE, sblk=5, eblk=16, size=7*BLKSZ+STUFF}
index[1]={L1_FILE, sblk=17,eblk=29, size=2*BLKSZ+STUFF}
then it becomes clear that room beyond file 2 (that is, blocks 20..29) is actually free for something else, since from the size of index[1] (which owns those blocks), they're unused.
To keep things clean, when such a "llama-with-screws" driver will detect room that needs to become "free", it just locates the previous file entry (not necessarily [i-1], thus), and extends the "eblk" value so that it now covers the "free" space (let's say that's how file 1 has "---" after it).
The "camel-with-stick" driver that wants to "shrink" a file just updates the "byte size" of the file, and both camels and llamas are kept happy.
Similarily, the "camel-with-stick" that wants to make the file deleted just tags it as "deleted". both llama or L2 driver will be happy and recover the space of the deleted file if they feel like.