Nice improvements, I learned some interesting details while following these improvements :-)
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Oct 30 2017
Oct 28 2017
LGTM
Oct 24 2017
Oct 2 2017
Sep 28 2017
Few nits
Aug 31 2017
Aug 25 2017
Jun 20 2017
May 18 2017
May 17 2017
Apr 26 2017
Apr 24 2017
Apr 19 2017
LGTM
Apr 14 2017
Apr 11 2017
LGM, much cleaner than it was.
Wow that's a lot of changes.
Apr 10 2017
Apr 8 2017
Convert timestamp to ticks to ensure that comparisons are correct for
hz != 1000.
Apr 7 2017
Lawrence is now happy with this in is current form, so just a prod to see if I get any comments for or against from transport members / gnn?
Apr 3 2017
Mar 31 2017
Extract common logic to tcp_autorcvbuf as suggested by lstewart.
Mar 30 2017
Some style nits but otherwise LGM
Mar 23 2017
Mar 19 2017
Thanks for the feedback Lawrence, based on that I've updated to use just the SRTT check, added the fastpath version and generally cleaned up.
Corrected dtrace autoresize mbuf parameter definition.
Updated dtrace:
dtrace #!/usr/sbin/dtrace -s
Eliminated timestamp specific code path resulting in a simplified yet still effective single SRTT path.
Mar 17 2017
Mar 16 2017
Mar 15 2017
Mar 14 2017
LGTM
Mar 7 2017
Massive amounts of changes in this so impossible to see if everything is good, however a number of style related bits highlighted, some of which are regressions.
Mar 4 2017
Mar 3 2017
book -> bool
Mar 2 2017
Feb 28 2017
In D9829#203014, @jhb wrote:I agree with shortening the line a bit so it fits in 80 cols. If you are worried about duplicating "ARC:" you could perhaps just use a whitespace prefix so you end up with something like:
Mem: 754M Active, 836M Inact, 75M Laundry, 3761M Wired, 10G Free ARC: 2476M Total, 914M MFU, 1302M MRU, 1696K Anon, 140M Header, 118M Other 1899M Compressed, 6065M Uncompressed, 2.45:1 Ratio, 318M Overhead Swap: 3072M Total, 3072M Free
Some may find it useful if it was bit shorter, currently its 82 chars in the example.
Feb 24 2017
Indeed, do you have any bandwidth to do proper testing to prove either way or have you already done this?
Feb 23 2017
LGTM
Feb 22 2017
Feb 21 2017
Just a few seemingly redundant assignments to error vars, sorry didn't spot them before
Feb 20 2017
Disabled reset receive buffer auto scaling when not in bulk receive mode, which gives an extra 20% performance increase, bring it closer to Linux.
Feb 19 2017
For reference fastpath version of this hasn't been done, which need also need the same changes to:
tcp_stacks/fastpath.c
Feb 15 2017
In D9611#198637, @avg wrote:Essentially, L2ARC periodically writes to every block on the device and that allows to physically move the data around.
That's exactly the reason why I think that TRIM is not needed for L2ARC.
TRIM is useful when we don't need data in some area, but we are not going to overwrite that area, so we need to a way to tell the storage system that it can reuse the physical cells without worrying about any data in them. But if we overwrite that area anyway, then the storage system is automatically aware that the data in those physical cells is obsolete. It's free to choose either those same cells or any different cells for the new data according to the wear leveling algorithms, but that's beside the point.
In D9611#198616, @avg wrote:My understanding of how L2ARC writing works is this. The code maintains a "hand" (like a clock hand) that points to a disk offset. At the regular intervals a certain space in front of the hand is freed by discarding L2 headers that point to that space and then new buffers are written to that space. Then the hand is moved forward by the appropriate amount.
There is also some freeing of L2 headers when ARC headers are freed, etc. In any case, after some uptime almost the whole cache disk is usually filled with data. And the hand inevitably moves forward. So, every block gets written over sooner or later. I do not see how TRIM helps in that case.
The only scenario where it makes difference, in my humble opinion, is the scenario that @mav described: a worn out disk where the "cheese holes" behind the hand can make some difference for writing new blocks at the hand. But I think that that's too marginal to be important.
In D9611#198582, @mav wrote:In D9611#198579, @smh wrote:In scenario #1 the performance of TRIM is also generally good, mitigating the need to avoid doing it.
Is there such thing as good TRIM performance? On my new Samsung 950 NVMe I had to disable TRIM as unusable. Though yes, NVMe driver still probably needs aggregation of TRIM requests to get better numbers.
In scenario #1 the performance of TRIM is also generally good, mitigating the need to avoid doing it.
This can could excessive slow down as the capacity of the disk is reached, however it could be argued that a better mitigation for L2ARC devices would be to use an under-provisioned slice to ensure the SSD controller always has space to work.
Jan 23 2017
Jan 16 2017
Jan 11 2017
Jan 9 2017
Nov 28 2016
Couple of little style nits and I'd like to understand why ENAMETOOLONG error gets turned into success in a few places.
Nov 2 2016
Oct 31 2016
Wouldn't it be better to have 0 (the default) be "use the PhyNum field as a fallback to the mapping logic" as that way at least the device would initialise when mpX_mapping_get_sas_id fails?
Aug 15 2016
Aug 14 2016
Aug 11 2016
Aug 4 2016
Jul 22 2016
Thanks for attacking this Andriy its a big task which really needed some attention.
Jul 13 2016
Apart from the comment this looks good in principle, however I think we need to better understand why retrying the probe works as it feels like where just hiding the real error with this.
Jul 11 2016
This looks reasonable however as you say its potentially racey with multiple renames happening.