xfs
[Top] [All Lists]

Re: SGI XFS on ppc

To: linux-xfs@xxxxxxxxxxx
Subject: Re: SGI XFS on ppc
From: Thomas Graichen <news-innominate.list.sgi.xfs@xxxxxxxxxxxxx>
Date: 7 Aug 2000 19:58:02 GMT
Distribution: local
Organization: innominate AG, Berlin, Germany
References: <news-innominate.list.sgi.xfs@innominate.de> <200008071610.LAA21799@jen.americas.sgi.com>
Reply-to: Thomas Graichen <graichen@xxxxxxxxxxxxx>
Reply-to: thomas.graichen@xxxxxxxxxxxxx
Sender: owner-linux-xfs-announce@xxxxxxxxxxx
User-agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.16-local (i586))
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 ?

>> ok - now tried the fix for the ppc >32 shift bug and it now shifts
>> correctly and thus it now also mounts fine with the original xlatesb
>> with the shifts > 32 in it - so this problem is fixed now ... but
>> if i try to write to the filesystem it crashes with
>> 
>>   XFS assertion failed: indlen > 0, file: xfs_bmap.c, line:4904

> I do not think pagebuf tracing is going to help here (but thanks for
> capturing them).

> This assert is coming out of a very specific function.

>                                 indlen = (xfs_extlen_t)
>                                         xfs_bmap_worst_indlen(ip, alen);
>                                 ASSERT(indlen > 0);

> 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).

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/)

> 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-unused
 -Wno-parentheses -Wno-uninitialized -I./linux -I./pseudo-inc -I. -D_KERNEL 
-funsigned-char  -Wno-unknown-pragmas -DDEBUG -DXFSDEBUG  -c -o xfs_vnodeops.o 
xfs_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-unused
 -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 ?

t

-- 
thomas.graichen@xxxxxxxxxxxxx
technical director                                       innominate AG
clustering & security                                networking people
tel: +49.30.308806-13  fax: -77                   http://innominate.de

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