#
331395 |
|
22-Mar-2018 |
mav |
MFC r329681: MFV r318941: 7446 zpool create should support efi system partition
illumos/illumos-gate@7855d95b30fd903e3918bad5a29b777e765db821 https://github.com/illumos/illumos-gate/commit/7855d95b30fd903e3918bad5a29b777e765db821
https://www.illumos.org/issues/7446 Since we support whole-disk configuration for boot pool, we also will need whole disk support with UEFI boot and for this, zpool create should create efi- system partition. I have borrowed the idea from oracle solaris, and introducing zpool create - B switch to provide an way to specify that boot partition should be created. However, there is still an question, how big should the system partition be. For time being, I have set default size 256MB (thats minimum size for FAT32 with 4k blocks). To support custom size, the set on creation "bootsize" property is created and so the custom size can be set as: zpool create B - o bootsize=34MB rpool c0t0d0 After pool is created, the "bootsize" property is read only. When -B switch is not used, the bootsize defaults to 0 and is shown in zpool get output with value ''. Older zfs/zpool implementations are ignoring this property. https://www.illumos.org/rb/r/219/
Reviewed by: Andrew Stormont <andyjstormont@gmail.com> Reviewed by: Yuri Pankov <yuri.pankov@gmail.com> Approved by: Dan McDonald <danmcd@kebe.com> Author: Toomas Soome <tsoome@me.com>
This commit makes no sense for FreeBSD, that is why I blocked the option, but it should be good to stay closer to upstream.
|
#
330733 |
|
10-Mar-2018 |
asomers |
MFC r329273, r329275, r329277, r329284, r329344
r329273: geli: append "/eli" to the underlying provider's physical path
If the underlying provider's physical path is null, then the geli device's physical path will be, too. Otherwise, it will append "/eli". This will make geli work better with zfsd(8).
PR: 224962 Differential Revision: https://reviews.freebsd.org/D13979
r329275: gpart: append partition name to the underlying provider's physical path
If the underlying provider's physical path is null, then the gpart device's physical path will be, too. Otherwise, it will append the partition name, such as "/p1" or "/s1/a". This will make gpart work better with zfsd(8).
PR: 224965 Differential Revision: https://reviews.freebsd.org/D14010
r329277: Add mtree entry for 329275
X-MFC-With: 329275 Sponsored by: Spectra Logic Corp
r329284: zfsd: Allow zfsd to work on any type of GEOM provider
cddl/usr.sbin/zfsd/zfsd_event.cc Remove the check for da and ada devices. This way zfsd can work on md, geli, glabel, gstripe, etc devices. geli in particular is useful combined with ZFS. gnop is also useful for simulating drive pulls in the ZFSD test suite.
Also, eliminate the DevfsEvent class entirely. Move its responsibilities into GeomEvent. We can get everything we need to know just from listening to GEOM events.
lib/libdevdctl/event.cc Fix GeomEvent::DevName for CREATE events. Oddly, the relevant field is named "cdev" for CREATE events but "devname" for disk events.
Relnotes: Yes (probably worth mentioning the geli part) Sponsored by: Spectra Logic Corp
r329344: Optimize zfsd for the happy case
If there are no damaged pools, then ignore all GEOM events. We only use them to fix damaged pools. However, still pay attention to ZFS events.
X-MFC-With: 329284 Sponsored by: Spectra Logic Corp
|
#
326321 |
|
28-Nov-2017 |
asomers |
MFC r325011, r325016
r325011: zfsd should be able to online an L2ARC that disappears and returns
Previously, this didn't work because L2ARC devices' labels don't contain pool GUIDs. Modify zfsd so that the pool GUID won't be required:
lib/libdevdctl/guid.h Change INVALID_GUID from a uint64_t constant to a function that returns an invalid Guid object. Remove the void constructor. Nothing uses it, and it violates RAII.
cddl/usr.sbin/zfsd/case_file.h cddl/usr.sbin/zfsd/case_file.cc Allow CaseFile::Find to match a CaseFile based on Vdev GUID alone. In CaseFile::ReEvaluate, attempt to online devices even if the newly arrived device has no pool GUID.
cddl/usr.sbin/zfsd/vdev_iterator.cc Iterate through a pool's cache devices as well as its regular devices.
Reported by: avg Reviewed by: avg Sponsored by: Spectra Logic Corp Differential Revision: https://reviews.freebsd.org/D12791
r325016: Partially revert r325011: restore Guid's default constructor
Reported by: ohartmann X-MFC-With: 325011 Sponsored by: Spectra Logic Corp
|
#
300906 |
|
28-May-2016 |
asomers |
zfsd(8), the ZFS fault management daemon
Add zfsd, which deals with hard drive faults in ZFS pools. It manages hotspares and replements in drive slots that publish physical paths.
cddl/usr.sbin/zfsd Add zfsd(8) and its unit tests
cddl/usr.sbin/Makefile Add zfsd to the build
lib/libdevdctl A C++ library that helps devd clients process events
lib/Makefile share/mk/bsd.libnames.mk share/mk/src.libnames.mk Add libdevdctl to the build. It's a private library, unusable by out-of-tree software.
etc/defaults/rc.conf By default, set zfsd_enable to NO
etc/mtree/BSD.include.dist Add a directory for libdevdctl's include files
etc/mtree/BSD.tests.dist Add a directory for zfsd's unit tests
etc/mtree/BSD.var.dist Add /var/db/zfsd/cases, where zfsd stores case files while it's shut down.
etc/rc.d/Makefile etc/rc.d/zfsd Add zfsd's rc script
sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev.c Fix the resource.fs.zfs.statechange message. It had a number of problems:
It was only being emitted on a transition to the HEALTHY state. That made it impossible for zfsd to take actions based on drives getting sicker.
It compared the new state to vdev_prevstate, which is the state that the vdev had the last time it was opened. That doesn't make sense, because a vdev can change state multiple times without being reopened.
vdev_set_state contains logic that will change the device's new state based on various conditions. However, the statechange event was being posted _before_ that logic took effect. Now it's being posted after.
Submitted by: gibbs, asomers, mav, allanjude Reviewed by: mav, delphij Relnotes: yes Sponsored by: Spectra Logic Corp, iX Systems Differential Revision: https://reviews.freebsd.org/D6564
|