Re: fatfs write support

[Marco Gerards]

tb@becket.net (Thomas Bushnell, BSG) writes:

> 1) Change diskfs to have a special "fatfs" option (perhaps called
>    something like "diskfs_metadata_in_directories" or whatnot).  If
>    the fatfs flag is set, then the directory must always be locked
>    when diskfs_write_disknode is called.  This would require very
>    careful work throughout diskfs.  When the nodes were just looked
>    up, this requires only preserving the locks on the directories
>    longer.  In other cases (say, file_chown), if the fatfs flag is set
>    then diskfs would have to acquire the directory lock before locking
>    the file, and then unlock both after the nput call is complete.
>
>    I believe this is the right strategy.  It does involve more pain,
>    and risks the ire of lots of other people if diskfs gets mangled in
>    the process.  But I do think this is the Right Thing.

Now I think the same, this seems to be the best and cleanest solution.
While I did not look into the libdiskfs details, there are a few
special cases:

-  When diskfs_cached_lookup is called, but it is not clear yet if the
   directory is locked.  Because this is where the node is crated and
   locked, it should know if it will be locked.  I propose to add the
   flag that was discussed earlier to diskfs_cached_lookup.

- Some RPCs can't be supported when "diskfs_metadata_in_directories"
  is used.  Those calls should return EOPNOTSUP (right?).  An example
  of this is "dir_link".

If I forgot any special case, I'd like to hear about it.

> 2) You could rig up a special "directory writing unit" that would live
>    entirely inside fatfs, which would have its own separate interlocks
>    for directory writing.  The idea is that you would just reach
>    inside the directory and rewrite it willy nilly without having
>    locked the directory.  That's safe as long as you interact
>    correctly with direnter, lookup, directory deletion, and everything
>    else.  It might well be *more* pain that (1) above.  I do not think
>    merely adding a reader/writer lock will do the trick.  This is, I
>    think, something like the plan in your first email on the subject,
>    but as I haven't studied it carefully yet, I can't be sure.

When thinking more about it, this is quite complex.  It seems you are
right and this is more pain because of the complexity.  However, if
the first solution does not seem possible for a reason, there is
always another option we might consider.

So I will change libdiskfs like you proposed (solution #1).

Thanks,
Marco