xfs
[Top] [All Lists]

Re: SGI XFS on ppc

To: Thomas Graichen <graichen@xxxxxxxxxxxxx>, thomas.graichen@xxxxxxxxxxxxx
Subject: Re: SGI XFS on ppc
From: Steve Lord <lord@xxxxxxx>
Date: Mon, 07 Aug 2000 15:16:46 -0500
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: Message from Thomas Graichen <news-innominate.list.sgi.xfs@xxxxxxxxxxxxx> of "07 Aug 2000 19:58:02 GMT." <news2mail-8mn4ca$8nb$2@xxxxxxxxxxxxxxxxxxxxxx>
Sender: owner-linux-xfs-announce@xxxxxxxxxxx
> Steve Lord <lord@xxxxxxx> wrote:
> >> Thomas Graichen <graichen@xxxxxxxxxxxxx> wrote:
> 
> > In theory this should be true - it is always possible there is a glitch
> > lurking out there somewhere. One issue might be how a specific architecture
> > lays out a structure in memory. We reply on the compiler to generate the
> > correct layout for on disk structures. For example, if you run
> 
> > # gdb modules/xfs.o
> 
> > you can do things like
> 
> > (gdb) print sizeof(xfs_sb_t)
> > $1 = 200
> 
> > This and other on disk structures need to come out the same size on
> > the ppc for things to work.
> 
> this one is the same for x86 and ppc - can you just write down the
> names of some other structures of interest - so that i may compare
> their sizes ?

Glurk! I will have to go dig around a little for that.... but since it
was my idea......



> 
> > Instead of just calling ASSERT here, put in an explicit check for
> > indlen being less than zero, if it is then print out indlen and
> > alen, they are both unsigned 32 bit quantities (which makes the
> > assert somewhat bogus). However, indlen should not be huge, it is
> > supposed to be the worst case calculation of the amount of disk
> > space to hold alen of data (worst case metadata overhead).
> 

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.

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.

> 
> > Adding printk calls to xfs_bmap_worst_indlen would be the next step - it
> > is in xfs_bmap.c. Something in this function is probably the cause,
> > maybe mp->m_bmap_dmxr[0] or [1] is incorrectly initialized. Printing
> > out XFS_BM_MAXLEVELS(mp, XFS_DATA_FORK) would be useful too.
> 
> will do that as the next step - btw. i just updated to the current
> cvs code and while recompiling it i noticed the following:
> 
> gcc -D__KERNEL__ -I/usr/src/xfs/linux/include -Wall -Wstrict-prototypes -O2 -
fomit-frame-pointer -D__powerpc__ -fsigned-char -msoft-float -pipe -ffixed-r2 -
Wno-uninitialized -mmultiple -mstring -fno-strict-aliasing -DMODULE -g3 -Wno-un
used
>  -Wno-parentheses -Wno-uninitialized -I./linux -I./pseudo-inc -I. -D_KERNEL -
funsigned-char  -Wno-unknown-pragmas -DDEBUG -DXFSDEBUG  -c -o xfs_vnodeops.o x
fs_vnodeops.c
> xfs_vnodeops.c: In function `xfs_allocstore':
> xfs_vnodeops.c:5056: warning: comparison is always true due to limited range 
of
> data type
> gcc -D__KERNEL__ -I/usr/src/xfs/linux/include -Wall -Wstrict-prototypes -O2 -
fomit-frame-pointer -D__powerpc__ -fsigned-char -msoft-float -pipe -ffixed-r2 -
Wno-uninitialized -mmultiple -mstring -fno-strict-aliasing -DMODULE -g3 -Wno-un
used
>  -Wno-parentheses -Wno-uninitialized -I./linux -I./pseudo-inc -I. -D_KERNEL -
funsigned-char  -Wno-unknown-pragmas -DDEBUG -DXFSDEBUG  -c -o xfs_rw.o xfs_rw.
c
> 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.

Steve



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