[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: defrag in linux

On Sun, Feb 10, 2002 at 12:06:40AM +0530, bulbultyagi now-india net in wrote:
> Aaron please elaborate on your answer
> I would love to know more about this filesystem approach that manages to
> avoid fragmentation even after repeated creation and deletion of files.
Well the complete story is long. But in short in dos based system
files are allocated in contiuous blocks. So they tend to be at the
end of the disk. When files are removed holes appear in the disk but
there is no real way to tell where they are so you need to defrag or
your system will get full.

*nix based systems use a more complex system based on inodes.It is
built from disk segments called inodes
and disk blocks(these latter blocks are generally either 1k or 4K). Of
the name of a file which appears in a directory (which is also a file
block); the name is identified with an inode. That inode contains the
information about the file that you might get by running ls on the
The inode also contains 13 address fields. 10 if the fields identify
blocks containing content of the file. So for 1k blocks you could
10k of the files contents. Now it gets more exciting. The 11th field
points to another inode which can point to file blocks. If you still
need bigger files the 12th field in the original inode points to an
inode that points to 10 inodes that point to ten blocks each of the
file. You still want more space we go to the 13th field of the
inode which points to 10 inodes, which point to 10 inodes which point
10 blocks of the files. At that point you quit.:

Now there is some argument in books about whether there are 10 or 12
direct addresses in an inode but that is not really important.

What is important is files that are written are not written
immediately to the disk and the system has some idea where the free
inodes are. There are various schemes to deal with this matter
efficiently. You notice that only 95% of a Linux disk is available for
normal use. This allows some moving around of file inodes to make
things more efficient. Other schemes are possible. 
Aaron Konstam
Computer Science
Trinity University
715 Stadium Dr.
San Antonio, TX 78212-7200

telephone: (210)-999-7484
email:akonstam trinity edu

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]