[Top] [All Lists]

Re: 2 question about XFS fragmentation and _fsr

To: Janos Haar <janos.haar@xxxxxxxxxxxx>
Subject: Re: 2 question about XFS fragmentation and _fsr
From: Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx>
Date: Mon, 11 Apr 2011 15:37:10 -0500
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: <DFA094D472104424BEA7AA9060DE0D6F@myXP>
References: <DFA094D472104424BEA7AA9060DE0D6F@myXP>
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv: Gecko/20110303 Thunderbird/3.1.9
Janos Haar put forth on 4/11/2011 12:39 PM:

> In the result, actually we have >6TB images on the 3TB disk, wich is
> 97.9% fragmented.

How much free space does the filesystem have?  How big is each image
file?  For xfs_fsr to work properly it must have sufficient free space
in the filesystem.

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

It sounds like you may have some other issues besides filesystem

> The XFS_FSR can be good for me or not?

If you have plenty of free space.

> Question 2:
> One of our customers have one storage wich is exactly the same like the
> one wich is described on the Q1, but only used for samba storage for
> storing media files (big files.)

Writing large files sequentially shouldn't cause fragmentation.

> I am sure, there is no torrent or similar, and i have told to the
> customers on the beginning "don't write more files parallel, to avoid
> fragmentation", but today the storage is >95% fragmented.
> The customer sad, he only does file write one by one, and nothing more.
> How can this be?

What were the mkfs.xfs arguments you used when creating these
filesystem?  Please share xfs_info output for the filesystems in
question, and details of the underlying hardware RAID storage.


<Prev in Thread] Current Thread [Next in Thread>