Re: File Fragmentation
- From: Robert Heller <heller@xxxxxxxxxxxx>
- Date: Mon, 05 Dec 2005 23:10:55 +0100
Cliff Hewitt <somebug@xxxxxxxxxxxxxx>,
In a message on Mon, 05 Dec 2005 20:26:16 GMT, wrote :
CH> Robert Heller wrote:
CH> > Cliff Hewitt <somebug@xxxxxxxxxxxxxx>,
CH> > In a message on Mon, 05 Dec 2005 16:25:15 GMT, wrote :
CH> >
CH> > CH> Hey folks,
CH> > CH>
CH> > CH> I understand that ext2 and ext3 are supposed to be better than FAT and
CH> > CH> NTFS with respect to file fragmentation, but somehow I was under the
CH> > CH> impression that there would be no fragmentation. Clearly, when I run
CH> >
CH> > Wrong. Fragmentation happens and is *normal*. What happens to the O/S
CH> > and disk I/O performance when it happens is a whole other issue...
CH>
CH> Certainly. That's why I'm interested in it.
CH>
CH> >
CH> > CH> filefrag, I see some files with "discontinuit[ies]". I am interested in
CH> > CH> knowing why the fragmentation happens, and what I can do to defragment.
CH> > CH> I don't care much that fragmentation occurs, since I blindly accept
CH> > CH> the statement "ext/x/ is better than FAT and NTFS," but I'd like to
CH> > CH> understand it better for ext2 and 3.
CH> >
CH> > Linux (and UNIX) file I/O works differently than MS-DOS/MS-Windows.
CH> > The driver modules (both low-level disk drivers and file system
CH> > modules) optimize disk access to minimize disk head travel (seeks) in a
CH> > multi-user / multi-tasking environment. This is part of how they were
CH> > designed: from the ground up for a multi-user / multi-tasking environment.
CH>
CH> So, these two file systems are designed with minimizing seek times
CH> versus, say, finding the largest continuous segment of free space?
Essentially yes. In a multi-user / multi-tasking environment the idea
of the 'largest continuous segment of free space' is not a very
meaningful or useful thing. Keeping your disk access time (read: I/O
delay) down is a good thing. Since in a multi-user / multi-tasking
environment *multiple files* will be written at any given time (since at
any given time there will be multiple processes running and possibly
generating output or reading input), none of which are 'complete', you
want to write (and read) all of the segments of these files out to
disk. Rather than move the head all over the place to leave 'holes'
for unfinished files, you write what you have in a series of block
writes. Other aspects of Linux and UNIX file systems, such as how the
list of free blocks is ordered and so on are also part of the
minimizing seek times strategy of these file systems.
Contrast this with a single-user / single-tasking environment: since
only one file is being read or written at any one time, it makes sense to
optimize I/O by trying to get the file in one continuous segment of disk
space. This is even more of an issue with slower devices and/or small
media (read: floppy disks).
CH>
CH> > ... NTFS
CH> > was sort of an attempt at this, but because of the downward
CH> > compatibility requirements and basic mis-designs deep in MS-Windows NT,
CH> > NTFS is only marginally better than FAT in terms of performance issues
CH> > WRT fragmentation.
CH> >
CH> > CH>
CH> > CH> Thanks,
CH> > CH>
CH> > CH> Cliff Hewitt
CH> > CH>
CH> >
CH> > \/
CH> > Robert Heller ||InterNet: heller@xxxxxxxxxxxx
CH> > http://www.deepsoft.com/ ||FidoNet: 1:321/153
CH> > http://www.deepsoft.com/~heller /\
CH> >
CH>
CH> Thanks again,
CH>
CH> Cliff Hewitt
CH>
\/
Robert Heller ||InterNet: heller@xxxxxxxxxxxx
http://www.deepsoft.com/ ||FidoNet: 1:321/153
http://www.deepsoft.com/~heller /\
.
- References:
- File Fragmentation
- From: Cliff Hewitt
- Re: File Fragmentation
- From: Robert Heller
- Re: File Fragmentation
- From: Cliff Hewitt
- File Fragmentation
- Prev by Date: Re: new http attack ?
- Next by Date: Re: File Fragmentation
- Previous by thread: Re: File Fragmentation
- Next by thread: Re: File Fragmentation
- Index(es):
Relevant Pages
|
