Attached... again
> -----Original Message-----
> From: Steve Lord [mailto:lord@xxxxxxx]
> Sent: Thursday, March 11, 2004 10:09 AM
> To: Ranslam, Robert E
> Cc: Vinesh Christopher; Nathan Scott; linux-xfs@xxxxxxxxxxx
> Subject: Re: Bug : XFS - XSCALE "Directory Not Empty"
>
>
> Ranslam, Robert E wrote:
> > FYI:
> > Its also in the IXDP425 as well as the IQ80321. These are two
> > completely different boards the only thing in common really is the
> > Xscale core.
> >
> > Greg Ungerer posted a patch that I echoed. One problem is that is
> > appears to be and issue with a calculation. The comment seems to
> > indicate that the variable used should be 'namelen' but instead is
> > 'count'
>
> What patch? please forward it here.
>
> >
> > One thing to consider here - the x86 is Little endian. We
> are BE on the
> > IXP425
> >
>
>
> XFS runs fine on big endian hardware, that is where it was developed.
> This is more likely to be a problem in the gcc code generation on
> the xscale. It would not be the first time that xfs has pushed gcc
> over the edge. There is a lot of 64 bit stuff inside xfs, and we have
> seen gcc get very confused about what is in which register.
>
> Steve
>
-- Attached file included as plaintext by Ecartis --
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
Subject: Useful Update for XFS on the IXDP425
Date: Thu, 11 Mar 2004 08:55:34 -0800
Message-ID: <802FECEADA78854F8DD69950B138D8C9FFD7E9@xxxxxxxxxxxxxxxxxxxxxx>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Useful Update for XFS on the IXDP425
Thread-Index: AcQG+tXi4Qm94O14RUyEOgZMNXLjKQAjGBVA
From: "Ranslam, Robert E" <robert.e.ranslam@xxxxxxxxx>
To: <linux-xfs@xxxxxxxxxxx>
ALL;
The following patch was made by Greg Ungerer in checking out XFS on the
IXDP425. This fixed basic issues that could help other that may want to
use XFS on BE Xscale (ixp4xx) systems.
This was made against xfs v1.3.1, using 2.4.24 based linux from the
SnapGear 3.1 distro. Minimal testing was done on an IXDP425. Initial
reports indicate that does help.=20=20
- Dave Jiang at intel has reported some success with this patch on
80321 based systems
Most of the discussions regarding XFS in the last few days prompted this
post, but were made in the arm-linux mailing list. Here is a snippet of
the comments that Greg provided when sent the patch to as part of what
we were working on.
Note: sorry of this appears to be a repost. The initial email seems to
have gotten stuck getting to the mailing list
> I have a fix for the problem and I can reproduce with XFS on the
> IXDP425. With the attached patch applied I can do basic filesystem
> manipluations with no problems now (things like copies, deletes,
> etc).
>=20
> Not to say there isn't more problems but it seems to basically work
> reliably with this in place. And this is with all debug and asserts
> turned on, so that gives me a little bit more confidence.
>=20
> The patch uses a different method to calculate the size of the
> secondary directory structure. I think the original calculation
> is using the wrong struct size, I would need to consult XFS experts
> on the XFS mailing to confirm this fix.
--- xfs_dir2_sf.c.org 2004-02-17 14:56:16.000000000 +1000
+++ xfs_dir2_sf.c 2004-02-17 14:55:16.000000000 +1000
@@ -148,6 +148,7 @@
/*
* Calculate the new size, see if we should give up yet.
*/
+#if 0
size =3D XFS_DIR2_SF_HDR_SIZE(i8count) + /*
header */
count + /*
namelen */
count * (uint)sizeof(xfs_dir2_sf_off_t) + /*
offset */
@@ -155,6 +156,13 @@
(i8count ? /*
inumber */
(uint)sizeof(xfs_dir2_ino8_t) * count :
(uint)sizeof(xfs_dir2_ino4_t) * count);
+#endif
+ size =3D XFS_DIR2_SF_HDR_SIZE(i8count) /*
header */
+ + namelen
+ + (count * (sizeof(xfs_dir2_sf_entry_t) - 1))
+ - (count * (((i8count =3D=3D 0) ? 1 : 0) *
+ (sizeof(xfs_dir2_ino8_t) -
sizeof(xfs_dir2_ino4_t))));
+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
if (size > XFS_IFORK_DSIZE(dp))
return size; /* size value is a
failure */
}
|