Dave Chinner wrote: On Mon, Jun 30, 2008 at 03:54:44PM +0530, Sagar Borikar wrote: After running my test for 20 min, when I check the fragmentation status of file system, I observe that it is severel
Yes, but you can run it in your test environment where you are reproducing this problem, right? No, at best it would only delay the problem (whatever it is). I don't have time to try to identify some
Dave Chinner wrote: On Wed, Jul 02, 2008 at 09:48:46AM +0530, Sagar Borikar wrote: Dave Chinner wrote: On Mon, Jun 30, 2008 at 03:54:44PM +0530, Sagar Borikar wrote: Sure - just like any other worklo
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. cheers.
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. -- Dave Chinner dchinner@xxxxxxxxx
Dave Chinner wrote: On Wed, Jul 02, 2008 at 04:13:11PM +1000, Nathan Scott wrote: On Wed, 2008-07-02 at 11:05 +0530, Sagar Borikar wrote: Unfortunately the architecture is customized mips for which t
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
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 wi
Ok, but that won't get to the bottom of the problem. It might alleviate it at best, but if I were shipping a product using xfs I'd want to know that it was properly solved. :) The tarball above shoul
Eric Sandeen wrote: Sagar Borikar wrote: Eric Sandeen wrote: 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 w
Repair finding corruption indicates a bug (or hardware problem) somewhere. As a long shot you might re-test with this patch in place: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;
The script is pretty straight forward: While [ 1 ] Do Cp -f $1 $2 Done Where I pass the first parameter as the 300+ MB file in one directory and $2 are is other directory. I run 30 instances of the s
Copying the same file to the same directory, or 30 different files to 30 different directories? Or the ame file to 30 different directories? If different directories what is the layout of the target
Copy is of the same file to 30 different directories and it is basically Here is the setup: It's a JBOD with Volume size 20 GB. The directories are empty and this is basically continuous copy of the
It would probably be best to try a 2.6.26 kernel from rawhide to be sure you're closest to the bleeding edge. I tested on 2.6.24.7-92.fc8 on x86_64, and I did this, specifically, in the root of a 30G
basically But It would probably be best to try a 2.6.26 kernel from rawhide to be sure you're closest to the bleeding edge. <Sagar> Sure Eric but I reran the test and I got similar errors with 2.6.24
It'd be great if you provided these actual scripts so we don't have to guess at what you're doing or work backwards from the repair output :) and nothing else of interest either? And how did you reco
Eric Sandeen wrote: Sagar Borikar wrote: Sagar Borikar wrote: Copy is of the same file to 30 different directories and it is basically overwrite. Here is the setup: It's a JBOD with Volume size 20 GB