I thought about that, it could become ugly: e.g., sys_llseek() and
truncate would have to lock a page in the page-cache.
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.
I think a list of all collisions will be the best option:
* parallel writes and reads to different areas of the file will
be possible.
* parallel readdir()-calls should be possible, but I did not check this.
* 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 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.
> > Btw, I think that the lock_kernel()-call in sys_lseek() is superflous:
> > sys_lseek accesses the same fields as sys_write(), but sys_write()
> > does not acquire the big kernel lock.
>
> Atavism again.
only partially: if f_op->llseek is NULL, then the lock_kernel() call is
superflous. Otherwise, it's needed because the actual filesystem could
rely on it.
-- 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/