Messages in this thread | | | Date | Thu, 05 Aug 1999 09:25:03 +0200 | From | Manfred Spraul <> | Subject | Re: i_size still not SMP safe. |
| |
Alexander Viro wrote: > On Thu, 5 Aug 1999, Manfred Spraul wrote: > > And you should also check the thread "2.3 SMP overlapping writes and > > NFS". > > Basically, NFS v2-writes should be atomic. Even multi-page writes. > > It sucks. Forget about NFS-exporting FAT, then. Unfortunately, ext2 has the same problem, so this cannot be ignored. (or "Forget about NFS-exporting Linux, then.")
> > * it's not that complicated: e.g. a truncate is identical to a write: > > it needs exclusive access for the byte range (new EOF, current EOF). > > You *do* know how badly POSIX locks implementation sucks, right? Relying > on it will kill any performance. > > > You don't need any new sync objects: only a normal spinlock for > > additions > > and removals from the collision list, and a wait queue for blocked > > threads. > > The collision list is similar to an extended semaphore: the "dec > > sem->count" > > is replaced with a check of all pending operations, so it's a very > > flexible and "fine grained" lock. > > Too fine grained. You are adding the unneeded overhead.
I never thought about abusing POSIX locks for this. I thought about an independant, lightweigth collision list. The lock structure could lie on the stack, I think it could be quite efficient. But the main problem is the overhead, but OTHO acquiring i_sem for write operations would kill performance for large databases.
-- Manfred
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |