> 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. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
- Re: I/O clustering, Re: patches for test / review Matthew Dillon
- 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