Fix all issues pointed out by @yuripv_yuripv.net
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Oct 3 2018
Oct 2 2018
Sep 26 2018
Sep 10 2018
Sep 6 2018
Looks good.
Thank you!
This change helps me on real hardware I've had this problem.
Thank you!
Jul 23 2018
Jul 18 2018
Jul 4 2018
Jul 3 2018
Jun 18 2018
May 23 2018
Address review notes by a @ae : better new-style printing and more context to diff.
Also, update to r334094
May 22 2018
Update to be applied to r334006 or later.
It is only solution to live-lock problem I encounter on my server when there are massive-parallel fast download.
Apr 28 2018
Apr 26 2018
Update diff to latest CURRENT version
Apr 20 2018
Apr 18 2018
Apr 16 2018
Mar 26 2018
Mar 22 2018
Mar 21 2018
Feb 21 2018
Feb 20 2018
Feb 19 2018
Jan 30 2018
Jan 25 2018
Jan 18 2018
Jan 15 2018
Jan 4 2018
Dec 5 2017
Dec 2 2017
Nov 8 2017
Sep 19 2017
Sep 18 2017
Aug 21 2017
Aug 11 2017
Aug 1 2017
Jul 11 2017
Jul 10 2017
Mar 12 2017
Mar 9 2017
Feb 27 2017
Feb 7 2017
In D9478#195922, @mav wrote:I have no objections if this information is proven.
I'm not sure how to check "TRIM with NCQ" for sure. fio (benchmarks/fio) could run "trim" task with I/O depth 4 with "posixaio" driver in "direct" mode without problems (with 4K-sized 4K-aligned) requests . Is it enough?
750 reports "Samsung", not "SAMSUNG".
In D9478#195912, @mav wrote:Is there reason why for ATA "Samsung" is lower-case, while for SATL it is upper-case? Does some SATL implementation convert strings to upper case?
It's my copy'n'paste error. 750 EVO uses "Samsung" according to boot message.
Feb 2 2017
Feb 1 2017
Jan 31 2017
Jan 7 2017
Dec 1 2016
Nov 30 2016
Nov 21 2016
Nov 18 2016
Oct 6 2016
Sep 6 2016
Aug 17 2016
Aug 14 2016
Fix new opcode placement after megre.
Better merge with named states: previous variant was formally correct, but ugly and against any codestyle.
Aug 13 2016
Remove debug output, as this branch is "ok" now.
Aug 12 2016
Diff against r304005, with all conflicts resolved.
Jun 30 2016
Jun 20 2016
In D1776#144733, @julian wrote:ok so I see the points of both of you.. hmm that doesn't sound very english.. let's try again..
I see the points both of you are making.
let's try address some of them (all mixed up):
1/ backwards compatibility. The capacity to process the opcodes generated by an old ipfw(8) when it sees 'keep-state' need to remain in place, and do the same things. We all agree with that. that compatibility doesn't really need to be in place for more that a major release..