On Wed, May 09, 2012 at 01:57:01AM -0500, Stan Hoeppner wrote: > On 5/7/2012 3:05 PM, Stefan Priebe wrote: > > Am 07.05.2012 18:36, schrieb Stan Hoeppner: .... > >> What I would suggest is doing an xfsdump to a filesystem on another LUN > >> or machine, expand the size of this LUN by 50% or more (I gather this is > >> an external RAID), format it appropriately, then xfsrestore. This will > >> eliminate your current free space fragmentation, and the 50% size > >> increase will delay the next occurrence of this problem. If you can't > >> expand the LUN, simply do the xfsdump/format/xfsrestore, which will give > >> you contiguous free space. > > But this will only help for a few month or perhaps a year. > > So you are saying your backup solution will fill up an additional 2.3TB > in less than a year? In that case I'd say you have dramatically > undersized your backup storage and/or are not using file compression to > your advantage. And you're obviously not using archiving to your > advantage or you'd not have the free space fragmentation issue because > you'd be dealing with much larger files. > > So the best solution to your current problem, and one that will save you > disk space and thus $$, is to use a backup solution that makes use of > both tar and gzip/bzip2. Why use the slow method? xfsdump will be much faster than tar. :) Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
