lkml.org 
[lkml]   [1999]   [Aug]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:53    [W:0.073 / U:0.308 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site