[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:


> 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


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
>  -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
> xfs_vnodeops.c: In function `xfs_allocstore':
> xfs_vnodeops.c:5056: warning: comparison is always true due to limited range 
> 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
>  -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.
> xfs_rw.c: In function `xfs_build_gap_list':
> xfs_rw.c:662: warning: comparison is always true due to limited range of data
> 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.


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