[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