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.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Feed Advanced Search
Advanced Search
Advanced Search
Feb 19 2017
Feb 19 2017
smh retitled D9668: Support estimated RTT for receive buffer auto resizing from to Support estimated RTT for receive buffer auto resizing.
Feb 15 2017
Feb 15 2017
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 23 2017
Jan 16 2017
Jan 16 2017
Jan 11 2017
Jan 11 2017
Jan 9 2017
Jan 9 2017
Fix rstat: symbol not in namelist from netstat
Nov 28 2016
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
Nov 2 2016
Oct 31 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 15 2016
Aug 14 2016
Aug 14 2016
Aug 11 2016
Aug 11 2016
Fix vtnet hang with max_virtqueue_pairs > VTNET_MAX_QUEUE_PAIRS
Aug 4 2016
Aug 4 2016
Jul 22 2016
Jul 22 2016
Thanks for attacking this Andriy its a big task which really needed some attention.
Jul 13 2016
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
Jul 11 2016
This looks reasonable however as you say its potentially racey with multiple renames happening.
Jul 6 2016
Jul 6 2016
Fix ZFS ARC min / max tunable
Jun 29 2016
Jun 29 2016
Allow ZFS ARC min / max to be tuned at runtime
Jun 28 2016
Jun 28 2016
Jun 14 2016
Jun 14 2016
I'd like to know why finding the current device would ever fail?
Jun 3 2016
Jun 3 2016
Jun 1 2016
Jun 1 2016
Fix tzsetup not installing /etc/localtime for UTC
May 9 2016
May 9 2016
May 5 2016
May 5 2016
Apr 11 2016
Apr 11 2016
Only include sysctl in kernel build
Remove redundent check on <= 0
smh retitled D5907: Allow ZFS ARC min / max to be tuned at runtime from to Allow ZFS ARC min / max to be tuned at runtime.
Only include sysctl in kernel build
Apr 9 2016
Apr 9 2016
Nice, do you have metrics on the typical dump size increase?
Apr 8 2016
Apr 8 2016
This looks like it might leave old data in the zpool.cache?
Apr 7 2016
Apr 7 2016
Seems reasonable to me
Mar 21 2016
Mar 21 2016
Mar 19 2016
Mar 19 2016
Mar 16 2016
Mar 16 2016
Prevent invalid ixgbe advertise setting warning
Mar 10 2016
Mar 10 2016
Mar 3 2016
Mar 3 2016
Feb 26 2016
Feb 26 2016
Removed unused label and fix mutex_exit order
Fix NULL pointer dereferences
Feb 25 2016
Feb 25 2016
Missed a few sub indents on the white space fixup.
Fix invalid whitespacing (7 spaces instead of tabs)
Define and init cpu_id using rss_getcpu.
Feb 22 2016
Feb 22 2016
Feb 20 2016
Feb 20 2016
We should get this up-streamed.
Feb 14 2016
Feb 14 2016
Add MySQL 5.7 symlinks for mysqlclient_r libs
Feb 11 2016
Feb 11 2016
MFC r295320, r295356 (Partial)
Fix ia64 build failures in EFI platform
MFC r294734, r295093 & r295094 ixgbe fixes
Feb 8 2016
Feb 8 2016
Restructure Makefile fix to aid future merges as per ngie's suggestion.
Feb 6 2016
Feb 6 2016
Fix EFI platform build failures
Fix pointer cast issue on arm.armeb.
In D5212#110873, @ngie wrote:Was there any change to how the operations need to be done in order to call efi_handle_lookup in the amd64/arm64 case on head with a ZFS root?
Feb 5 2016
Feb 5 2016
Fix EFI multi device boot support
smh closed D5108: Improve EFI multi device boot support by committing rS295320: Fix EFI multi device boot support.
Feb 3 2016
Feb 3 2016
Feb 1 2016
Feb 1 2016
Almost there. recomparing with our diff the only remaining missing block is the following which comes from between r283882 and r283883:
Fix device_paths_match breakage in last diff caused by late check of media type match.
Jan 31 2016
Jan 31 2016
- Comment new methods.
- Fix possible edge case in device_paths_match.
- Fix failure printf in first path case for load_loader.
- Small flow optimisation in try_boot.
- Rename devpath_strncat -> devpath_strlcat to more closely describe its function in terms of standard string functions.
- Increase devpath_str buffer to 256 as 128 could be could be close.
- Optimise placement of device_paths_match in probe_handle.
Fix ixgbe flow control autoneg reporting
Configure ixgbe phy & gbic power
smh closed D5107: Configure ixgbe phy & gbic power by committing rS295093: Configure ixgbe phy & gbic power.
- Add SATA devpath node decoding
- Fix and rename msg_path_matches -> device_path_matches
- Add boot1 imgpath debug
Further debugging improvements.
Jan 30 2016
Jan 30 2016
Refactor preferred device so that:
- Its sticky for all requests, this ensures that boot.config is loaded from the same device / pool as loader.efi.
- Allows UFS only preferred devices to work correctly.
Fix clean target for sys/boot/efi
@imp with the latest set of improved debugging we should be able to see what's loading from where.
- Change boot module loader_path -> filepath to better refect its use.
- Switch devinfo_t.devpath to store the full path instead of final node to aid debugging.
- Improve debug and error output.
- Fix DPRINTF for single argument use.
- Refactor msgpath calculation into seperate methods.
Committed as: https://svnweb.freebsd.org/changeset/base/295051
Jan 29 2016
Jan 29 2016
Fix phy interrupts setup for ixl
In D5117#108850, @sbruno wrote:I should have captured r285592 in the MFC of driver version 3.1.0 to stable 10. https://svnweb.freebsd.org/base?view=revision&revision=294061
In D5108#108719, @imp wrote:When I tested this with a USB drive that had a /boot.config with -h and a SATA SSD with a boot.config with -D in it. The sata was fs0: in the uefi shell , while the usb clocked in with fs1. I get identical boot behavior if I type in fs0:\efi\boot\bootx64.efi and fs1:\efi\boot\bootx64.efi. Both of them are dying during boot because there's no /dev/ada0 to satisfy the /etc/fstab I have on the usb drive. If I pull it out, it goes back to booting correctly.
So it appears that we're now finding the loader.efi, but that at least boot1 is still confused a bit. Perhaps my hack for the /boot.config stuff in there needs to be fixed too, since it clearly is finding the loader.efi.
Anything I can do to help debug this?