:
:> effects of the I/O being in-progress. If a user program doesn't access
:> any of the information it recently wrote the whole mechanism winds up
:> operating asynchronously in the background. If a user program does,
:> then the write behind mechanism breaks down and you get a stall.
:
:What makes no sense is that it should be perfectly ok to _read_ this
:information back.
When we separate out the read vs write access in the buffer
cache API we *will* be able to read the information back while a
write is in progress. At the moment the buffer cache has no clue
how a buffer is going to be used, which means the buffer is locked
exclusively.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
- Re: patches for test / review Dan Nelson
- Re: patches for test / review Greg Lehey
- Re: patches for test / review Dan Nelson
- Write clustering (was: patches for test / review) Greg Lehey
- Re: patches for test / review Paul Richards
- FreeBSD random I/O performance issues Richard Wendland
- Re: FreeBSD random I/O performance issues Matthew Dillon
- Re: FreeBSD random I/O performance issues Paul Richards
- Re: FreeBSD random I/O performance issues Matthew Dillon
- Re: FreeBSD random I/O performance issues Mike Smith
- Re: FreeBSD random I/O performance issues Matthew Dillon
- Re: FreeBSD random I/O performance issues Julian Elischer
- Re: FreeBSD random I/O performance issues Richard Wendland
- Re: FreeBSD random I/O performance issues Richard Wendland
- Re: FreeBSD random I/O performance issues Matthew Dillon
- Re: FreeBSD random I/O performance issues Sheldon Hearn
- Re: FreeBSD random I/O performance issues Matthew Dillon
- Re: FreeBSD random I/O performance issues Chris Wasser
- Re: patches for test / review Poul-Henning Kamp
- Re: patches for test / review Greg Lehey
- Re: patches for test / review Poul-Henning Kamp
