@Colin this was indeed fixed by the backport of
4ecd55ea074217473f94cfee21bb72864d39f8d7, as we suspected it would be. I
think this can be closed.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1832384
We are going to set a system with a 4.15.0-60 kernel from the -proposed
repository to confirm that this fixes the issue. Colin, do you know when
that kernel will make its way out of -proposed and become generally
available?
--
You received this bug notification because you are a member of Ubuntu
It looks like items are in rare cases being removed from the export
cache's hash table without being removed from the queue. Once they are
removed from the hash table, no downcall can complete the request,
because the item can't be looked up in the hash table, leaving the item
orphaned, along with
We used BPF/BCC to trace all refcount changes on all of the relevant
mounts, and for each (struct mount*, stack) pair, kept track of the
number of references acquired/released by that pair. Including the
struct mount* in the key in our map make the map quite large, but
allowed us to pare the
We are still seeing this issue and still working on tracking it down.
We've done some tracing to track all of the refcount changes by stack
when this occurs. However, the refcount is manipulated from many
different contexts, making it difficult to identify which increment is
the odd one out.
We
Thanks for taking a look. One of the things that is painful about
debugging this issue is how long it takes to manifest. It would probably
require several weeks of testing a particular kernel version without
seeing the issue before we could be reasonably sure that the problem is
fixed. Also,
Public bug reported:
We periodically see an issue where unmounting a ZFS filesystem fails
with EBUSY, even though there appears to be no one using it.
# cat /proc/self/mounts | grep
/domain0/group-38/oracle_db_container-202/oracle_timeflow-16370/archive
@Mathieu, thanks for your work on this.
Regarding the test cases, I think that the second case needs an
additional step:
-- initramfs update --
1) install Ubuntu, using ZFS as a rootfs.
2) change 'MODULES=most' to 'MODULES=dep' in /etc/initramfs-tools/initramfs.conf
3) run "sudo update-initramfs
** Patch added: "mkinitramfs.patch"
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1661629/+attachment/5162606/+files/mkinitramfs.patch
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
> It might be easier to resolve this by considering this as "mkinitramfs
fails on ZFS root without /etc/fstab lines for the ZFS filesystems when
MODULES=dep is used".
Yes, that sounds like an accurate summary. I'm not sure I follow how
/etc/fstab is related, though. Looking briefly through
> I'm not particularly familiar with this part of initramfs-tools, but
it seems to me that essentials like the loading of the virtio_pci module
would be short-circuited by your patch.
Yes, you're right, thanks for pointing that out. If the driver isn't
built-in to the kernel, it would be omitted.
Maybe there is something better, but it seems like the simplest change
that would fix this would be something along the lines of the patch
below. This just assumes that if the filesystem type is listed as zfs
then it actually is zfs, and it adds the zfs module. With this change I
was able to build
12 matches
Mail list logo
