>That's it. write() does lock the page before writing to it/allocating new
>blocks/etc. _That_ protection should be enough to avoid several callers of
>write() messing with each other.
Except the fact that two writers writing 100byte each one will produce a
100byte long file and not a 200byte long file as the user expected. And
btw NFS needs to be atomic at the write() level, line 415 of rfc1094:
file after the write has completed. The write operation is atomic.
Data from this "WRITE" will not be mixed with data from another
client's "WRITE".
What I would like is to have a three level semaphore with three kind of
locks:
1) read
2) write-serialized (allow-readers)
3) truncate
Lots of readers can enter at the same time of write-serialized. But only
one write-serialized event can enter the critical section at once.
And the `truncate' locking instead enters only if nobody else is grabbing
locks and forbids everybody else to enter.
I think it's safe as write(2) only enlarges the i_size so any reader won't
risk to read beyond the end of the inode.
During truncate() instead everybody will block and so there won't be any
race.
With this design all reads can be parallel to writes. But only one
write(2) can happen at once so there won't be any i_size race and NFS will
be happy too.
I really don't think it make sense to let write(2) to be SMP parallel as
it would be unreliable and thus useless. So basically allowing more writes
to enter the critical section looks an useless improvement and lose of
robustness to me.
Andrea
-
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/