| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
Sort SEE ALSO section sequentially.
Highlighted by mandoc -Tlint
PR: 212440
Approved by: imp
Differential Revision: https://reviews.freebsd.org/D8192
|
|
|
|
|
|
|
|
| |
Add history section to nos-tun(8)
PR: 212545
Approved by: bcr (mentor)
Differential Revision: https://reviews.freebsd.org/D8104
|
|
|
|
|
|
|
|
|
| |
Add history section to natd(8)
Fix back sentence raised by igor.
PR: 212544
Approved by: bcr (mentor)
Differential Revision: https://reviews.freebsd.org/D8104
|
|
|
|
|
|
|
|
|
| |
Add history section to fsck_ffs(8)
Move sentence to a new line as advised by igor.
PR: 212474
Approved by: bcr (mentor)
Differential Revision: https://reviews.freebsd.org/D8104
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Document the history of fdisk based on the original post to comp.unix.bsd by Julian Elischer [1] and the Mach 2.
5 Installation notes [2].
I was unable to pin point the exact version of Mach the fdisk utility appeared as I could not find documentation
older than version 2.5 & no source code or repo history.
fdisk utility appears as a separate utility[3] in v2.5. Due to this, I have avoided stating the exact version fd
isk first appeared in Mach.
Add authors section.
[1] https://groups.google.com/d/topic/comp.unix.bsd/Hhi45vAHxDg/discussion
[2] ftp://ftp.mcs.vuw.ac.nz/doc/misc/mach-i386-doc/i386_install.ps
[3] ftp://ftp.mcs.vuw.ac.nz/doc/misc/mach-i386-doc/i386_manpages.ps
PR: 212470
Approved by: bcr (mentor)
Differential Revision: https://reviews.freebsd.org/D8104
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Document the history of fdisk based on the original post to comp.unix.bsd by Julian Elischer [1] and the Mach 2.5 Installation notes [2].
I was unable to pin point the exact version of Mach the fdisk utility appeared as I could not find documentation older than version 2.5 & no source code or repo history.
fdisk utility appears as a separate utility[3] in v2.5. Due to this, I have avoided stating the exact version fdisk first appeared in Mach.
Add authors section.
Make correction pointed by igor
[1] https://groups.google.com/d/topic/comp.unix.bsd/Hhi45vAHxDg/discussion
[2] ftp://ftp.mcs.vuw.ac.nz/doc/misc/mach-i386-doc/i386_install.ps
[3] ftp://ftp.mcs.vuw.ac.nz/doc/misc/mach-i386-doc/i386_manpages.ps
PR: 212469
Approved by: bcr (mentor)
Differential Revision: https://reviews.freebsd.org/D8104
|
|
|
|
|
|
|
|
|
| |
Add history section for devfs(8)
Move sentence to a new line as advised by igor.
PR: 212441
Approved by: bcr (mentor)
Differential Revision: https://reviews.freebsd.org/D8104
|
|
|
|
|
|
|
|
|
| |
Add history section for devd(8)
Move sentence to a new line as advised by igor
PR: 212439
Approved by: bcr (mentor)
Differential Revision: https://reviews.freebsd.org/D8104
|
|
|
|
|
|
|
|
|
| |
Add history section for clri(8)
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/man/man8/clri.8
PR: 212438
Approved by: bcr (mentor)
Differential Revision: https://reviews.freebsd.org/D8104
|
|
|
|
|
|
|
|
|
|
| |
Add history section for bsdlabel(8)
http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Tahoe/usr/man/cat8/disklabel.0
Remove tab after space, highlighted by igor
PR: 212436
Approved by: bcr (mentor)
Differential Revision: https://reviews.freebsd.org/D8104
|
|
|
|
|
|
|
|
| |
Add history section for atmconfig(8)
PR: 212415
Approved by: bcr (mentor)
Differential Revision: https://reviews.freebsd.org/D8104
|
|
|
|
|
|
|
|
|
| |
Add history section for test(1)
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/test.c
PR: 211789
Approved by: bcr (mentor)
Differential Revision: https://reviews.freebsd.org/D8104
|
|
|
|
|
|
|
|
|
| |
Add history section for stty(1)
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V3/man/man1/stty.1
PR: 211788
Approved by: bcr (mentor)
Differential Revision: https://reviews.freebsd.org/D8104
|
|
|
|
|
|
|
|
|
| |
Add history section of pwd(1)
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/source/s2/pwd.c
PR: 211787
Approved by: bcr (mentor)
Differential Revision: https://reviews.freebsd.org/D8104
|
|
|
|
|
|
|
|
|
| |
Document origins of expr & authors
http://minnie.tuhs.org/cgi-bin/utree.pl?file=PWB1/usr/man/man1/expr.1
PR: 173979
Approved by: bcr (mentor)
Differential Revision: https://reviews.freebsd.org/D8104
|
|
|
|
|
|
|
|
|
|
| |
Add history section for echo(1)
Sourced using the draft copy of the second edition manual
http://www.tuhs.org/Archive/PDP-11/Distributions/research/1972_stuff/unix_2nd_edition_manual.pdf
PR: 211785
Approved by: bcr (mentor)
Differential Revision: https://reviews.freebsd.org/D8104
|
|
|
|
|
|
|
|
| |
sconfig appeared in FreeBSD 5.2.
PR: 212550
Approved by: bcr (mentor)
Differential Revision: https://reviews.freebsd.org/D8105
|
|
|
|
|
|
|
|
|
| |
Note the version PF first appeared in FreeBSD & from which version it was ported from.
Address the contractions raised by igor.
PR: 212574
Approved by: bcr (mentor)
Differential Revision: https://reviews.freebsd.org/D8105
|
|
|
|
|
|
|
|
| |
Note the change of name in FreeBSD 5.0.
PR: 212542
Approved by: bcr (mentor)
Differential Revision: https://reviews.freebsd.org/D8105
|
|
|
|
|
|
|
|
| |
Note the name change from mount_null to mount_nullfs in FreeBSD 5.0.
PR: 212541
Approved by: bcr (mentor)
Differential Revision: https://reviews.freebsd.org/D8105
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Amend history to mention predecessor originated from 386BSD[1] & current implementation from NetBSD[2].
Reword history since the utility was renamed once more in FreeBSD 5.0.
Separate out author & historical information regarding character code conversion.
Add AUTHORS section.
[1] https://groups.google.com/forum/#!search/mount_pcfs.c/comp.unix.bsd/9qhH0v1tZm0/inlPnXZj_2sJ
[2] http://cvsweb.netbsd.org/bsdweb.cgi/src/sbin/mount_msdos/mount_msdos.c?rev=1.6&content-type=text/x-cvsweb-markup
PR: 212536
Approved by: bcr (mentor)
Differential Revision: https://reviews.freebsd.org/D8105
|
|
|
|
|
|
|
| |
use .Mt to mark up email addresses consistently (part1)
PR: 191174
Submitted by: Franco Fichtner <franco at lastsummer.de>
|
|
|
|
|
| |
There are some reports about panics on ic->ic_socket NULL derefence.
This kind of races is the only way I can imagine it to happen.
|
|
|
|
|
|
|
|
|
|
|
|
| |
sfxge(4): update external port mapping for Medford
Extend the mapping table for external port numbering to support port modes
which output to the second external port only. Where supported, map from
the current port mode rather than inferring from all the available modes.
Updated comments for clarity.
Submitted by: Richard Houldsworth <rhouldsworth at solarflare.com>
Sponsored by: Solarflare Communications, Inc.
|
|
|
|
|
|
|
|
|
|
|
| |
sfxge(4): sync tlv_layout.h with firmwaresrc and update port-mode
definition use
It fixes driver attach issue to a new firmware which reports a new
port-modes.
Submitted by: Tom Millington <tmillington at solarflare.com>
Sponsored by: Solarflare Communications, Inc.
|
|
|
|
| |
Import tzdata 2016g
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Incorporate a change from OpenBSD by millert@OpenBSD.org
Don't warn about valid time zone abbreviations. POSIX
through 2000 says that an abbreviation cannot start with ':', and
cannot contain ',', '-', '+', NUL, or a digit. POSIX from 2001
on changes this rule to say that an abbreviation can contain only
'-', '+', and alphanumeric characters from the portable character
set in the current locale. To be portable to both sets of rules,
an abbreviation must therefore use only ASCII letters." Adapted
from tzcode2015f.
This is needed to be able to update tzdata to a newer version
|
|
|
|
| |
Update pci_vendors to 2016-10-03
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The DS_FIELD_LARGE_BLOCKS macro has been unused since the integration of
this patch:
commit ca0cc3918a1789fa839194af2a9245f801a06b1a
Author: Matthew Ahrens <mahrens@delphix.com>
Date: Fri Jul 24 09:53:55 2015 -0700
5959 clean up per-dataset feature count code
Reviewed by: Toomas Soome <tsoome@me.com>
Reviewed by: George Wilson <george@delphix.com>
Reviewed by: Alex Reece <alex@delphix.com>
Approved by: Richard Lowe <richlowe@richlowe.net>
This patch simply removes this macro from dsl_dataset.h.
Reviewed by: Dan Kimmel <dan.kimmel@delphix.com>
Reviewed by: Prakash Surya <prakash.surya@delphix.com>
Reviewed by: Dan McDonald <danmcd@omniti.com>
Reviewed by: Igor Kozhukhov <ikozhukhov@gmail.com>
Author: Matthew Ahrens <mahrens@delphix.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
7278 tuning zfs_arc_max does not impact arc_c_min
When changing zfs_arc_max (e.g. as zdb does), it may be set to less
than the default arc_c_min. arc_c_min should decrease to not be more than
arc_c_max, but it doesn't; therefore tuning of arc_c_max is ineffective.
Reviewed by: Dan Kimmel <dan.kimmel@delphix.com>
Reviewed by: Paul Dagnelie <paul.dagnelie@delphix.com>
Reviewed by: Prakash Surya <prakash.surya@delphix.com>
Reviewed by: Igor Kozhukhov <ikozhukhov@gmail.com>
Author: Matthew Ahrens <mahrens@delphix.com>
openzfs/openzfs@608764beadaf4bb71c5d8fe1818e8392ac66a61b
|
|
|
|
|
| |
The upstream change introduced a new load state, SPA_LOAD_CREATE,
and vdev_geom code needs to be aware of it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
7004 dmu_tx_hold_zap() does dnode_hold() 7x on same object
Using a benchmark which has 32 threads creating 2 million files in the
same directory, on a machine with 16 CPU cores, I observed poor
performance. I noticed that dmu_tx_hold_zap() was using about 30% of
all CPU, and doing dnode_hold() 7 times on the same object (the ZAP
object that is being held).
dmu_tx_hold_zap() keeps a hold on the dnode_t the entire time it is
running, in dmu_tx_hold_t:txh_dnode, so it would be nice to use the
dnode_t that we already have in hand, rather than repeatedly calling
dnode_hold(). To do this, we need to pass the dnode_t down through
all the intermediate calls that dmu_tx_hold_zap() makes, making these
routines take the dnode_t* rather than an objset_t* and a uint64_t
object number. In particular, the following routines will need to have
analogous *_by_dnode() variants created:
dmu_buf_hold_noread()
dmu_buf_hold()
zap_lookup()
zap_lookup_norm()
zap_count_write()
zap_lockdir()
zap_count_write()
This can improve performance on the benchmark described above by 100%,
from 30,000 file creations per second to 60,000. (This improvement is on
top of that provided by working around the object allocation issue. Peak
performance of ~90,000 creations per second was observed with 8 CPUs;
adding CPUs past that decreased performance due to lock contention.) The
CPU used by dmu_tx_hold_zap() was reduced by 88%, from 340 CPU-seconds
to 40 CPU-seconds.
Sponsored by: Intel Corp.
Closes #109
Reviewed by: Steve Gonczi <steve.gonczi@delphix.com>
Reviewed by: George Wilson <george.wilson@delphix.com>
Reviewed by: Pavel Zakharov <pavel.zakharov@delphix.com>
Reviewed by: Ned Bass <bass6@llnl.gov>
Reviewed by: Brian Behlendorf <behlendorf1@llnl.gov>
Author: Matthew Ahrens <mahrens@delphix.com>
openzfs/openzfs@d3e523d489a169ab36f9ec1b2a111a60a5563a9f
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This resolves two 'zfs recv' issues. First, when receiving into an
existing filesystem, a snapshot created during the receive process is
not added to the guid->dataset map for the stream, resulting in failed
lookups for deduped streams when a WRITE_BYREF record refers to a
snapshot received earlier in the stream. Second, the newly created
snapshot was also not set properly, referencing the snapshot before the
new receiving dataset rather than the existing filesystem.
Closes #159
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Reviewed by: Dan Kimmel <dan.kimmel@delphix.com>
Author: Chris Williamson <chris.williamson@delphix.com>
openzfs/openzfs@b09697c8c18be68abfe538de9809938239402ae8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
zap_lockdir() / zap_unlockdir() should take a "void *tag" argument which
tags the hold on the zap. This will help diagnose programming errors
which misuse the hold on the ZAP.
Sponsored by: Intel Corp.
Closes #108
Reviewed by: Pavel Zakharov <pavel.zakharov@delphix.com>
Reviewed by: Steve Gonczi <steve.gonczi@delphix.com>
Reviewed by: George Wilson <george.wilson@delphix.com>
Reviewed by: Brian Behlendorf <behlendorf1@llnl.gov>
Author: Matthew Ahrens <mahrens@delphix.com>
openzfs/openzfs@0780b3eab5a2c13e04328b39ecd2a6d0d3c4f7cb
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
7230 add assertions to dmu_send_impl() to verify that stream includes BEGIN and
END records
illumos/illumos-gate@12b90ee2d3b10689fc45f4930d2392f5fe1d9cfa
https://github.com/illumos/illumos-gate/commit/12b90ee2d3b10689fc45f4930d2392f5f
e1d9cfa
https://www.illumos.org/issues/7230
A test failure occurred where a send stream had only a BEGIN record. This
should not be possible if the send returns without error. Prevented this from
happening in the future by adding an assertion to dmu_send_impl() to verify
that if the function returns 0 (success) both a BEGIN and END record are
present. Did this by adding flags to dmu_sendarg_t (indicating whether BEGIN o
r
END records sent), having dump_record() set flags appropriately, adding VERIFY
statement to dmu_send_impl().
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Reviewed by: Paul Dagnelie <pcd@delphix.com>
Reviewed by: Igor Kozhukhov <ikozhukhov@gmail.com>
Approved by: Robert Mustacchi <rm@joyent.com>
Author: Matt Krantz <matt.krantz@delphix.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
illumos/illumos-gate@bd56f80007857b960e0981ed0797ad8ec844a96b
https://github.com/illumos/illumos-gate/commit/bd56f80007857b960e0981ed0797ad8ec
844a96b
https://www.illumos.org/issues/7235
The function dsl_dataset_set_blkptr() is unused. We should remove it.
Reviewed by: George Wilson <george.wilson@delphix.com>
Reviewed by: Alex Reece <alex@delphix.com>
Reviewed by: Prakash Surya <prakash.surya@delphix.com>
Reviewed by: Igor Kozhukhov <ikozhukhov@gmail.com>
Approved by: Robert Mustacchi <rm@joyent.com>
Author: Matthew Ahrens <mahrens@delphix.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
illumos/illumos-gate@29bdd2f916366ece37c4748bca6b3d61f57a223b
https://github.com/illumos/illumos-gate/commit/29bdd2f916366ece37c4748bca6b3d61f
57a223b
https://www.illumos.org/issues/7277
ztest always prints the debug messages (zfs_dbgmsg()) by calling
zfs_dbgmsg_print(). We should add a flag to zdb to make it do this as well
before exiting.
Reviewed by: George Wilson <george.wilson@delphix.com>
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Reviewed by: Igor Kozhukhov <ikozhukhov@gmail.com>
Approved by: Dan McDonald <danmcd@omniti.com>
Author: Pavel Zakharov <pavel.zakharov@delphix.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
7090 zfs should improve allocation order and throttle allocations
illumos/illumos-gate@0f7643c7376dd69a08acbfc9d1d7d548b10c846a
https://github.com/illumos/illumos-gate/commit/0f7643c7376dd69a08acbfc9d1d7d548b
10c846a
https://www.illumos.org/issues/7090
When write I/Os are issued, they are issued in block order but the ZIO pipelin
e
will drive them asynchronously through the allocation stage which can result i
n
blocks being allocated out-of-order. It would be nice to preserve as much of
the logical order as possible.
In addition, the allocations are equally scattered across all top-level VDEVs
but not all top-level VDEVs are created equally. The pipeline should be able t
o
detect devices that are more capable of handling allocations and should
allocate more blocks to those devices. This allows for dynamic allocation
distribution when devices are imbalanced as fuller devices will tend to be
slower than empty devices.
The change includes a new pool-wide allocation queue which would throttle and
order allocations in the ZIO pipeline. The queue would be ordered by issued
time and offset and would provide an initial amount of allocation of work to
each top-level vdev. The allocation logic utilizes a reservation system to
reserve allocations that will be performed by the allocator. Once an allocatio
n
is successfully completed it's scheduled on a given top-level vdev. Each top-
level vdev maintains a maximum number of allocations that it can handle
(mg_alloc_queue_depth). The pool-wide reserved allocations (top-levels *
mg_alloc_queue_depth) are distributed across the top-level vdevs metaslab
groups and round robin across all eligible metaslab groups to distribute the
work. As top-levels complete their work, they receive additional work from the
pool-wide allocation queue until the allocation queue is emptied.
Reviewed by: Adam Leventhal <ahl@delphix.com>
Reviewed by: Alex Reece <alex@delphix.com>
Reviewed by: Christopher Siden <christopher.siden@delphix.com>
Reviewed by: Dan Kimmel <dan.kimmel@delphix.com>
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Reviewed by: Paul Dagnelie <paul.dagnelie@delphix.com>
Reviewed by: Prakash Surya <prakash.surya@delphix.com>
Reviewed by: Sebastien Roy <sebastien.roy@delphix.com>
Approved by: Robert Mustacchi <rm@joyent.com>
Author: George Wilson <george.wilson@delphix.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
illumos/illumos-gate@f34284d835bc555f987c1310df46c034c3101155
https://github.com/illumos/illumos-gate/commit/f34284d835bc555f987c1310df46c034c
3101155
https://www.illumos.org/issues/7163
Running zloop from zfs-precommit hit this assertion:
*panicstr/s
0xfffffd7fd7419370: assertion failed for thread 0xfffffd7fe29ed240,
thread-id 577: parent != NULL, file ../../../uts/common/fs/zfs/dbuf.c, line
1827
$c
libc.so.1`_lwp_kill+0xa()
libc.so.1`_assfail+0x182(fffffd7ffb1c29fa, fffffd7ffb1cc028, 723)
libc.so.1`assfail+0x19(fffffd7ffb1c29fa, fffffd7ffb1cc028, 723)
libzpool.so.1`dbuf_dirty+0xc69(10e3bc10, 3601700)
libzpool.so.1`dbuf_dirty+0x61e(10c73640, 3601700)
libzpool.so.1`dbuf_dirty+0x61e(10e28280, 3601700)
libzpool.so.1`dmu_buf_will_fill+0x64(10e28280, 3601700)
libzpool.so.1`dmu_write+0x1b6(2c7e640, d, 400000002e000000, 200, 3717b40,
3601700)
ztest_replay_write+0x568(4950d0, 3717a80, 0)
ztest_write+0x125(4950d0, d, 400000002e000000, 200, 413f000)
ztest_io+0x1bb(4950d0, d, 400000002e000000)
ztest_dmu_write_parallel+0xaa(4950d0, 6)
ztest_execute+0x83(1, 420c98, 6)
ztest_thread+0xf4(6)
libc.so.1`_thrp_setup+0x8a(fffffd7fe29ed240)
libc.so.1`_lwp_start()
This is another manifestation of ECKSUM in ztest:
The lowest level ancestor that’s in memory is the L8 (topmost). The L7
ancestor is blkid 0x10:
::dbufs -O 0x2c7e640 -o d -l 7 |::dbuf
addr object lvl blkid holds os
600be50 d 7 4 1 ztest/ds_6
719d880 d 7 0 4 ztest/ds_6
Reviewed by: George Wilson <george.wilson@delphix.com>
Reviewed by: Paul Dagnelie <pcd@delphix.com>
Approved by: Robert Mustacchi <rm@joyent.com>
Author: Matthew Ahrens <mahrens@delphix.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
illumos/illumos-gate@f9eb9fdf196b6ed476e4ffc69cecd8b0da3cb7e7
https://github.com/illumos/illumos-gate/commit/f9eb9fdf196b6ed476e4ffc69cecd8b0d
a3cb7e7
https://www.illumos.org/issues/6451
Sometimes ztest fails because zdb detects checksum errors. e.g.:
Traversing all blocks to verify checksums and verify nothing leaked ...
zdb_blkptr_cb: Got error 50 reading <71, 47, 0, 8000160> DVA0=<0:1cc2000:
180000> [L0 other uint64[]] sha256 uncompressed LE contiguou
s unique single size=100000L/100000P birth=271L/271P fill=1
cksum=c5a3e27d1ed0f894:843bca3a5473c4bf:f76a19b6830a2e4:91292591613a12bf --
skipping
zdb_blkptr_cb: Got error 50 reading <71, 47, 0, 800000180> DVA0=<0:ce16800:
180000> [L0 other uint64[]] sha256 uncompressed LE contigu
ous unique single size=100000L/100000P birth=840L/840P fill=1
cksum=5d018f3d061e17f3:6d1584784587bf63:2805a74a0ce37369:ba68a214806c7e75
-- skipping
zdb_blkptr_cb: Got error 50 reading <71, 47, 0, 1000000360> DVA0=<0:10d37400:
180000> [L0 other uint64[]] sha256 uncompressed LE conti
guous unique single size=100000L/100000P birth=904L/904P fill=1
cksum=fa1e11d4138bd14b:86c9488c444473e3:f31e43c72e72e46b:e3446472d1174d
ba -- skipping
zdb_blkptr_cb: Got error 50 reading <71, 47, 0, 400000002c0> DVA0=<0:127ef400:
180000> [L0 other uint64[]] sha256 uncompressed LE cont
iguous dedup single size=100000L/100000P birth=549L/549P fill=1
cksum=30e14955ebf13522:66dc2ff8067e6810:4607e750abb9d3b3:6582b8af909fcb
58 -- skipping
zdb_blkptr_cb: Got error 50 reading <657, 5, 0, 1c0> DVA0=<0:1a180400:180000>
[L0 other uint64[]] fletcher4 uncompressed LE contiguou
s unique single size=100000L/100000P birth=1091L/1091P fill=1 cksum=a6cf1e50:
29b3bd01c57e5:36779b914035db9a:db61cdcf6bec56f0 -- skippin
g
The problem is that ztest_fault_inject() can inject multiple faults into the
same block. It is designed such that it can inject errors on all leafs of a
RAID-Z or mirror, but for a given range of offsets, it will only inject errors
Reviewed by: George Wilson <george.wilson@delphix.com>
Reviewed by: Prakash Surya <prakash.surya@delphix.com>
Reviewed by: Jorgen Lundman <lundman@lundman.net>
Approved by: Dan McDonald <danmcd@omniti.com>
Author: Matthew Ahrens <mahrens@delphix.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
7147 ztest: ztest_ddt_repair fails with ztest_pattern_match assertion
illumos/illumos-gate@aab80726335c76a7cae32c7300890248d73a51e3
https://github.com/illumos/illumos-gate/commit/aab80726335c76a7cae32c7300890248d
73a51e3
https://www.illumos.org/issues/7147
Here's the dbuf we're currently reading:
966f200::dbuf
addr object lvl blkid holds os
966f200 4 0 0 1 ztest/ds_3
966f200::print dmu_buf_t db_data
db_data = 0x9ae0400
0x9ae0400/10J
0x9ae0400: c1c7ced932020d c1c7ced932020d c1c7ced932020d c1c7ced932020d
c1c7ced932020d c1c7ced932020d c1c7ced932020d c1c7ced932020d
c1c7ced932020d c1c7ced932020d
The pattern we're expecting is actually this: a34ae10b5f2db2. If we attempt to
read the block on disk we find that it has matches what ztest_ddt_repair()
would have written:
~c1c7ced932020d=J
ff3e383126cdfdf2
966f200::print dmu_buf_impl_t db_blkptr | ::blkptr
DVA0=<0:71d3c00:800>
[L0 UINT64_OTHER] SHA256 OFF LE contiguous dedup single
size=400L/400P birth=55L/55P fill=1
cksum=18486450d3ce8c6d:75a72f4bbf117b0f:2d3a226314eb5650:2eb0fd68648b1af0
1. zdb -U /rpool/tmp/zpool.cache -R ztest 0:71d3c00:800 | head
Found vdev type: mirror
0:71d3c00:800
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
000000: ff3e383126cdfdf2 ff3e383126cdfdf2 ...&18>....&18>.
000010: ff3e383126cdfdf2 ff3e383126cdfdf2 ...&18>....&18>.
000020: ff3e383126cdfdf2 ff3e383126cdfdf2 ...&18>....&18>.
000030: ff3e383126cdfdf2 ff3e383126cdfdf2 ...&18>....&18>.
000040: ff3e383126cdfdf2 ff3e383126cdfdf2 ...&18>....&18>.
000050: ff3e383126cdfdf2 ff3e383126cdfdf2 ...&18>....&18>.
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Reviewed by: Prakash Surya <prakash.surya@delphix.com>
Approved by: Robert Mustacchi <rm@joyent.com>
Author: George Wilson <george.wilson@delphix.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
7086 ztest attempts dva_get_dsize_sync on an embedded blockpointer
illumos/illumos-gate@926549256b71acd595f69b236779ff6b78fa08ef
https://github.com/illumos/illumos-gate/commit/926549256b71acd595f69b236779ff6b7
8fa08ef
https://www.illumos.org/issues/7086
In dbuf_dirty(), we need to grab the dn_struct_rwlock before looking at the
db_blkptr, to prevent it from being changed by syncing context.
Otherwise we may see that ztest got a segfault from this stack:
libzpool.so.1`dva_get_dsize_sync+0x98(872f000, b32b240, fed7811b, 0, b4cda20,
0)
libzpool.so.1`bp_get_dsize+0x60(872f000, b32b240, 0, 97cb780, 9d4c1a8, 0)
libzpool.so.1`dbuf_dirty+0x9b3(ce0a100, 97cb780, 9, fecd2530)
libzpool.so.1`dmu_buf_will_dirty+0xc3(ce0a100, 97cb780, ea293d6c, 1)
libzpool.so.1`zap_lockdir+0x1a0(8aaa3c0, 1, 0, 97cb780, 1, 1)
libzpool.so.1`zap_remove_norm+0x30(8aaa3c0, 1, 0, 8728b10, 0, 97cb780)
libzpool.so.1`zap_remove+0x29(8aaa3c0, 1, 0, 8728b10, 97cb780, a)
ztest_replay_remove+0x225(ea294588, 8728ae8, 0, 38010000, 0, 0)
ztest_remove+0x9f(ea294588, ea293f50, 4, 3)
ztest_object_init+0x78(ea294588, ea293f50, 4e0, 1)
ztest_dmu_object_alloc_free+0x71(ea294588, 13)
ztest_dmu_objset_create_destroy+0x224(80cef08, 13, 0, 805d36c, 9017ad44, 0)
ztest_execute+0x89(a, 807c720, 13, 0)
ztest_thread+0xea(13, 0, 0, 0)
libc.so.1`_thrp_setup+0x88(f0983240)
libc.so.1`_lwp_start(f0983240, 0, 0, 0, 0, 0)
Looking into it a bit, we see that this is an embedded blockpointer, so
BP_GET_NDVAS should have returned 0:
b32b240::blkptr
EMBEDDED [L0 ZAP_OTHER] et=0 LZ4 size=200L/4aP birth=80L
Instead, it looks like another thread is modifying this blockpointer:
b32b240::ugrep | ::whatis
f47a0e0c is in [ stack tid=0x19f ]
ebd6ec40 is in [ stack tid=0x226 ]
ea293bd0 is in [ stack tid=0x244 ]
ea293be4 is in [ stack tid=0x244 ]
Reviewed by: Prakash Surya <prakash.surya@delphix.com>
Reviewed by: George Wilson <george.wilson@delphix.com>
Approved by: Robert Mustacchi <rm@joyent.com>
Author: Matthew Ahrens <mahrens@delphix.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
7072 zfs fails to expand if lun added when os is in shutdown state
illumos/illumos-gate@c39a2aae1e2c439d156021edfc20910dad7f9891
https://github.com/illumos/illumos-gate/commit/c39a2aae1e2c439d156021edfc20910da
d7f9891
https://www.illumos.org/issues/7072
upstream:
38733 zfs fails to expand if lun added when os is in shutdown state
DLPX-36910 spares and caches should not display expandable space
DLPX-39262 vdev_disk_open spam zfs_dbgmsg buffer
Reviewed by: Igor Kozhukhov <ikozhukhov@gmail.com>
Reviewed by: Dan Kimmel <dan.kimmel@delphix.com>
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Reviewed by: Prakash Surya <prakash.surya@delphix.com>
Reviewed by: Alex Reece <alex@delphix.com>
Approved by: Dan McDonald <danmcd@omniti.com>
Author: George Wilson <george.wilson@delphix.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
illumos/illumos-gate@dcbf3bd6a1f1360fc1afcee9e22c6dcff7844bf2
https://github.com/illumos/illumos-gate/commit/dcbf3bd6a1f1360fc1afcee9e22c6dcff
7844bf2
https://www.illumos.org/issues/6950
When reading compressed data from disk, the ARC should keep the compressed
block cached and only decompress it when consumers access the block. The
uncompressed data should be short-lived allowing the ARC to cache a much large
r
amount of data. The DMU would also maintain a smaller cache of uncompressed
blocks to minimize the impact of decompressing frequently accessed blocks.
Reviewed by: Prakash Surya <prakash.surya@delphix.com>
Reviewed by: Dan Kimmel <dan.kimmel@delphix.com>
Reviewed by: Matt Ahrens <mahrens@delphix.com>
Reviewed by: Paul Dagnelie <pcd@delphix.com>
Reviewed by: Don Brady <don.brady@intel.com>
Reviewed by: Richard Elling <Richard.Elling@RichardElling.com>
Approved by: Richard Lowe <richlowe@richlowe.net>
Author: George Wilson <george.wilson@delphix.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
306484
hyperv/vmbus: Add missing vmbus_if.c to module build.
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8067
306485
hyperv/hn: Add stubs for OFFLOAD_CURRENT_CONFIG and NETWORK_CHANGE status
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8068
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
306482
hyperv/hn: If synthetic parts are detached, don't touch them.
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8065
306483
hyperv/hn: Fix detach and attach error handling.
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8066
|
|
|
|
|
|
|
|
|
|
|
|
| |
x86/ioapic: Fix destination cpu for Hyper-V
On Hyper-V:
- Stick to the first cpu for all I/O APIC pins.
- And don't allow destination cpu changes.
Reviewed by: jhb
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D7949
|
|
|
|
|
|
|
|
|
| |
hyperv/hn: Don't set HASHVAL pktinfo for NDIS < 6.30
This unbreaks packet sending on WS2008R2.
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8057
|