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?
>
|