On Thu, 2006-07-20 at 09:17 -0700, Chris Wedgwood wrote:
> On Thu, Jul 20, 2006 at 10:08:22AM -0400, Ming Zhang wrote:
> > we mainly handle large media files like 20-50GB. so file number is
> > not too much. but file size is large.
> xfs_repair usually deals with that fairly well in reality (much better
> than lots of small files anyhow)
sounds cool. yes, large # of small files are always painful.
> > hope i never need to run repair, but i do need to defrag from time
> > to time.
> if you preallocate you can avoid that (this is what i do, i
> preallocate in the replication daemon)
i could not control my application. so i still need to do defrag some
> > hope this does not hold true for a 15x750GB SATA raid5. ;)
> that's ~10TB or so, my guess is that a repair there would take some
> GBs of ram
> it would be interesting to test it if you had the time
yes. i should find out. hope to force a repair? unplug my power cord? ;)
> there is a 'formular' for working out how much ram is needed roughly
> (steve lord posted it a long time ago, hopefully someone can find that
> and repost is)
> > say XFS can make use of parallel storage by using multiple
> > allocation groups. but XFS need to be built over one block
> > device. so if i have 4 smaller raid, i have to use LVM to glue them
> > before i create XFS over it right? but then u said XFS over LVM or N
> > MD is not good?
> with recent kernels it shouldn't be a problem, the recursive nature of
> the block layer changed so you no longer blow up as badly as people
> did in the past (also, XFS tends to use less stack these days)