xfs
[Top] [All Lists]

XFS_IOC_RESVSP & XFS_IOC_UNRESVSP

To: linux-xfs@xxxxxxxxxxx
Subject: XFS_IOC_RESVSP & XFS_IOC_UNRESVSP
From: Daniel Moore <dxm@xxxxxxxxxxxxxxxxxxxxxxxx>
Date: Thu, 24 Aug 2000 14:57:23 +1000
Sender: owner-linux-xfs@xxxxxxxxxxx
Still banging my head against this one (pv 799616).

Can anyone tell me how xfs_zero_remaining_bytes in xfs_vnodeops.c
can assert that xfs_bmapi doesn't return a delayed allocation
extent? 

        ASSERT(imap.br_startblock != DELAYSTARTBLOCK);

I've got a completely repeatable test case where this ASSERT
fails because xfs_bmapi returns a delayed extent.

Amusing this is, if you sleep for a tiny bit before doing the
unreserve that trips the assert, the pagebuf page_cleaner_daemon
comes along and converts it to a real extent and everything goes
fine.

The extent in question is written with dd, so there's no reason
why it _shouldn't_ be delayed. But when the unreserve happens,
there's the assertion that it isn't.

Anyone got any ideas?


There's an example fsstress invocation in the pv, or this:

#!/bin/sh 

make iprobe

_t()
{
        echo "$*" | isms/slinx-xfs/cmd/xfs/stress/src/alloc \
                -n -f /mnt/arch0/fish
}

mkfs -t xfs -f /dev/hda6 || exit 1
mount -t xfs /dev/hda6 /mnt/arch0 || exit 1

_t r 552894 105778
_t u 359577 318758
dd if=/dev/zero of=/mnt/arch0/fish bs=1 seek=592400 count=10466
# sleep 1 here and it'll work, otherwise the next line trips the ASSERT
_t u 634008 225946

umount /dev/hda6


-----------------------------------------------------
 Daniel Moore                  dxm@xxxxxxx
 R&D Software Engineer         Phone: +61-3-98348209
 SGI Performance Tools Group   Fax:   +61-3-98132378
-----------------------------------------------------


<Prev in Thread] Current Thread [Next in Thread>