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
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 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
 

Click here to add your comments
I would differ from the above explanation. The "experts" in many sites and articles are seeing at fragmentation as a process effecting file reads. I'd think its a process effecting file writes also.

File writes and subsequent updates are what cause fragmentation particularly when the disk is at 85% of its capacity.

The tracks being allocated in sectors or cilinders does not matter much.

What all the "experts" mean is DOS and Windows has less efficient disk access drivers than Unix varients. So they infer Linux file system does not have fragmentation issues which is wrong.

Fragmentation occurs on all hard disks except the proposed harddisks with bubble memory which we may see a long way in the future.

Fragmentation is a disk thing and not OS thing. Please dont say that Linux disks do not have fragmentation issues only with the reason that it employs better disk drivers.

Raja Surapaneni..
MCSE, CNE & Linux fan

--

You aren't understanding. It's not that Unix and Linux disks don't have fragmentation, it's that fragmentation isn't the issue it is in single-user OSes, both because the file systems are designed with that in mind and because multi-use access is inherently fragmented.

--TonyLawrence





Tue Aug 14 19:45:06 2007: Subject:   anonymous


You just misread the original post ! Read carefully!



Thu Jun 25 02:50:33 2009: Subject: File defrag   anonymous


Well, I don't do much (add software etc.) to my Linux system, but its file accessing is slowing down as is booting etc. just like a winx machine. I am new to Linux so most of what I do is open things, read the Linux book I have, surf the how to Linux sites and exercise the features to learn more about Linux, but it sure seems to me that some sort of file defrag is going on. The net seems to be evenly split about this happening and some developers are looking into it (they say anyway).





Fri Jun 26 05:50:29 2009: Subject:   TonyLawrence



It is certainly possible that you have a specific situation where defragging would be helpful to your system.

However, I still think you need to read this again more carefully and also http://aplawrence.com/Unixart/defrag-wars.html


Don't miss responses! Subscribe to Comments by RSS or by Email

Click here to add your comments

If you want a picture to show with your comment, go get a Gravatar

Macworld Digital Photography Superguide

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.