Messages in this thread | | | Date | Fri, 8 Oct 1999 19:49:27 +0200 (CEST) | From | Andrea Arcangeli <> | Subject | Re: how to write get_block? |
| |
On Fri, 8 Oct 1999, Alexander Viro wrote:
>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/
| |