Re: another crash and going forward with zfs

2023-04-24 Thread Mateusz Guzik
On 4/18/23, Pawel Jakub Dawidek wrote: > On 4/18/23 05:14, Mateusz Guzik wrote: >> On 4/17/23, Pawel Jakub Dawidek wrote: >>> Correct me if I'm wrong, but from my understanding there were zero >>> problems with block cloning when it wasn't in use or now disabled. >>> >>> The reason I've introduce

Re: another crash and going forward with zfs

2023-04-18 Thread Juraj Lutter
> On 18 Apr 2023, at 09:46, Martin Matuska wrote: > > Btw. I am open for setting up a pre-merge stress testing > > I will check out if I can use the hourly-billed amd64 and arm64 cloud boxes > at Hetzner with FreeBSD. > Otherwise there are monthly-billed as well. I can provide a bhyve VM on

Re: another crash and going forward with zfs

2023-04-18 Thread Martin Matuska
Btw. I am open for setting up a pre-merge stress testing I will check out if I can use the hourly-billed amd64 and arm64 cloud boxes at Hetzner with FreeBSD. Otherwise there are monthly-billed as well. Cheers, mm On 17. 4. 2023 22:14, Mateusz Guzik wrote: On 4/17/23, Pawel Jakub Dawidek wro

Re: another crash and going forward with zfs

2023-04-18 Thread Martin Matuska
On 18. 4. 2023 3:16, Warner Losh wrote: Related question: what zfs branch is stable/14 going to track? With 13 it was whatever the next stable branch was. Warner FreeBSD 14.0 is about to track soon-to-be-branched OpenZFS 2.2

Re: another crash and going forward with zfs

2023-04-17 Thread Warner Losh
On Mon, Apr 17, 2023, 5:37 PM Rick Macklem wrote: > On Mon, Apr 17, 2023 at 4:29 PM Cy Schubert > wrote: > > > > In message , Pawel > Jakub > > Dawi > > dek writes: > > > On 4/18/23 05:14, Mateusz Guzik wrote: > > > > On 4/17/23, Pawel Jakub Dawidek wrote: > > > >> Correct me if I'm wrong, but

Re: another crash and going forward with zfs

2023-04-17 Thread Rick Macklem
On Mon, Apr 17, 2023 at 4:29 PM Cy Schubert wrote: > > In message , Pawel Jakub > Dawi > dek writes: > > On 4/18/23 05:14, Mateusz Guzik wrote: > > > On 4/17/23, Pawel Jakub Dawidek wrote: > > >> Correct me if I'm wrong, but from my understanding there were zero > > >> problems with block cloning

Re: another crash and going forward with zfs

2023-04-17 Thread Cy Schubert
In message , Pawel Jakub Dawi dek writes: > On 4/18/23 05:14, Mateusz Guzik wrote: > > On 4/17/23, Pawel Jakub Dawidek wrote: > >> Correct me if I'm wrong, but from my understanding there were zero > >> problems with block cloning when it wasn't in use or now disabled. > >> > >> The reason I've i

Re: another crash and going forward with zfs

2023-04-17 Thread Pawel Jakub Dawidek
On 4/18/23 05:14, Mateusz Guzik wrote: On 4/17/23, Pawel Jakub Dawidek wrote: Correct me if I'm wrong, but from my understanding there were zero problems with block cloning when it wasn't in use or now disabled. The reason I've introduced vfs.zfs.bclone_enabled sysctl, was to exactly avoid mes

Re: another crash and going forward with zfs

2023-04-17 Thread Mateusz Guzik
On 4/17/23, Pawel Jakub Dawidek wrote: > On 4/18/23 03:51, Mateusz Guzik wrote: >> After bugfixes got committed I decided to zpool upgrade and sysctl >> vfs.zfs.bclone_enabled=1 vs poudriere for testing purposes. I very >> quickly got a new crash: >> >> panic: VERIFY(arc_released(db->db_buf)) fail

Re: another crash and going forward with zfs

2023-04-17 Thread Pawel Jakub Dawidek
On 4/18/23 03:51, Mateusz Guzik wrote: After bugfixes got committed I decided to zpool upgrade and sysctl vfs.zfs.bclone_enabled=1 vs poudriere for testing purposes. I very quickly got a new crash: panic: VERIFY(arc_released(db->db_buf)) failed cpuid = 9 time = 1681755046 KDB: stack backtrace:

another crash and going forward with zfs

2023-04-17 Thread Mateusz Guzik
After bugfixes got committed I decided to zpool upgrade and sysctl vfs.zfs.bclone_enabled=1 vs poudriere for testing purposes. I very quickly got a new crash: panic: VERIFY(arc_released(db->db_buf)) failed cpuid = 9 time = 1681755046 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_