Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 227331 - xfs on large volumes with 4k-stack kernel crashes
Summary: xfs on large volumes with 4k-stack kernel crashes
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 5
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Eric Sandeen
QA Contact: Brian Brock
: 240077 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2007-02-05 11:39 UTC by Darko Veberic
Modified: 2007-11-30 22:11 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-09-17 19:41:58 UTC

Attachments (Terms of Use)
Panic backtrace of XFS stack overflow (deleted)
2007-06-12 14:34 UTC, paul.knowles
no flags Details

Description Darko Veberic 2007-02-05 11:39:20 UTC
Description of problem:
  kernel crashes during heavy load on large (>1TB md) xfs valumes when the
  kernel stack size is only 4k

Version-Release number of selected component (if applicable):

How reproducible:
  once or two times per week, on heavy load

Steps to Reproduce:
1. heavy load from several sources: httpd, nfs, scp, dd
Actual results:
  xfs related kernel panic, or simply freeze

Expected results:
  ??? work without flaws, maybe???

Additional info:
  i have an impression this is a known issue that xfs and 4k do not mix anymore.
you should decide to either (1) switch to default 8k or (2) remove xfs support
since a lot of people is losing data (one of the crashes required complete
format since xfs_repair was segfaulting on such mess)...

Comment 1 Dave Jones 2007-02-13 16:44:25 UTC
we need to see the traces really to be able to do anything with this.

Comment 2 Eric Sandeen 2007-02-13 17:31:23 UTC
Yep, stacking xfs over MD and nfs and ... is going to push the limits of the 4k

sgi guys have done a little work to try to trim down stack usage but adding IO
layers will help add it up again.

Seeing traces would at least identify the particular callchain that you ran into....

a couple of thoughts on making this more robust/safe for fedora users...

perhaps we could refuse to even load the xfs module into a 4kstacks kernel
unless loaded with an "i_want_to_live_on_the_edge" module option or somesuch...

also, Russell has suggested the possibility of making stack size a boot time
parameter; but I bet that will go over like a ton of bricks upstream.


Comment 3 Eric Sandeen 2007-03-08 15:59:36 UTC
We need more info on how this actually failed, or we can't even begin to address it.

Backtraces please?

Comment 4 paul.knowles 2007-06-12 14:34:38 UTC
Created attachment 156797 [details]
Panic backtrace of XFS stack overflow

Kernel panic trace from a Hyperthreaded P4 running 2.6.20-1.2316.fc5smp.
The system provides NFS access to a 1.3T XFS volume on software raid 5.
The machine is also used to analyze the data written to the discs.  
Under heavy load (two memory intensive processes) plus a constant 
(~1Mb/s) write rate to the discs, the machine falls over after some
unpredictable time between a few hours to a few days.

Comment 5 Eric Sandeen 2007-06-12 14:51:58 UTC
Thanks, I'll look over that stack backtrace.  Interestingly, there seems to be
no xfs functions in the stack which caused the initial warning.  FWIW in the
past I think I've seen the stack overflow warning itself cause the *actual*
stack overflow...

Honestly, xfs + any complex IO stack will have a very hard time fitting into 4k.
 SGI has been chipping away at the problem, but the low-hanging fruit has all
been found... If this is critical to your workflow, I would seriously suggest
using an x86_64 box for the purpose, which has 8k stacks (yes, they must share
that 8k with  irqs, but in my experience it's been a much more robust combination).

I'll look over those stack traces & see if anything interesting pops out, though.


Comment 6 Eric Sandeen 2007-06-12 14:55:31 UTC
ah, I think the backtrace has the stack warning intermingled with the subsequent
oops, it will take a bit to untangle it.  (but yeah, xfs is in there) :)

Comment 7 Eric Sandeen 2007-08-09 19:42:40 UTC
*** Bug 240077 has been marked as a duplicate of this bug. ***

Comment 8 Eric Sandeen 2007-09-11 19:19:33 UTC
The other fun thing here is that the stack warning *itself* tends to push the
stack over the edge, if you're close enough to make it go off.  Neat, eh?

I've sent something upstream to see about addressing this, but it's not been
accepted yet.


Comment 9 Eric Sandeen 2007-09-17 19:41:58 UTC
I'm going to close this as "UPSTREAM" - I'm never going to fully resolve this
bug, though I do occasionally try to whack down the worst offenders if I can. 
Realistically, the problem is known, and it's going to take upstream work (from
sgi, on xfs, and maybe from core kernel work to ease stack for stacked IO).

For now, as of fedora devel today, xfs is reasonably functional on 4k stacks,
esp. if you don't put it over a volume manager....

Note You need to log in before you can comment on or make changes to this bug.