hi,
On Thu, Aug 09, 2001 at 09:07:41PM +0000, Detlef Vollmann wrote:
>
> Here are some results (all on linux-2.4.3):
>
> [root@dwarf tmp]# dd if=/dev/zero of=disk.xfs bs=1024 count=4851
> 4851+0 records in
> 4851+0 records out
> [root@dwarf tmp]# mkfs -t xfs disk.xfs
> meta-data=disk.xfs isize=256 agcount=1, agsize=4096
> blks
> data = bsize=4096 blocks=1212, imaxpct=25
> = sunit=0 swidth=0 blks, unwritten=0
> naming =version 2 bsize=4096
> log =internal log bsize=4096 blocks=1200
> realtime =none extsz=65536 blocks=0, rtextents=0
> Segmentation fault (core dumped)
>
> That core dump is absolutely reproducible, if the size of the file
> is big enough for the log (i.e. in the default case >= 4096K) but
> the remaining size is less than 13b).
>
I've just spent some time looking at this one and narrowed it down
to the point where it goes astray in the libxfs code (kernel code),
still need to figure out why. The failure happens trying to allocate
the root directory inode, we get into [lib]xfs_alloc_fix_freelist
which decides (wrongly, it seems) that we don't have enough space
for an allocation in the first (and only) AG, so kicks us out, but
without an error - in the context its called from, we shouldn't see
an error here. We eventually percolate back up to xfs_mkfs.c code
and since it didn't see an error, assumes the inode got allocated,
and dereferences a null pointer which shoulda had space alloc'd
lower down - mkfs.xfs takes a segv.
This problem doesn't seem to happen on IRIX, so will be fixable - it
will have to wait till Monday though.
cheers.
--
Nathan
|