Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*xfs_fsr\,\s+performance\s+related\s+tweaks\s*$/: 38 ]

Total 38 documents matching your query.

1. Re: xfs_fsr, performance related tweaks (score: 1)
Author: David Chinner <dgc@xxxxxxx>
Date: Mon, 2 Jul 2007 08:43:39 +1000
That could be easily done with command line options, I think. Define the minimum extent length or number of extents we want files to have and ignore those that are outside that criteria. Cheers, Dave
/archives/xfs/2007-07/msg00001.html (9,372 bytes)

2. Re: xfs_fsr, performance related tweaks (score: 1)
Author: David Chinner <dgc@xxxxxxx>
Date: Mon, 2 Jul 2007 08:43:39 +1000
That could be easily done with command line options, I think. Define the minimum extent length or number of extents we want files to have and ignore those that are outside that criteria. Cheers, Dave
/archives/xfs/2007-07/msg00364.html (9,372 bytes)

3. xfs_fsr, performance related tweaks (score: 1)
Author: Just Marc <marc@xxxxxxxxx>
Date: Thu, 28 Jun 2007 13:47:39 +0100
I'm using fsr extensively. I noticed two things: 1. in xfs_fsr.c: if (fsx.fsx_xflags & XFS_XFLAG_NODEFRAG) { if (vflag) fsrprintf(_("%s: marked as don't defrag, ignoring\n"), fname); return(0); } Th
/archives/xfs/2007-06/msg00415.html (10,652 bytes)

4. xfs_fsr, performance related tweaks (score: 1)
Author: Just Marc <marc@xxxxxxxxx>
Date: Thu, 28 Jun 2007 13:47:49 +0100
I'm using fsr extensively. I noticed two things: 1. in xfs_fsr.c: if (fsx.fsx_xflags & XFS_XFLAG_NODEFRAG) { if (vflag) fsrprintf(_("%s: marked as don't defrag, ignoring\n"), fname); return(0); } Th
/archives/xfs/2007-06/msg00416.html (11,779 bytes)

5. Re: xfs_fsr, performance related tweaks (score: 1)
Author: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Thu, 28 Jun 2007 16:38:56 -0400
But... that file could drastically change in the future, no? Just because it can't be improved now doesn't necessarily mean that it should never be revisited on subsequent runs, does it? -Eric
/archives/xfs/2007-06/msg00431.html (9,393 bytes)

6. Re: xfs_fsr, performance related tweaks (score: 1)
Author: Andi Kleen <andi@xxxxxxxxxxxxxx>
Date: 29 Jun 2007 02:52:57 +0200
I guess one could define an additional dont-defrag (or perhaps rather already-defrag) flag that is always cleared when the file changes. That could be safely set here. But then I'm not sure it would
/archives/xfs/2007-06/msg00438.html (10,208 bytes)

7. Re: xfs_fsr, performance related tweaks (score: 1)
Author: Nathan Scott <nscott@xxxxxxxxxx>
Date: Fri, 29 Jun 2007 10:12:09 +1000
Just call the ioctl directly - fsr is already doing this in a bunch of places (even has a call to XFS_IOC_FSSETXATTR already, elsewhere). The xfsctl wrapper is just to give some tools platform indepe
/archives/xfs/2007-06/msg00439.html (9,220 bytes)

8. Re: xfs_fsr, performance related tweaks (score: 1)
Author: Just Marc <marc@xxxxxxxxx>
Date: Fri, 29 Jun 2007 07:21:58 +0100
Hi Eric, In my particular case, and I'm sure for many other people, files that are stored never change again until they deleted. I hinted that there could be a command line switch to turn this functi
/archives/xfs/2007-06/msg00451.html (10,639 bytes)

9. Re: xfs_fsr, performance related tweaks (score: 1)
Author: "Barry Naujok" <bnaujok@xxxxxxx>
Date: Fri, 29 Jun 2007 16:41:22 +1000
On Fri, 29 Jun 2007 16:21:58 +1000, Just Marc <marc@xxxxxxxxx> wrote: Hi Eric, In my particular case, and I'm sure for many other people, files that are stored never change again until they deleted.
/archives/xfs/2007-06/msg00453.html (10,562 bytes)

10. Re: xfs_fsr, performance related tweaks (score: 1)
Author: Just Marc <marc@xxxxxxxxx>
Date: Fri, 29 Jun 2007 07:31:04 +0100
Hi Nathan, Andy, I tried calling the ioctl of course, it does accept a path (also in the example in which it is used) but it returned EINVAL, I'll try again. I had this in mind but thought not to bri
/archives/xfs/2007-06/msg00454.html (10,824 bytes)

11. Re: xfs_fsr, performance related tweaks (score: 1)
Author: Just Marc <marc@xxxxxxxxx>
Date: Fri, 29 Jun 2007 07:41:15 +0100
Barry Naujok wrote: On Fri, 29 Jun 2007 16:21:58 +1000, Just Marc <marc@xxxxxxxxx> wrote: Hi Eric, In my particular case, and I'm sure for many other people, files that are stored never change again
/archives/xfs/2007-06/msg00455.html (11,087 bytes)

12. Re: xfs_fsr, performance related tweaks (score: 1)
Author: David Chinner <dgc@xxxxxxx>
Date: Fri, 29 Jun 2007 17:08:14 +1000
So walk the filesystem with a script that queries the number of extents in each file, and if they have a single extent then run the xfs_io on them. Cheers, Dave. -- Dave Chinner Principal Engineer SG
/archives/xfs/2007-06/msg00458.html (10,099 bytes)

13. Re: xfs_fsr, performance related tweaks (score: 1)
Author: Just Marc <marc@xxxxxxxxx>
Date: Fri, 29 Jun 2007 08:16:28 +0100
In my first post I already said something like that can be done but it's just an ugly hack. Don't you think it would best be handled cleanly and correctly by fsr itself? David Chinner wrote: On Fri,
/archives/xfs/2007-06/msg00459.html (10,726 bytes)

14. Re: xfs_fsr, performance related tweaks (score: 1)
Author: Nathan Scott <nscott@xxxxxxxxxx>
Date: Fri, 29 Jun 2007 17:33:55 +1000
As I said earlier, fsr already issues the ioctl you're concerned about using - I'm not sure what the issue is there - if you need to do a setxattr, Just Do It. cheers. -- Nathan
/archives/xfs/2007-06/msg00460.html (10,158 bytes)

15. Re: xfs_fsr, performance related tweaks (score: 1)
Author: David Chinner <dgc@xxxxxxx>
Date: Fri, 29 Jun 2007 17:41:14 +1000
No, I don't - if you want files not to be defragmented, then you have to set the flags yourself in some way. You have a specific need that can be solved by some scripting to describe your defrag/no d
/archives/xfs/2007-06/msg00462.html (10,059 bytes)

16. Re: xfs_fsr, performance related tweaks (score: 1)
Author: Just Marc <marc@xxxxxxxxx>
Date: Fri, 29 Jun 2007 08:39:02 +0100
I agree with you. But what about files it works on, heavily, then decides they can't be defragged further? then it tries to defrag them again and again and again. And that's the end of my story. Davi
/archives/xfs/2007-06/msg00464.html (10,054 bytes)

17. Re: xfs_fsr, performance related tweaks (score: 1)
Author: Andi Kleen <andi@xxxxxxxxxxxxxx>
Date: Fri, 29 Jun 2007 10:13:57 +0200
It might be better to investigate why XFS does such a poor job for your workload in the first case. Unless the file systems are always nearly full or you have a lot of holes it shouldn't fragment th
/archives/xfs/2007-06/msg00467.html (9,425 bytes)

18. Re: xfs_fsr, performance related tweaks (score: 1)
Author: Just Marc <marc@xxxxxxxxx>
Date: Fri, 29 Jun 2007 09:23:04 +0100
Many files are being added concurrently, 24/7. You might have hit the nail on the head, some of the files it was not able to improve are on filesystems that are almost full. As the patch is done anyw
/archives/xfs/2007-06/msg00469.html (15,277 bytes)

19. Re: xfs_fsr, performance related tweaks (score: 1)
Author: Andi Kleen <andi@xxxxxxxxxxxxxx>
Date: Fri, 29 Jun 2007 10:58:46 +0200
Don't do that then. It's probably the reason you get the bad fragmentation in the first place. Most file systems perform very poorly when they are nearly full. -Andi
/archives/xfs/2007-06/msg00470.html (9,780 bytes)

20. Re: xfs_fsr, performance related tweaks (score: 1)
Author: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Sat, 30 Jun 2007 13:17:29 -0400
I wouldn't mind seeing a way to tell fsr to not worry about defragging some files based on current layout; say if the avg extent in the file is in 3 extents (not bad) fsr will try to "fix" it for you
/archives/xfs/2007-06/msg00486.html (10,331 bytes)


This search system is powered by Namazu