xfs
[Top] [All Lists]

Re: xfs_fsr question for improvement

To: Linux XFS <xfs@xxxxxxxxxxx>
Subject: Re: xfs_fsr question for improvement
From: pg_xf2@xxxxxxxxxxxxxxxxxx (Peter Grandi)
Date: Sun, 25 Apr 2010 12:17:24 +0100
In-reply-to: <20100417091357.4e7ad1e0@xxxxxxxxxxxxxx>
References: <201004161043.11243@xxxxxx> <20100417012415.GE2493@dastard> <20100417091357.4e7ad1e0@xxxxxxxxxxxxxx>
[ ... ]

>> XFS resists fragmentation better than most other filesystems,
>> so defragmentation, while possible, is generally not needed.

That's a common myth. For most file systems and filesystems.
Also most applications write files really badly.

  http://www.sabi.co.uk/blog/anno06-3rd.html#060914b

> There two systems nevertheless where I need to use xfs_fsr
> regularly to keep decent performance :

Fortunately 'xfs_fsr' is mostly reliable, but in-place
defragmentation is a risky propostion for several reasons even
if 'xfs_fsr' is fairly reliable.

Note also that 'xfs_fsr' uses a terrible "defragmentation"
strategy (from 'man xfs_fsr'):

  "The reorganization algorithm operates on one file at a time,"

  "xfs_fsr improves the layout of extents for each file by
  copying the entire file to a temporary location and then
  interchanging the data extents of the target and temporary
  files in an atomic manner."

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

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

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