bug-hurd
[Top][All Lists]
Advanced

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

Re: hurd/tmpfs dir.c tmpfs.c


From: Marco Gerards
Subject: Re: hurd/tmpfs dir.c tmpfs.c
Date: Tue, 4 Jun 2002 22:12:37 +0200

> This was the change that came up on the thread "fatfs locking".  It might
> still be desireable for fatfs, but I don't know enough about that case to
> really be sure.

There is no fix for the fatfs locking problem yet. This patch can fix the 
problem :). 

I thought about an other solution for the problem, although it is a stange 
solution it might solve the problem. The thread in fatfs will deadlock 
because that thread already locked the node, what if the function that locks 
the node check if the node is locked by that thread and won't lock if it is? 
That will solve the problem and won't cause troubles for other diskfs 
translators.

I was thinking about the functions "diskfs_lock_node" and 
"diskfs_unlock_node". If everybody agrees I'm willing to write those and 
adept libdiskfs and the translators using libdiskfs to use those functions.

Another solution is not locking the directory but locking the directory 
entries instead. Personally I don't like this solution because it doesn't use 
libdiskfs' locking mechanisms. I haven't tried this solution yet, it can be 
hard to implement and it make fatfs slow (a lot over overhead, locking every 
entry makes diskfs_get_directs slow I think). I'm not 100% sure if this is 
possible.

Reading in fatfs already works, writing is almost working. This is one of the 
last problems that needs to be solved :)

Thanks,

Marco Gerards





reply via email to

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