| To: | Eric Sandeen <sandeen@xxxxxxxxxxx> |
|---|---|
| Subject: | Re: xfs_fsr, performance related tweaks |
| From: | Andi Kleen <andi@xxxxxxxxxxxxxx> |
| Date: | 29 Jun 2007 02:52:57 +0200 |
| Cc: | Just Marc <marc@xxxxxxxxx>, xfs@xxxxxxxxxxx |
| In-reply-to: | <46841C60.5030207@xxxxxxxxxxx> |
| References: | <4683ADEB.3010106@xxxxxxxxx> <46841C60.5030207@xxxxxxxxxxx> |
| Sender: | xfs-bounce@xxxxxxxxxxx |
| User-agent: | Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 |
Eric Sandeen <sandeen@xxxxxxxxxxx> writes: > Just Marc wrote: > > > 2. Files for which 'No improvement will be made' should also be marked > > as no-defrag, this will avoid a ton of extra work in the future. > > 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? 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 be worth the effort. Why would you run fsr that often that it matters? Also I would expect that one can easily detect in many cases an defragmented file by looking at the number of extents in the inode only and that would make it equivalent to the flag. The cases where this is not the case are probably rare too. -Andi |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [PATCH 4/7][TAKE5] support new modes in fallocate, Nathan Scott |
|---|---|
| Next by Date: | Re: xfs_fsr, performance related tweaks, Nathan Scott |
| Previous by Thread: | Re: xfs_fsr, performance related tweaks, Eric Sandeen |
| Next by Thread: | Re: xfs_fsr, performance related tweaks, Just Marc |
| Indexes: | [Date] [Thread] [Top] [All Lists] |