>>> On Sun, 21 Oct 2007 04:16:54 -0400 (EDT), Justin Piszcz
>>> <jpiszcz@xxxxxxxxxxxxxxx> said:
jpiszcz> What they do not talk about is how bad JFS "supposedly"
jpiszcz> gets after 1-2 years of usage regarding fragmentation
I have quite a bit of experience of JFS slowdown caused by
fragmentation as I use JFS for my root filesystem and after a
few months of very intense updates and rewrites overall speed
goes down by a factor of around 2.5 which seems to me to be
fairly good (at least as compared to a slowdown of a factor of 7
with 'ext3'). I have little idea of how much XFS slows down with
time, as I don't use it for my ''root'' filesystem, but it seems
comparable to JFS. This is not awesome either, but somewhat
understandable.
Part of the reason is that filesystem competitive benchmarks
that file system designers care about seem all about freshly
loaded filesystems; also it is not easy to do absolutely
equivalent updates...
And the claim to fame for XFS is not steady performance across
updates, it is high aggregate multi-process/multi-stream
performance *on a freshly constructed* filesystem (well, I have
seen impressive performance in such a case).
jpiszcz> and how there is no defragmenting tool for JFS.
I have thought about taking an existing attempt as a JFS
defragmenter and completing it, but I have realized that
in-place defragmentation is usually a very bad idea in almost
all cases, both for performance and safety reasons, and copying
and switching is the only sensible way. The argument is that in
most cases it is unsafe to defragment in-place without prior
backup, and the backup is a much faster way to ''straighten
out'' the files anyhow.
Of course this runs into the problem that one has to take the
filesystem offline for some time to switch, but then current
file systems are simply not designed (with the claimed exception
of ZFS suitably configured) as VLDBs (''a VLDB is a database
that is so large that it is impractical to take it offline to
backup''), just consider the 'fsck' time/space problem.
|