[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New task list items on savannah

From: Marco Gerards
Subject: Re: New task list items on savannah
Date: 01 Aug 2003 21:01:46 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2


Here are the revised tasks. Now I've split them up and added more
information. Can someone please read it to see if it makes sense,
especially the locking stuff? (I know how it works, so I easily think
it is clear).

The new tasks for fatfs:

(Partially) ignore some unsupported calls

Fatfs can't store the entire stat structure on disk, some fields are
not supported at all and some only partially.

The following functions should be overwritten:

* file_chown, file_chgrp, file_chauthor: Setting the owner of a file
  is not supported.

* file_chmod: Changing the access permissions is not possible.

* file_chflags: Changing of flags is not supported with the exception
  of UF_IMMUTABLE. A part of the task is finding out if it is sane to
  use UF_IMMUTABLE, if not use file_chmod and the writable permission
  bits instead.

- Reimplement dir_rename_dir, the libdiskfs version relies on


Make it possible to rename directories

Fatfs doesn't support renaming directories. The implementation in
libdiskfs, dir_rename_dir, relies on hard links.  So this function
needs to be overridden and replaced with fatfs specific
implementation. Possibly huge parts of the libdiskfs version can be
used in order to get the right serialization and locking behavior.


Fix the locking problems in write_node

There are two locking problems in write_node. Both make fatfs hang
while writing(deadlock). The first is when diskfs_cached_lookup is
called, diskfs_cached_lookup locks diskfs_node_refcnt_lock.

One example is diskfs_drop_node, it calls diskfs_node_update when the
link count is set to 0 (during this call diskfs_node_refcnt is
locked). After this write_node is call via diskfs_node_update, this
makes fatfs deadlock. Please notice diskfs_node_refcnt isn't always
locked while write_node is called, see for example diskfs_S_io_read.

The other locking problem in fatfs is also caused by the call to
diskfs_cached_lookup. diskfs_cached_lookup is used to lookup the
parent directory of the file that is currently written to. After
looking up the directory diskfs_cached_lookup locks this directory. It
is possible that the directory was already locked by the caller of
node_write (or by the caller of the caller, etc.).

The easiest way to fix both problems is replace the call to
diskfs_cached_lookup. Possibly this can be done by adding a one
reference to the directory for all existing node structures and store
a pointer to the directory in the node of the file. By doing this it
is not required to lookup the directory because it is always
known. When doing this don't use diskfs_nput like it is done now (it
locks diskfs_node_refcnt), just lock the node instead.

It is better to solve this problem using another solution if
possible. Just avoid to calling any function that can lock the
directory node or diskfs_node_refcnt. The best way to solve this
problem is by changing the locking order without introducing race


Fix the directory fragmentation

When removing files the directory gets fragmentated. A block should be
removed when it is only filled with "free" entries. If the block
contains a few "free" entries move directory entries to save some

Think about the consequences for long file names and undeleting
(although undeleting is very low priority it would be a nice thing if
it can be supported).


Store if the filesystem is or isn't clean 

Check if a FAT32 partition was cleanly unmounted. fatfs should also
set this information. This behavior should be identical to the ext2fs


Make fatfs handle filenames correctly

The filenames are presented as they are on disk when reading. It is
better to convert them to uppercase/lowercase names (Make an option so
the user can configure this). Always write files in uppercase.

fatfs should use and update the FSInfo sector when it is available

For FAT32 a FSInfo sector can be stored, this is a sector with
additional information about the filesystem including the free space
and the next free sector.

It is not safe to assume this information is correct, it is possible
to destroy the filesystem when using the next free sector without
checking if it is really free.

Fatfs should use the free space information in this sector, but there
must be possible for the user to configure fatfs to ignore this field
and find out this information itself like it is done for FAT12 and
FAT16. NEVER consider this information reliable. Always look for free
space by scanning the FAT, don't report the disk is full because the
FSInfo sector claims it is.  When possible (it is when the whole fat
was read) update this information so it is correct.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]