Committed as part of rP527260
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Feb 27 2020
fine, 10x Tijl
Move creation of a "minor" from dsl_dataset_snapshot_sync_impl() to
dsl_dataset_snapshot_sync(). The former is also used by
dsl_dataset_snapshot_tmp_sync() and we do not need to create minors for
temporary snapshots. They are used only by zfs diff against a filesystem (via
ZFS_IOC_TMP_SNAPSHOT).
rebase to r358382
In D18624#458099, @jtl wrote:This looks like it does what is described. As I understand, the use of delivered_data will be covered by a separate review. It looks like this will slightly change the way sacked_bytes is calculated. The change is probably a good thing, but it is worth verifying (and I haven't done this yet) that the updated calculation will work correctly.
Added two more occurences of direct use of NG_VERSION: libexec/pppoed/pppoed.c usr.sbin/ppp/ether.c
OK, I'll mark them as mpsafe in a commit.
The idea is to allow a split of large messages into smaller ones over size limited links. In kernel this is never necessary.
Replaced by D23844.
Replaced by D23844.
In D23783#523422, @ngie wrote:One thing that isn't clear is why this sanity check is needed. Is this being specifically for platform integration issue with PowerPC64, or is there another better reason for why this needs to be done given the API? If for the latter reason and the item is well-documented, please add it. If not, this doesn't seem to serve much value and might be better implemented as a platform-specific regression test.
Please test this on amd64 as well as a sanity check, second.
Looks good.
Can someone look at the hpts bits please? I know they are not as straight forward as is the ktls case.
- Merge pull request #1 from knobix/arcpatch-D12592
I am happy with this revision.
In D23836#524333, @jhb wrote:So for reference, I ran 'tftp' over localhost to fetch a ~5MB file. With the defaults (512b blocks, 1 window), it took 1.7 seconds. With 1024 byte blocks it took 1.2 seconds. With 512 byte blocks and a windowsize of 16 it took 0.2 seconds, and with 1025 byte blocks and a windowsize of 16 it took 0.1 seconds (as reported by the client). For that simple test it seems that windowsize makes a much bigger difference than blocksize for improving throughput.
So for reference, I ran 'tftp' over localhost to fetch a ~5MB file. With the defaults (512b blocks, 1 window), it took 1.7 seconds. With 1024 byte blocks it took 1.2 seconds. With 512 byte blocks and a windowsize of 16 it took 0.2 seconds, and with 1025 byte blocks and a windowsize of 16 it took 0.1 seconds (as reported by the client). For that simple test it seems that windowsize makes a much bigger difference than blocksize for improving throughput.