Re: current transaction too big to flush

[Jaromír Doleček <jaromir.dolecek%gmail.com@localhost>]

When I was last working on WAPBL, I was specifically testing this
scenario (deleting big files), and never had problems.

Fragmentation shouldn't really be the problem - FFS by default
allocates block in the same cylinder group for same file. Unless of
course you were close to full filesystem when the files were created.

What's block size do you use on the filesystem?

Jaromir

Le lun. 24 juin 2019 à 15:39, Dima Veselov <kab00m%lich.phys.spbu.ru@localhost> a écrit :
>
> Hi,
>
> this maybe caused by nature of the file. All these files were
> created with torrents, which may made them very
> defragmented.
>
> 24.06.2019 13:05, David Brownlee wrote:
> >> 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?
> >
> > Hi - I have a few largish filesystems mounted with log and have
> > deleted multi GB files without problems. I did make them with 64K
> > bsize, which may have mitigated matters?
> >
> > #dumpfs /dev/rdk5|head
> > file system: /dev/rdk5
> > format  FFSv2
> > endian  little-endian
> > location 65536  (-b 128)
> > magic   19540119        time    Mon Jun 24 09:46:53 2019
> > superblock location     65536   id      [ 5aff4cab 591e6965 ]
> > cylgrp  dynamic inodes  FFSv2   sblock  FFSv2   fslevel 5
> > nbfree  6262856 ndir    1816222 nifree  175315127       nffree  928895
> > ncg     1749    size    732495616       blocks  726786860
> > bsize   65536   shift   16      mask    0xffff0000