On 10/9/20 7:54 PM, Eric van Gyzen wrote:
On 10/9/20 6:27 PM, Ryan Moeller wrote:
On 10/9/20 6:22 PM, Alan Somers wrote:
This sounds like it might be a regression introduced by the OpenZFS
merge.
Have you compared vdev_geom.c in OpenZFS vs the old version?
-Alan
I don't think vdev_geom.c i
On 10/9/20 6:27 PM, Ryan Moeller wrote:
On 10/9/20 6:22 PM, Alan Somers wrote:
This sounds like it might be a regression introduced by the OpenZFS
merge.
Have you compared vdev_geom.c in OpenZFS vs the old version?
-Alan
I don't think vdev_geom.c is involved, we're taking a wrong path in
z
On 10/9/20 6:22 PM, Alan Somers wrote:
This sounds like it might be a regression introduced by the OpenZFS merge.
Have you compared vdev_geom.c in OpenZFS vs the old version?
-Alan
I don't think vdev_geom.c is involved, we're taking a wrong path in
zvol_os.c because
it seems the volume is c
This sounds like it might be a regression introduced by the OpenZFS merge.
Have you compared vdev_geom.c in OpenZFS vs the old version?
-Alan
On Fri, Oct 9, 2020 at 3:48 PM Eric van Gyzen wrote:
> On 10/9/20 4:39 PM, Eric van Gyzen wrote:
> > Does this look familiar? I'm creating a zvol with vo
On 10/9/20 4:39 PM, Eric van Gyzen wrote:
Does this look familiar? I'm creating a zvol with volmode=dev, but some
geom code paths were taken. If this looks new, I'll provide more details.
primarycache=none also seems to be a factor. I can easily repro with:
zfs create -s -V 10G -o primaryca
Does this look familiar? I'm creating a zvol with volmode=dev, but some
geom code paths were taken. If this looks new, I'll provide more details.
Thanks in advance,
Eric
13.0-CURRENT r366500+84ccaf49083c-c272054 GENERIC
#8
#9 zvol_geom_bio_getattr (bp=0xf80376132900)
at /usr/src
