267654 |
20-Jun-2014 |
gjb |
Copy stable/9 to releng/9.3 as part of the 9.3-RELEASE cycle.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation
|
225736 |
23-Sep-2011 |
kensmith |
Copy head to stable/9 as part of 9.0-RELEASE release cycle.
Approved by: re (implicit)
|
218938 |
22-Feb-2011 |
miwi |
- Fix QA issues
PR: misc/146687 Submitted by: Garrett Cooper <gcooper@FreeBSD.org> Approved by: rwatson (mentor)
|
156735 |
15-Mar-2006 |
ru |
Style: NO_MAN doesn't need any value.
|
154668 |
22-Jan-2006 |
davidxu |
s/sigval/sival/g
|
151261 |
12-Oct-2005 |
ambrisko |
This test can run now.
|
142976 |
02-Mar-2005 |
ambrisko |
This will not compile without: http://www.ambrisko.com/doug/listio_kqueue/listio_kqueue.patch
Note: it is a good idea to run this against a physical drive to exercise the physio fast path (ie. lio_kqueue /dev/<something safe>) This will ensure op's counting per LIO request is correct. It is currently broken the above patch fixes it.
Sponsored by: IronPort
|
142971 |
02-Mar-2005 |
ambrisko |
Add an AIO & kqueue regression test. It is a good idea to run this against a disk as the argument. If you don't it will use a temp file. The raw disk will use the kernel physio fast path method until the max number of pending op's is reached then it will queue them. File system op's are always queued. This is more important with LIO since operation can get split across and accounting of op's is broken with LIO.
Note that this was broken when locking was added to kqueue (ie. 5.3) My fix needs to be better integrated with FreeBSD.
Next is an LIO test and implementation.
Sponsored by: IronPort
|