[Top] [All Lists]

Re: Xfs Access to block zero exception and system crash

To: Eric Sandeen <sandeen@xxxxxxxxxxx>
Subject: Re: Xfs Access to block zero exception and system crash
From: Sagar Borikar <sagar_borikar@xxxxxxxxxxxxxx>
Date: Thu, 03 Jul 2008 10:44:59 +0530
Cc: Nathan Scott <nscott@xxxxxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <486C4F89.9030009@xxxxxxxxxxx>
Organization: PMC Sierra Inc
References: <20080628000516.GD29319@disturbed> <340C71CD25A7EB49BFA81AE8C8392667028A1CA7@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20080629215647.GJ29319@disturbed> <20080630034112.055CF18904C4@xxxxxxxxxxxxxxxxxxxxxxxxxx> <4868B46C.9000200@xxxxxxxxxxxxxx> <20080701064437.GR29319@disturbed> <486B01A6.4030104@xxxxxxxxxxxxxx> <20080702051337.GX29319@disturbed> <486B13AD.2010500@xxxxxxxxxxxxxx> <1214979191.6025.22.camel@xxxxxxxxxxxxxxxxxx> <20080702065652.GS14251@xxxxxxxxxxxxxxxxxxxxx> <486B6062.6040201@xxxxxxxxxxxxxx> <486C4F89.9030009@xxxxxxxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Thunderbird (X11/20080421)

Eric Sandeen wrote:
Sagar Borikar wrote:
Dave Chinner wrote:
On Wed, Jul 02, 2008 at 04:13:11PM +1000, Nathan Scott wrote:

You can always try the reverse - replace fs/xfs from your mips build
tree with the one from the current/a recent kernel.  Theres very few
changes in the surrounding kernel code that xfs needs.
Eric should be able to comment on the pitfalls in doing this having
tried to backport a 2.6.25 fs/xfs to a 2.6.18 RHEL kernel. Eric -
any comments?


Eric, Could you please let me know about bits and pieces that we need to remember while back porting xfs to 2.6.18?
If you share patches which takes care of it, that would be great.


should be pretty close.  It was quick 'n' dirty and it has some warts
but would give an idea of what backporting was done (see patches/ and
the associated quilt series; quilt push -a to apply them all)
Thanks a lot Eric. I'll go through it .I am actually trying another option of regularly defragmenting the file system under stress.
I wanted to understand couple of things for using xfs_fsr utility:

1. What should be the state of filesystem when I am running xfs_fsr. Ideally we should stop all io before running defragmentation. 2. How effective is the utility when ran on highly fragmented file system? I saw that if filesystem is 99.89% fragmented, the recovery is very slow. It took around 25 min to clean up 100GB JBOD volume and after that system was fragmented to 82%. So I was confused on how exactly the fragmentation works.
Any pointers on probable optimum use of xfs_fsr?
3. Any precautions I need to take when working with that from data consistency, robustness point of view? Any disadvantages?
4. Any threshold for starting the defragmentation on xfs?


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