: :> 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