Note: I have splitted my previous letter for easyer discusion...
This have only Question-1 the storage with only sparse files.
----- Original Message -----
From: "Dave Chinner" <david@xxxxxxxxxxxxx>
To: "Janos Haar" <janos.haar@xxxxxxxxxxxx>
Cc: <linux-xfs@xxxxxxxxxxx>
Sent: Monday, April 11, 2011 11:42 PM
Subject: Re: 2 question about XFS fragmentation and _fsr
On Mon, Apr 11, 2011 at 07:39:07PM +0200, Janos Haar wrote:
Hello list,
First, please CC me because i am not on the list.
Question 1:
I am working in a data recovery company, and we are using one 3TB
RAID storage with XFS to store the recovery cases in image files.
For spare a lot of space, usually we are imaging only the used
spaces of the filesystems. (for example 1TB system drive wich have
only 80GB data inside but needs to be bootable, the image is similar
like Ghost images)
But this makes a lot of sparse files, wich right should be this way.
Some cases are done and we are closed (image can be deleted), and
some needs to store for long time.
In the result, actually we have >6TB images on the 3TB disk, wich is
97.9% fragmented.
How are you determining that figure?
[root@UNISTORE admin]# cat xfs_get_frat_ratio
echo loop0
xfs_db -c frag -r /dev/loop0
[root@UNISTORE admin]# ./xfs_get_frat_ratio
loop0
actual 7650952, ideal 752501, fragmentation factor 90.16%
Basically the sparse RAW disk images should be more faster
accessible than the original drive, because this is 4disk raid,
instead of one, AND the head don't need to travel through the empty
space of the drive...
But actually we are proud if we can read or write in 8-10MB/s! :-D
I have started to read about xfs_fsr but there is almost none
information, how it is _really_ working, and i am doubt about this
will try to fill up all of my images, and therefore fail to do any
improvement, or this will do the right job and will re-organize the
sparse files again.
The XFS_FSR can be good for me or not?
xfs_fsr preserves the layout of sparse files, so it is unlikely to
help you at all here. Remember, sparse files only reduce the amount
of space used by a file - they don't magically reduce the number of
seeks needed to read data from the files...
Yes of course, but heads needs move more closer from one point to another.
I think this should reduce the seeking time.
Or i have missed something? :)
If not, i suggest to implement an option to do sparse fles on the
result or not in the next releases...
I will say a huge thanks in the end. :-)
Cheers,
Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
Thanks,
Janos
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
