A.P. Lawrence

file system fragmentation defragmentation linux

If this isn't exactly what you wanted, please try our Search (there's a LOT of techy and non-techy stuff here about Linux, Unix, Mac OS X and just computers in general!):

From - Sat Sep 29 07:28:59 2001
Path: typhoon.ne.mediaone.net!chnws06.ne.mediaone.net!24.147.2.43!chnws02.mediaone.net!newsfeed2.skycache.com!newsfeed1.cidera.com!Cidera!newsfeed.sovam.com!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!merlin.l6s4x6-4.ca!nobody Message-ID: <3BB50505.7EDE2C5B@sympatico.ca>
From: Lew Pitcher <lpitcher@sympatico.ca>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.19 i686)
X-Accept-Language: en, en-GB, en-US
MIME-Version: 1.0
Newsgroups: alt.os.linux,alt.os.linux.mandrake,comp.os.linux.misc
Subject: Re: Defrag in linux? - Newbie question References: <flQs7.504$Cu2.29521@eagle.america.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 147
Date: Fri, 28 Sep 2001 19:17:25 -0400
NNTP-Posting-Host: 64.228.39.63
X-Complaints-To: abuse@sympatico.ca
X-Trace: news20.bellglobal.com 1001741343 64.228.39.63 (Sat, 29 Sep 2001 01:29:03 EDT)
NNTP-Posting-Date: Sat, 29 Sep 2001 01:29:03 EDT
Organization: Bell Sympatico
Xref: chnws06.ne.mediaone.net alt.os.linux:219385 alt.os.linux.mandrake:184910 comp.os.linux.misc:349765

mac wrote:
> 
> Do I need to defrag the HD in Linux?  If yes, how?
>

Short answer: No.

Long answer: see below

In a single-user, single-tasking OS, it's best to keep all blocks for a
file together,
because _most_ of the disk accesses over a given period of time will be
against a
single file. In this scenario, the read-write heads of your HD advance
sequentially
through the hard disk. In the same sort of system, if your file is
fragmented, the
read-write heads jump all over the place, adding seek time to the hard
disk access time.

In a multi-user, multi-tasking, multi-threaded OS, many files are being
accessed at any
time, and, if left unregulated, the disk read-write heads would jump all
over the place
all the time. Even with 'defragmented' files, there would be as much
seek-time delay as
there would be with a single-user single-tasking OS and fragmented
files.

Fortunately, multi-user, multi-tasking, multi-threaded OSs are usually
built smarter than
that. Since file access is multiplexed from the point of view of the
device (multiple file
accesses from multiple, unrelated processes, with no order imposed on
the sequence of blocks
requested), the device driver reorders the requests into something
sensible for the device
(i.e elevator algorithm).

In other words, fragmentation is a concern when one (and only one)
process access data from
one (and only one) file. When more than one file is involved, the disk
addresses being
requested are 'fragmented' wrt the sequence that the driver has to
service them, and thus it
doesn't matter to the device driver whether or not a file was
fragmented.

To illustrate:

I have two programs executing simultaneously, each reading two different
files.

The files are organized sequentially (unfragmented) on disk...
 [1.1][1.2][1.3][2.1][2.2][2.3][3.1][3.2][3.3][4.1][4.2][4.3][4.4]

Program 1 reads file 1, block 1
                file 1, block 2
                file 2, block 1
                file 2, block 2
                file 2, block 3
                file 1, block 3

Program 2 reads file 3, block 1
                file 4, block 1
                file 3, block 2
                file 4, block 2
                file 3, block 3
                file 4, block 4

The OS scheduler causes the programs to be scheduled and executed such
that the device
driver receives requests
                file 3, block 1
                file 1, block 1
                file 4, block 1
                file 1, block 2
                file 3, block 2
                file 2, block 1
                file 4, block 2
                file 2, block 2
                file 3, block 3
                file 2, block 3
                file 4, block 4
                file 1, block 3

Graphically, this looks like...

  [1.1][1.2][1.3][2.1][2.2][2.3][3.1][3.2][3.3][4.1][4.2][4.3][4.4]
}------------------------------>[3.1]
  [1.1]<-----------------------'
       `-------------------------------------->[4.1]
       [1.2]<---------------------------------'
            `----------------------->[3.2]
                 [2.1]<-------------'
                      `---------------------------->[4.2]
                      [2.2]<-----------------------'
                           `------------->[3.3]
                           [2.3]<-------'
                                `---------------------------->[4.4]
             [1.3]<------------------------------------------'

As you can see, the accesses are already 'fragmented' and we haven't
even reached the disk
yet. I have to stress this, the above situation is _no different_ from
an MSDOS single file
access against a fragmented file.

So, how do we minimize the effect seen above? If you are MSDOS, you
reorder the blocks on
disk to match the (presumed) order in which they will be requested.
OTOH, if you are Linux,
you reorder the _requests_ into a regular sequence that minimizes disk
access. You also
buffer most of the data in memory, and you only write dirty blocks. In
other words, you
minimize the effect of 'disk file fragmentation' as part of the other
optimizations you
perform on the _access requests_ before you execute them.

Now, this is not to say that 'disk file fragmentation' is a good thing.
It's just that
'disk file fragmentation' doesn't have the *impact* here that it would
have in MSDOS-based
systems. The performance difference between a 'disk file fragmented'
Linux file system and
a 'disk file unfragmented' Linux file system is minimal to none, where
the same performance
difference under MSDOS would be huge. 

Under the right circumstances, fragmentation is a neutral thing, neither
bad nor good. As
to defraging a Linux filesystem (ext2fs), there are tools available, but
(because of the
design of the system) these tools are rarely (if ever) needed or used.
That's the impact
of designing up front the multi-processing/multi-tasking multi-user
capacity of the OS into
it's facilities, rather than tacking multi-processing/multi-tasking
multi-user support on
to an inherently single-processing/single-tasking single-user system.

-- 
Lew Pitcher

Master Codewright and JOAT-in-training
Registered Linux User #112576