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?
Cheers,
Dave.
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.
http://sandeen.net/rhel5_xfs/xfs-2.6.25-for-rhel5-testing.tar.bz2
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?
Thanks
Sagar
-Eric
|