Re: xfs_fsr question for improvement

[Eric Sandeen <sandeen@sandeen.net>]

Emmanuel Florac wrote:
> Le Sun, 25 Apr 2010 12:17:24 +0100 vous écriviez:
> 
>>> my test VMware server (performance dropped down to abysmal
>>> level until I set up a daily xfs_fsr cron job),  
>> That should not be the case unless you are using very sparse
>> VM image files, in which case you get what you pay for.
>>
> 
> This is a development and test VM Ware server, so it hosts lots ( 100
> or so) of test VM with sparse image files (when you start a VM to host
> a quick test, you don't want to spend 15 minutes initializing the
> drives).

If you have the -space- then you can use space preallocation to
do this very quickly, FWIW.  xfs_io's resvsp command, or fallocate
in recent util-linux-ng, if vmware doesn't do it on its own already.

You pay some penalty for unwritten extent conversion but it'd be
better than massive fragmentation of the images.

>>> and a write-intensive video server.  
>> That also should not be the case unless your applications write
>> strategy is wrong and you get extremely interleaved streams, in
>> which case you get what you paid for the application programmer.
> 
> The application write strategy is as simple as possible; several
> different machines unaware of every other write huge media files to a
> samba share. I don't know how it could be worse, however it could
> hardly be enhanced in any way.

If it's all large writes, you could mount -o allocsize=512m or so:

  allocsize=size
        Sets the buffered I/O end-of-file preallocation size when
        doing delayed allocation writeout (default size is 64KiB).
        Valid values for this option are page size (typically 4KiB)
        through to 1GiB, inclusive, in power-of-2 increments.

and that might help.

-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs