[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: fatfs locking
From: |
Marcus Brinkmann |
Subject: |
Re: fatfs locking |
Date: |
Sat, 28 Feb 2004 22:56:59 +0100 |
User-agent: |
Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI) |
Hi,
I should point out that a similar issue is appearing in another area.
I refer you to this info by Marco for the details:
> Fatfs needs to lock the directory that holds a file in order to write
> the metadata of a file to disk. This happens in the function
> write_node.
>
> The problem is that this directory could have been locked by one of
> the callers of write_node. So locking the directory is not safe
> because the directory could have been locked (and that makes the
> thread hang). Not locking the directory isn't safe either because it
> introduces race conditions.
>
> We can't make a special case here like we did for read_node because
> there are too many callers, all with different behavior.
>
> I propose to modify the interfaces for diskfs_update_node and
> diskfs_write_disknode. By adding a flag to notice these functions if
> the directory is locked, or even better by passing the "dp" to the
> function if it is locked (as Roland once proposed for read_node).
>
> I even like to make similar changes for diskfs_cached_lookup so fatfs
> and other filesystems that have similar problems can support nfs.