Date: Fri, 28 May 1999 12:58:42 -0600 From: Wes Peters <wes@softweyr.com> To: Peter Jeremy <jeremyp@gsmx07.alcatel.com.au> Cc: wayne@msen.com, hackers@FreeBSD.ORG Subject: Re: File system gets too fragmented ??? Message-ID: <374EE762.3091C5D4@softweyr.com> References: <99May28.153523est.40353@border.alcanet.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Jeremy wrote:
>
> "Michael R. Wayne" <wayne@msen.com> wrote:
> >Long ago, back when disks were small, slow and expensive, someone
> >wrote a program that properly defragged a Unix filesystem.
>
> If it was that long ago, chances are it is pre-FFS - the System 5
> File System and its predecessors. I remember using a Motorola
> SysVR3 system that included a disk de-fragmenting tool.
>
> Re-writing a disk in-place will always be slow because you're mostly
> doing small I/O's at random places on the platter.
>
> dump/newfs/restore is the safest way to defragment a disk. It's
> probably faster than an in-place de-fragmenter as well.
Interesting this should come up at this time. Somebody here handed
me a copy of "Windows NT Systems" magazine yesterday, as a joke (in
poor taste). It happened to be open to an add for PerfectDisk 2000
from Raxco Software. I used to work for Raxco, before they spun
the security tools off into Axent Technologies and took that public;
I thought Raxco had just died. Like all good VMS software houses,
they just mutated into NT software houses.
Anyhow, one of the first things I did at Raxco in 1991 was to write
a detailed explanation of why SunOS didn't need a disk defragmenting
product -- "ffs doesn't fragment files the way VMS does."
A background task that moves disk blocks around, continually optimizing
the filesystem layout always SOUNDS like a good idea. In practice, it
rarely is. Consider the side effects of moving blocks around on the
disk, in live files. You somehow have to lock the file(s) whose blocks
you're currently munging, and lock the filesystem out of the pool of
blocks you're munging them into, until you're done munging. This alone
is enough to give me the willies.
An offline tool that could re-write a filesystem in an optimal pattern
while the disk is offline would be a much more feasible tool to produce.
Developing a tool like this requires knowlege of the filesystem layout
and great care, but little else. Operationally, taking a disk offline
for any reason is upsetting, but if you can't break to optimize your
disks, what CAN you break for?
Be careful what you ask for, somebody might just make it.
--
"Where am I, and what am I doing in this handbasket?"
Wes Peters Softweyr LLC
http://www.softweyr.com/~softweyr wes@softweyr.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?374EE762.3091C5D4>