You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 9, 2022. It is now read-only.
tmpfs on /var type tmpfs (rw,nosuid,nodev,noexec,relatime,size=1023524k,mode=755)
testpool/nextnas/containerd-vol on /var/lib/containerd/io.containerd.snapshotter.v1.zfs type zfs (rw,xattr,noacl)
testpool on /var/zpool type zfs (rw,xattr,noacl)
testpool/nextnas on /var/zpool/nextnas type zfs (rw,xattr,noacl)
The pool is not a file on the disk, thus could not be stated.
We need to figure out how to get device UUID for zfs. Or maybe we need admin to pass the UUID to us for zfs if we could not figure it out.
The text was updated successfully, but these errors were encountered:
Reopen this issue. According to #335 (comment), ZFS still doesn't work.
The main problem is that ZFS doesn't have an uuid, because it manages the block/volume itself.
I feel like we should throw out an error and proceeding if we could not get uuid, the only thing won't work is that kubelet can't get image fs capacity. However, we should not block people from trying this out because of that.
We added skip-imagefs-uuid flag, and will be included in v1.0.0-beta.1. If the current uuid based approach doesn't work, user could use that flag to skip that step. It should not prevent user from trying out this.
I'll close this issue. Further discussion will be carried on in the kubernetes issue kubernetes/kubernetes#57356.
Mount info for ZFS is like this:
The pool is not a file on the disk, thus could not be stated.
We need to figure out how to get device UUID for zfs. Or maybe we need admin to pass the UUID to us for zfs if we could not figure it out.
The text was updated successfully, but these errors were encountered: