In message <[EMAIL PROTECTED]>, Matthew Dillon writes:
> There must still be a bug in there somewhere, unrelated to softupdates.
>
> Try turning off the vfs.ffs.doreallocblks via sysctl and see if that
> stops the crashes, that will help narrow down where to search for the
> problem.
I think I've found it. Here's an easy way to repeat the problem to
start with:
mount_mfs -T fd1440 none /mnt
cd /mnt
dd if=/dev/zero bs=4k of=test seek=1036 count=1
dd if=/dev/zero bs=4k of=test1 count=1
dd if=/dev/zero bs=4k of=test2
rm test1
dd if=/dev/zero bs=4k of=test seek=8000 count=1
echo > test
It looks as if the problem is in ffs_balloc(), and occurs as follows:
- ffs_balloc() is asked to allocate a doubly indirect block.
- The first-level indirection block already exists
- The second-level indirection block does not exist, but is
successfully allocated.
- This block is linked into the first-level indirection block by
the line:
bap[indirs[i - 1].in_off] = nb;
- Allocation of the data block fails.
- All allocated blocks are then released, but there is still
a link in the first-level indirection block to what is
now a free block.
The fix should be relatively straightforward - either the code should
avoid linking new indirection blocks until all allocations succeed,
or it should back out the changes on failure.
Ian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
