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/