Re: stable xfs

[Ming Zhang <mingz@ele.uri.edu>]

On Fri, 2006-07-21 at 09:07 -0700, Chris Wedgwood wrote:
> On Fri, Jul 21, 2006 at 09:10:31AM -0400, Ming Zhang wrote:
> 
> > then what is the benefit? because files under same dir can be accessed
> > with locality so put close will reduce disk head seek?
> 
> yes
> 
> > other than this, what else benefit?
> 
> that alone has a measurable benefit to me (i have an overlay
> filesystem over many smaller 400 to 500GB filesystems so i don't get
> the benefit of many spindles to reduce average seek times)

what u mean overlay fs over small fs? like a unionfs?

> 
> > so if i have 500GB file, will it be copied to another 500GB temp
> > file?
> 

but other than fsr. there is no better way for this right?

of course, preallocate is always good. but i do not have control over
applications.


> yes, which in many cases isn't always derisable because:
> 
>   * if the file had a small number of extents in the first place,
>     reducing them slightly more isn't much of a gain (ie. going from
>     say 11 to 10 is argubly pointless) (i have a patch to specifiy
>     the miniumum gains before doing the copy somewhere)
> 
>   * if the file changes during the copy, then it will be skipped until
>     next time, for larger files this is problematic,  you could
>     argue attemtping to fsr a file that is less than <n> seconds old
>     is pointless as it has a high chance of being active (i have a
>     patch for that too))

sounds like a useful patch. :P will it be merged into fsr code?

> 
>   * fsr has no global overview of what it's doing, so it never does
>     things like 'move this file out of the way to make room for this
>     one' (it can't do this w/o assistance right now), and of course it
>     can't move inodes w/o changing them so there are limits to what
>     can be done anyhow

what kind of assistance you mean?

>