headers
Adrian Bunk | 1 Aug 2004 21:02
Picon
Picon
Favicon

[2.6 patch] let 4KSTACKS depend on EXPERIMENTAL

On Fri, Jul 30, 2004 at 08:30:40AM +1000, Nathan Scott wrote:
>...
> Adrian wrote:
> > 2.6 is a stable kernel series used in production environments.
> > 
> > Regarding Linus' tree, it's IMHO the best solution to work around it 
> > this way until all issues are sorted out.
> 
> I'm not really convinced - the EXPERIMENTAL marking should
> be plenty of a deterent to folks in production environments.
> There are reports of stack overruns on other filesystems as
> well with 4KSTACKS, so doesn't seem worthwhile to me to do
> this just for XFS.

OK, below is a patch that only adds a dependency of 4KSTACKS on 
EXPERIMENTAL.

Considering that not all issues with 4kb stacks are currently corrected, 
this patch should IMHO go in 2.6.8 .

Signed-off-by: Adrian Bunk <bunk <at> fs.tum.de>

--- linux-2.6.8-rc2-mm1-full/arch/i386/Kconfig.old	2004-08-01 20:59:02.000000000 +0200
+++ linux-2.6.8-rc2-mm1-full/arch/i386/Kconfig	2004-08-01 20:59:46.000000000 +0200
 <at>  <at>  -1474,7 +1474,8  <at>  <at> 
 	  to solve problems without frame pointers.

 config 4KSTACKS
-	bool "Use 4Kb for kernel stacks instead of 8Kb"
+	bool "Use 4Kb for kernel stacks instead of 8Kb (EXPERIMENTAL)"
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nathan Scott | 2 Aug 2004 06:58
Picon
Favicon

Re: XFS: Oops in 2.4.26 and 2.4.27-rc4

On Sun, Aug 01, 2004 at 06:59:46PM +0200, Cahya Wirawan wrote:
> Hi,

Hi there,

> ...
> 2.4.26 and 2.4.27-rc4 get an Oops again. The server will not always
> crash, but it gets always an Oops at the same test (diotest4), and it is

Thanks for reporting it, here is the fix.

cheers.

--

-- 
Nathan

--- fs/xfs/linux-2.4/xfs_lrw.c.orig	2004-08-02 12:57:02.000000000 +1000
+++ fs/xfs/linux-2.4/xfs_lrw.c	2004-08-02 13:00:03.000000000 +1000
 <at>  <at>  -283,6 +283,8  <at>  <at> 
 	XFS_STATS_INC(xs_read_calls);

 	if (unlikely(ioflags & IO_ISDIRECT)) {
+		if ((ssize_t)size < 0)
+			return -XFS_ERROR(EINVAL);
 		if (((__psint_t)buf & BBMASK) ||
 		    (*offset & mp->m_blockmask) ||
 		    (size & mp->m_blockmask)) {
 <at>  <at>  -325,7 +327,8  <at>  <at> 
 	if (unlikely(ioflags & IO_ISDIRECT)) {
 		xfs_rw_enter_trace(XFS_DIORD_ENTER, &ip->i_iocore,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nathan Scott | 2 Aug 2004 07:13
Picon
Favicon

Re: 2.4.26 XFS file space reporting bug

On Fri, Jul 30, 2004 at 03:42:45PM -0700, Stormy Waters wrote:
> Hi people,
> 
> I think I found a bug in the 2.4.26 kernel,  I have a

I suspect this may be pilot error...

> logical partition (see below) that is partitioned for
> 20 gig's.  when i use df it reports it as 278MB. 
> Which is not even close to 20gb.  This Machine is

Did you run mkfs.xfs on this device right after it was
partitioned?  mkfs.xfs is only going to use as much as
the block layer says it can, so if the kernels in-core
partition table was out of whack, mkfs will be told an
out-of-date device size.

If this may be the case, try rebooting and then see if
mkfs.xfs sees the updated device size.  Also xfs_info /
"mkfs.xfs -fN" output would be useful here, along with
the contents of /proc/partitions.

cheers.

--

-- 
Nathan
Permalink | Reply | 0 comments |
headers
Nathan Scott | 2 Aug 2004 07:48
Picon
Favicon

Re: Possible XFS Corruption

On Mon, Aug 02, 2004 at 12:20:14PM +0800, Callan Tham wrote:
> On Mon, 2004-08-02 at 13:02, Nathan Scott wrote:
> > > I'm running a Gentoo-patched 2.6.7 kernel, and am experiencing possible
> > > XFS corruption on one of my partitions. I've included a sample of the
> > 
> > Is it reproducible with an unpatched kernel.org kernel?
> > 
> > thanks.
> 
> Hi Nathan,
> 
> Unfortunately, I am unable to test this with a vanilla kernel. However,

Oh?

> looking through the Gentoo patches, they did not touch any of the XFS
> code in a vanilla 2.6.7 kernel.

I would be surprised if they had.  A more likely source of
problems would be changes in the VM subsystem (XFS metadata
buffers are cached in the page cache).

> Is there any other way to diagnose this?

The failure you see is XFS reporting corruption in a directory
btree buffer which didn't have an appropriate magic number at
its start when read in from disk.  There's thousands of potential
reasons why that may have happened;  more often than not these
days its an error thats occured outside of XFS though, and XFS
is passing on the bad news.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nathan Scott | 2 Aug 2004 08:01
Picon
Favicon

Re: building xfsprogs (CVS): mmap.c:627: `MADV_NORMAL' undeclared

On Sat, Jul 31, 2004 at 08:37:59AM +0200, Bernhard Erdmann wrote:
> Nathan Scott wrote:
> 
> >Does your /usr/include/{bits,sys}/mman.h have those missing macros?
> >If so, what cpp macro is guarding them?  (mail me the file please)
> >If not, can you grep below /usr/include for them and let me know
> >which header defines them?  thanks.
> 
> Hi Nathan,
> 
> /usr/include/{bits,sys}/mman.h does not have a definition for 
> MADV_NORMAL. Instead, it is defined in /usr/include/asm/mman.h:

Does adding #include <asm/mman.h> (in xfsprogs/io/mmap.c) get
a working build for you or do you see subsequent errors too?

thanks.

--

-- 
Nathan
Permalink | Reply | 6 comments |
headers
bugzilla-daemon | 2 Aug 2004 07:00
Picon
Favicon

[Bug 272] xfs_force_shutdown in xfs_trans_cancel, part 2

http://oss.sgi.com/bugzilla/show_bug.cgi?id=272

------- Additional Comments From nathans <at> sgi.com  2004-01-08 22:00 PDT -------
> Tried with -d size=512g (additionally to the parameters used before) and the
> forced shutdown still happens.

Unfortunately, I don't have a 500g device to test with either ;) - but here's
a few more things worth testing:
- try mkfs without a version 2 log, does problem persist?
- try without any data stripe alignment options
- try with -dagsize=4g
- try with default inode size (256 bytes)..

and one-at-a-time, not all-at-once of course - if the problem goes away with
any one of these, then we have a big hint.  Also, does it only happen on top
of MD, or does the failure occur with those options on a regular disk too?

thanks.

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
Permalink | Reply | 0 comments |
headers
Tupshin Harper | 2 Aug 2004 13:20
Picon

xfs_repair fatal error in phase 6

I have an xfs partition that xfs_repair refuses to fix. It always dies
with the following:

Phase 6 - check inode connectivity...
        - resetting contents of realtime bitmap and summary inodes
        - ensuring existence of lost+found directory
        - traversing filesystem starting at / ...
rebuilding directory inode 128
empty data block 9 in directory inode 54540222: junking block

fatal error -- can't read block 8388608 for directory inode 54540222

I have tried dd'ing it to a file on another filesystem, and I get the
same results. I've tried running it a few times, and no change. Mount
doesn't recognize it.

For what it's woth, xfs_repair is running on a debian sid box on an
athlon xp cpu, and xfsprogs is from debian's xfsprogs_2.6.20-1
package.

Any suggestions?

-Tupshin
Permalink | Reply | 4 comments |
headers
Thimo E | 2 Aug 2004 15:44
Picon

XFS on Loop Device on Raid

Hello,

I am using XFS on an encrypted loop devices (loop-aes.sourceforge.net) and 
that runs on a software RAID 5 system.
Raid 5 doesn't support variable length transfers, normally xfs recognize it 
and disables them, but here xfs only sees a LOOP device, so variable length 
transfers are enabled and the filesystem gets corrupted in this case.

I found a solution on another list: 
http://mail.nl.linux.org/linux-crypto/2003-12/msg00024.html
This disables variable length transfers on all loop devices...

--- linux-2.4.22aa1r3/fs/xfs/linux/xfs_super.c.old      Fri Dec 12 08:19:49 
2003
+++ linux-2.4.22aa1r3/fs/xfs/linux/xfs_super.c  Fri Dec 12 08:20:58 2003
 <at>  <at>  -303,6 +303,7  <at>  <at> 

         switch (MAJOR(btp->pbr_dev)) {
         case MD_MAJOR:
+       case LOOP_MAJOR:
         case EVMS_MAJOR:
                 btp->pbr_flags = PBR_ALIGNED_ONLY;
                 break;

Is there another solution ? I have nothing found about this 
interoperability on sgi's website.

bye
   Thimo
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Sandeen | 2 Aug 2004 16:46
Picon
Favicon

Re: xfs_repair fatal error in phase 6

On Mon, 2 Aug 2004, Tupshin Harper wrote:

> I have an xfs partition that xfs_repair refuses to fix. It always dies
> with the following:
> 
> Phase 6 - check inode connectivity...
>         - resetting contents of realtime bitmap and summary inodes
>         - ensuring existence of lost+found directory
>         - traversing filesystem starting at / ...
> rebuilding directory inode 128
> empty data block 9 in directory inode 54540222: junking block
> 
> fatal error -- can't read block 8388608 for directory inode 54540222

maybe stracing xfs_repair would tell us what the real error was, although
the output will be quite large - the option "-etrace=read" might catch
only the read calls, and see if one fails.  Or, maybe some creative
printf debugging in phase6.c to find the underlying error.

> I have tried dd'ing it to a file on another filesystem, and I get the
> same results. I've tried running it a few times, and no change. Mount
> doesn't recognize it.

What does mount say?

-Eric
Permalink | Reply | 3 comments |
headers
アシストジャパン・コーポレーション | 2 Aug 2004 17:12
Picon

=?ISO-2022-JP?B?lqKPs5H4jUyNkIGmgUCBmpdMlryPl5dEdnOPl45xjVqQtnZzkGyNyIGaIIyDiMCCY4J1gmOUzJSEikqOboFJIA==?=


////////////dq[ <at> ɊÂ\L////////////
̃[AhX͑Mpł̂
zM]ȂiIvgAEgj͂ł肢܂B
 <at>  <at> http://www.delivery-mail.com/opt-out/tmmail.cgi

Mҁ <at> AVXgWpER[|[V
Z <at>  <at>  <at> 107-0052 <at> s`ԍ4-6-3
///////////////////////////////////////////////////




 <at>  <at> yA_gcuc≮ <at> w9800YENlbgxz
 <at>  <at>  <at>  <at>  <at>  <at>  <at>  <at>  <at>  <at>  <at>  <at>  <at>  <at>  <at>  <at>  <at>  <at>  <at>  <at>  <at>  <at>  <at>  <at>  <at>  <at>  <at>  <at>  <at>  <at>  <at> -VOL.1-


dddddddddd

cucArfIAA_gObYil̂jȂRRII
  <at>  <at> 
 <at>  <at> 荢ȃAȃA_giXCWOO~ψII

dddddddddd
 <at> 

 <at>  <at>   <at> jĩI[vjOZ[D]JÒII
 <at>  <at> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
\\\\\\\\\\\\\\\\\\\\\\\\
 <at>  <at> Pe <at> qZEuZVOL.1 <at> i10Zbgj
 <at>  <at>
(Continue reading)

Permalink | Reply | 0 comments |

Gmane