On Mon, 7 Aug 2000, Steve Lord wrote:
> An ASSERT actually means ASSERT that the statement is true, so it is
> supposed to die if it is fault. So
> ASSERT(indlen > 0);
>
> means panic is indlen <= 0.
>
> The ASSERT macro is coming from:
>
> fs/xfs/pseudo-inc/sys/debug.h
>
> > i think you meant "greater than zero" ? - if so it's indlen 5 and
> > alen 16 all time ... what exactly does the ASSERT do and where is
> > it defined ? (will install lxr as the next step to be able to
> > navigate through the code better - do you know it - if not it's
> > really worth a look: http://lxr.linux.no/)
>
> 5 and 16 are good values, maybe doing the comparison of an unsigned
> type being > 0 is the problem here! You could just remove the assert.
done - ok i looked a bit further now - i mounted the filesystem
can read the XFS file fine - can copy it to another file called
test for instance and also this contains what it should - i can
create an directory - works fine too - but if i copy for instance
/etc recursively into the xfs filesystem then i get after a few
files (about a dozen)
ASSERT(xfs_dir_ino_validate(mp, INT_GET(dep->inumber, ARCH_CONVERT)) == 0);
from within xfs_dir2_data_check in xfs_dir2_data.c and the
xfs_dir_ino_validate from xfs_dir_leaf.c says
Invalid inode number 0x0
before - any idea where to search further - there this inodenumber
of zero might come from ? - maybe as a sidenote: the etc dir is then
not visible by ls (so there's definitely something broken :-)
would it be of any help for you if i would send you an dd of the
filesystem (32mb, zeroed before, mkfs_xfs'ed and containing only
one testfile and then the copied /etc) to have a look at ?
> As for looking at the source code, we use cscope, which you can get from
> here:
>
> http://cscope.sourceforge.net/
>
> Understanding XFS is pretty much impossible without a source code browser.
ah - thanks i'll have a look at it
> > xfs_rw.c: In function `xfs_build_gap_list':
> > xfs_rw.c:662: warning: comparison is always true due to limited
> > range of data type
> >
> > which i do not see on the x86 from the same source - both times its
> > an
> >
> > ASSERT(count_fsb >= 0LL);
> >
> > any idea ?
>
> Yes, these look like unsigned types being compared against 0. It may
> be that stricter type checking is happening on the ppc platform.
maybe it's the difference egcs (x86 redhat) - gcc 2.95.2 (ppc) - but
so far these asserts are ueseless then (?)
t
--
thomas.graichen@xxxxxxxxxxxxx
technical director innominate AG
clustering & security networking people
tel: +49.30.308806-13 fax: -77 http://innominate.de
|