:I just spent a bit of time talking to the Linux Alan Cox and I
:was suprised to find out that it seems that Linux doesn't
:garantee read/write atomicity.
:
:It sounded somewhat strange however, it dawned on me that one should
:be using advisory locks instead of depending on that feature.
:
:Removing those locks would simplify a lot of the locking code,
:and probably aid in performance quite a bit. I know Matt Dillon
:wanted to implement byterange I/O locks to handle this, but it
:seems unnessesary in terms of complexity and performance gains.
:
:I know some people will be eager to just spout "Linux is broken"
:but what i'm really looking for is a situation where this would
:cause problems.
:
:Can anyone comment on this or reference a thread that has
:gone over this issue?
:
:thanks,
:-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
I would love to see the guarentee go away, at least for anything
not O_APPEND. O_APPEND writes would probably still have to
be exclusively locked.
Such a change would clean up many of the deadlock problems with the
current code and would also drastically improve parallel I/O performance
on the same file (because I/O requests whos data is cached in memory
would not have to block waiting for an I/O request whos data must be
obtained from the disk).
BUT! And this is a big but... I/O atomicy has been 'standard' in
UNIX for a very long time. If we were to make such a change, we
would no longer be in conformance with the UNIX spec. This is why
it hasn't been done and why it probably will not be done in the near
future. Simply put, Linux is doing it wrong.
On the otherhand, way back then mmap() was not used to the degree that
it is used today, and with mmap() you already lose I/O atomicy (you lose
it even between mmap() and discrete I/O, not just mmap-to-mmap).
It would be great if someone could ram such a change through the standards
committees. Alternatively Linux could become enough of a defacto standard
that we could ignore the standards committee. Barring that, the only
solution available to us to increase performance is to implement temporary
byte-ranged locks within the kernel to allow the I/O to be parallelized.
It isn't necessarily as bad as you think... support for such locks
already exists in order to deal with POSIX locks, but it would certainly
be easier if we didn't have to mess with it at all.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
