defrag

Hi, Michael.

Michael Havens wrote:
> That went right over my head!
>
> On Friday 16 January 2004 11:58 pm, Ted Gould said:
> . . .
> http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/html_single/Partition.html#FRAGMENTATION

Here are some comments that might help a little:

Disks are broken up into numbered chunks or blocks of some
fixed size.
A directory translates a file name into a list of
block addresses, so you can read through the file.
The operating system (OS) maintains the disk directory,
and also a list of all the available chunks of storage.
When a program goes to create a file, the OS builds a
directory entry and assigns an initial area of storage.
If that area gets filled, the OS adds another chunk --
somewhere on the disk. These can be scattered all over,
so the head on the disk unit has to get jerked all around
seeking for the right tracks as you read through the
file.
Windows systems allocate one chunk at a time. I gather from
the article that a Unix/Linux system allocates a bigger
space, so the chances are better that the whole file will
fit in that space -- in a consecutive series of chunks.
Any bl
If your computer has lots of memory, it can keep a lot of
disk blocks in memory, so you can read them without
going to the disk. This is called buffering or caching.
Unix does this better than MS.
On any system, when a program finishes writing a file,
on the average it stands to reason that the last block
will be only half used, and since the directory works in
terms of whole chunks there is no way to let another file
use that wasted space. (Some file systems have a way for
two files to share a tail-block, but most can't.)
If you have a million tiny files using a million big blocks,
then those blocks are mostly wasted. If you have small
blocks, then the system has to fetch lots of blocks to get
through the file, which can be inefficient. So if you
really need to optimize, then block size is important.
But most of us don't need to worry about that.

HTH,

Vic