Closed igalic closed 4 years ago
Travis error is unrelated:
./libioc/helpers_ioctl.py:44:23: T484 No overload variant of "ioctl" matches argument types "int", "Any", "bytes"
./libioc/helpers_ioctl.py:44:23: T400 note: Possible overload variants:
./libioc/helpers_ioctl.py:44:23: T400 note: def ioctl(__fd, Union[int, HasFileno], int, int = ..., bool = ...) -> int
./libioc/helpers_ioctl.py:44:23: T400 note: def ioctl(__fd, Union[int, HasFileno], int, Union[bytearray, memoryview, array[Any]], Literal[True] = ...) -> int
./libioc/helpers_ioctl.py:44:23: T400 note: <2 more non-matching overloads not shown>
just means newer mypy version is now detecting better… things?
A couple of days ago I upgraded my server to FreeBSD 12.1-RELEASE and used this branch to upgrade my years old libiocage to libioc + ioc. I used this branch to install and am now encountering the same issue as you do in your test run, namely a "Dataset xyz is not mounted". It occurs when creating a new jail and also when fetching a new release:
# ioc fetch -r 12.1-RELEASE
[-] FetchRelease@12.1-RELEASE: ...
[+] ReleasePrepareStorage@12.1-RELEASE: OK [0.112s]
[+] ReleaseDownload@12.1-RELEASE: OK [6.487s]
[+] ReleaseAssetDownload@12.1-RELEASE: OK [2.291s]
[-] ReleaseExtraction@12.1-RELEASE: FAILED [0.714s]
Dataset 'zroot/iocage/releases/12.1-RELEASE/root' is not mounted
Altough the dataset is actually mounted:
# mount | grep 'zroot/iocage/releases/12.1-RELEASE/root'
zroot/iocage/releases/12.1-RELEASE/root on /iocage/releases/12.1-RELEASE/root (zfs, local, noatime, nfsv4acls)
Digging through the codebase, I traced the issue back to the dataset.mountpoint
call in _require_dataset_mounted
(L115 in LaunchableResource.py
), but I cannot reproduce libzfs returing None
for the dataset's mountpoint.
I added a sleep before the mountpoint is checked and ran a script in a loop to check the mountpoint using both libzfs and libioc.ZFS.get_zfs(), but both reported the mountpoint correctly every time. I have no idea what the issue is here, but since I am interested in a fix I thought I'd shar my findings here. If there is anything I can do (testing, etc.) I'd gladly help out. I can reproduce the issue in @gronke's chore/update-default-python-version
branch as well. I also tried using the master branch of libzfs but that did not help either.
Test script for reference:
#!/usr/bin/env python3.7
import libzfs
import libioc
dataset_name = "zroot/iocage/releases/12.1-RELEASE"
stdzfs = libzfs.ZFS()
ioczfs = libioc.ZFS.get_zfs()
def check(zfs):
normal = zfs.get_dataset(dataset_name)
root = zfs.get_dataset(dataset_name + "/root")
print(f"normal mountpoint: {normal.mountpoint}")
print(f"root mountpoint: {root.mountpoint}")
print("without libioc zfs:")
check(stdzfs)
print("with libioc zfs:")
check(ioczfs)
BTW, shouldn't you also change the python version for the install-travis
target to `$pyver$ as well?
BTW, shouldn't you also change the python version for the
install-travis
target to `$pyver$ as well?
well, that's probably a good idea (done)
I'm seeing the same problem with
Dataset 'zroot/iocage/releases/12.1-RELEASE/root' is not mounted
Also same problem creating new jails.
Not sure if it helps but I reverted py-libzfs from 20191113 to 20181220 and error seems to go away
.. on it.. @igalic want to join me in tmux?
Not sure if it helps but I reverted py-libzfs from 20191113 to 20181220 and error seems to go away
i should look at the diff between those two
The regression was introduced with ZFS parallel mounts in FreeBSD 12.1: https://svnweb.freebsd.org/base?view=revision&revision=345578
Please note, that this PR is a duplicate and will not be merged. The Python-version will be updated in https://github.com/bsdci/libioc/pull/751. This PR remains open, so that we don't forget to clean dependencies (such as in https://github.com/bsdci/libioc/pull/753/commits/d074402ae6e93152446e699204cef016b1d2d80f).
@gronke so should I open a separate ZFS ticket?
Let's start collecting everyone's kernel and py-libzfs versions in #755
@gronke so should I open a separate ZFS ticket?
An issue exists, yes. Right now I'm further investigating the problem. Its deterministic across systems, built with or without the commit mentioned above. Before opening a ticket for FreeBSD, I'd like to have reduced my PoC to the minimal steps to reproduce without involving py-libzfs.
A hotfix to address this issue is to re-open ZFS handles for all operations involving mounts. At the same time it requires changes across the entire library and comes with a huge performance penalty. Rather than working around the issue, a custom C module tailored for ZFS operations of libioc seems more appropriate. We do know exactly what operations to perform on ZFS datasets, so this a good opportunity.
Be assured that there will be a hotfix for 12.1 as soon as I have fully understood the impact of the regression. Next step is a debugging session with @FabianFreyer on tmux. After that I should be able to provide a PoC that's worth a ticket on FreeBSD, reason about a short-term solution for libioc and maybe even find motivation to optimize ZFS workflows.
Commits have been incorporated in #751.
The hotfix was to disable mnttab_cache in py-libzfs.ZFS(..., mnttab_cache=False)
.
the default is now 3.7 on FreeBSD.