Re: current transaction too big to flush

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

Greetings,

the problem is still there and I even have a single file
which can not be deleted via standard rm command
causing kernel panic. What can be done there? Current
situation make WAPBL filesystem unusable. I also can not
increase log space.

Is that real that 3Gb file deletion take 64Mb of log space?

18.06.2019 11:14, Dima Veselov пишет:

> 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