On Tue, Nov 26, 2019 at 04:34:26PM -0800, Darrick J. Wong wrote: > On Tue, Nov 26, 2019 at 12:27:14PM -0800, Omar Sandoval wrote: > > Hello, > > > > The following reproducer results in a transaction log overrun warning > > for me: > > > > mkfs.xfs -f -r rtdev=/dev/vdc -d rtinherit=1 -m reflink=0 /dev/vdb > > mount -o rtdev=/dev/vdc /dev/vdb /mnt > > fallocate -l 4G /mnt/foo > > > > I've attached the full dmesg output. My guess at the problem is that the > > tr_write reservation used by xfs_alloc_file_space is not taking the realtime > > bitmap and realtime summary inodes into account (inode numbers 129 and 130 on > > this filesystem, which I do see in some of the log items). However, I'm not > > familiar enough with the XFS transaction guts to confidently fix this. Can > > someone please help me out? > > Hmm... > > /* > * In a write transaction we can allocate a maximum of 2 > * extents. This gives: > * the inode getting the new extents: inode size > * the inode's bmap btree: max depth * block size > * the agfs of the ags from which the extents are allocated: 2 * sector > * the superblock free block counter: sector size > * the allocation btrees: 2 exts * 2 trees * (2 * max depth - 1) * block size > * And the bmap_finish transaction can free bmap blocks in a join: > * the agfs of the ags containing the blocks: 2 * sector size > * the agfls of the ags containing the blocks: 2 * sector size > * the super block free block counter: sector size > * the allocation btrees: 2 exts * 2 trees * (2 * max depth - 1) * block size > */ > STATIC uint > xfs_calc_write_reservation(...); > > So this means that the rt allocator can burn through at most ... > 1 ext * 2 trees * (2 * maxdepth - 1) * blocksize > ... worth of log reservation as part of setting bits in the rtbitmap and > fiddling with the rtsummary information. > > Instead, 4GB of 4k rt extents == 1 million rtexts to mark in use, which > is 131072 bytes of rtbitmap to log, and *kaboom* there goes the 109K log > reservation. > > So I think you're right, and the fix is probably? to cap ralen further > in xfs_bmap_rtalloc(). Does the following patch fix it? > > --D Yup, that seems to fix it. Reported-and-tested-by: Omar Sandoval <osandov@xxxxxx> Thanks, Darrick!
