>
> 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.
In theory it should be real data at this point, xfs_free_file_space calls
xfs_inval_cached_pages before it calls xfs_zero_remaining_bytes, this will
end up in pagebuf_flushinval which should convert all extents in the
range specified to real disk space.....
Maybe we are not doing this correctly.
Steve
>
> 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
> -----------------------------------------------------
|