Re: fatfs: slot_status COMPRESS

[Marcus Brinkmann]

At Wed, 13 Jun 2007 10:31:33 +0200,
"christian nastasi" <nastasichr@gmail.com> wrote:
> 
> [1  <multipart/alternative (7bit)>]
> [1.1  <text/plain; ISO-8859-1 (7bit)>]
> Hi all,
> I'm working on the vfatfs translator and I'm trying to understand how it
> should be merged with the fatfs one.
> First of all I'm looking at the dir entries searching (diskfs_lookup_hard).
> Some questions.
> 1- What does mean the slot status COMPRESS in the dir.c? It seems that
> should be used to choose to look for the LFN entry slots.

In dir.c, line 47 on:
  /* This means that there is enough space in the block, but not in
     any one single entry, so they all have to be shifted to make
     room.  */
  COMPRESS,

Ie, the directory block has enough free space due to deleted entries
that it can be used, but the space is fragmented, ergo the used space
needs to be compressed.  For example, say you need two directory
entries for a long file name, and all entries in the block are used,
except for two.  Then we know the long file name will fit, but there
are two possibilities: The free entries are next to each other, then
we can use them directly, or they are separated, then one of the
entries needs to be moved.

Actually, the logic you see in the code comes from the ext2fs file
system, and it may be more complex than necessary.  IIRC, all dirents
in FAT are of the same size.  The ext2fs code can not make that
assumption.  So, there you have to move all entries inbetween to
defragment.  In FAT, one only needs to move as many entries as the
space that needs to be freed.  However, scanning for the free entries
will still take time linear in the number of entries that are
inbetreen.  However, that work has already been done in dirscanblock,
so one could store its result for later.

When reading the code, imagine that dirents could have different size,
to understand how and why it is written (also compare ext2fs/dir.c).
In particular you will want to look at ext2fs' diskfs_direnter_hard,
where you can see the defragmentation step.  This is what could, in
principle, be optimized further in fatfs, but I would suggest that you
just copy that code for now and leave it at that for simplicity.

> 2- The multiplexing between fat and vfat could be done in the
> dirscanblock(), doesn't it?

That's what I suggested before.

> Here I want to know what the fatfs authors
> intend to do with the COMPRESS status (is it for vfat LFN?).

See above, and yes, it is for LFN support.

> I suppose the fatnamematch() will be also multiplexed with a vfatnamematch
> or whatever you want to call it.

I wouldn't take this literally, but yes.  Maybe have two functions,
collectfilename and matchfilename.

Thanks,
Marcus