Re: current transaction too big to flush

[Dima Veselov <kab00m%lich.phys.spbu.ru@localhost>]

Dear Jaromir,

It is 8.1-STABLE as of Jun, 10. It was happening on all
8 since RC1.

dk0 is 3Tb and I believe it is happening on this device.

[root@ssd ~]$ tunefs -N /dev/dk0
tunefs: tuning /dev/rdk0
tunefs: current settings of /dev/rdk0
        maximum contiguous block count 2
        maximum blocks per file in a cylinder group 4096
        minimum percentage of free space 5%
        optimization preference: time
        average file size: 16384
        expected number of files per directory: 64
        journal log file location: in filesystem
        journal log file size: 64MB (67108864 bytes)
        journal log flags:
        quotasdisabled
tunefs: no changes made

On 18.06.2019 9:36, Jaromír Doleček wrote:
> Which version of NetBSD is this? Can you also post tunefs -N output
> for the filesystem?
>
> Jaromir
>
> Le mar. 18 juin 2019 à 02:24, Dima Veselov <kab00m%lich.phys.spbu.ru@localhost> a écrit :
> > Hello,
> >
> > Maybe I need to create PR, but here might be a
> > person already met the situation of kernel panic
> > on big file operation. When I try to delete several
> > files (from 1 to 8 Gb at once) from net/transmission
> > interface I get kernel panic like this:
> >
> > panic: wapbl_flush: current transaction too big to flush
> > cpu0: Begin traceback...
> > vpanic() at netbsd:vpanic+0x15d
> > snprintf() at netbsd:snprintf
> > wapbl_stop() at netbsd:wapbl_stop
> > wapbl_begin() at netbsd:wapbl_begin+0x5b
> > ufs_inactive() at netbsd:ufs_inactive+0x13a
> > VOP_INACTIVE() at netbsd:VOP_INACTIVE+0x4c
> > vrelel() at netbsd:vrelel+0x168
> > ufs_remove() at netbsd:ufs_remove+0xab
> > VOP_REMOVE() at netbsd:VOP_REMOVE+0x50
> > do_sys_unlinkat.isra.5() at netbsd:do_sys_unlinkat.isra.5+0x1eb
> > syscall() at netbsd:syscall+0x1ec
> > --- syscall (number 10) ---
> > 7887406fb53a:
> > cpu0: End traceback...
> >
> > I also have question about dumping: kernel can't
> > do dump on panic:
> >
> > dumping to dev 168,2 (offset=4278362, size=515454):
> > dump device bad
> >
> > Why it is bad if it work as a swap normally?
> >
> > [root@ssd ~]$ swapctl  -l
> > Device      512-blocks     Used    Avail Capacity  Priority
> > /dev/dk2       8401995        0  8401995     0%    0
> > [root@ssd ~]$ ls -la /dev/dk2
> > brw-r-----  1 root  operator  168, 2 Apr 19  2018 /dev/dk2