Messages in this thread | | | Subject | Re: MM deadlock [was: Re: arca-vm-8...] | Date | Tue, 12 Jan 1999 11:16:42 -0800 | From | Craig Milo Rogers <> |
| |
>>> most writes should take out a read lock on the filesize so that the file >>> won't disappear from under their feet; only extending or truncating the >>> file should take out an i_atomic_allocate write lock (assuming the same > >> why should the writes care if the file is extended? > >Because POSIX.1 specifies that O_APPEND writes are atomic with respect >to each other.
Indeed, O_APPEND writes extend the file, and thus need a higher level of locking. Regular writes interior to the file should be able to continue concurrently with the O_APPEND extend.
>> I would guess that it should be something like: ... >Unnecessary complexity, I think. A single lock on >allocation/deallocation is sufficient for the important case (concurrent >writes inside a shared file by multiple threads/processes) while >maintaining reasonable behaviour for truncate. For processes managing a >shared database file, this is important. I don't think it's all that >important at all for multiple processes extending or truncating a file.
I agree that I may be advocating optimizing for an infrequent case; I prefer to think of it as a clean design. :-) Regarding shared the use of database files, I note that Oracle can dynamically extend a shared database file, so there's a possibility that the extend-while-interior-I/O-is-in-progress scenario might occur (depending upon how Oracle manages their own internal queuing, of course).
Craig Milo Rogers
- 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/
| |