🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.os.ms-windows.nt.misc
Article #124

Re: Defrag for NTFS

#124
From: Paul Keinanen
Date: Sun, 21 Jun 1998 00:00
43 lines
3238 bytes
On Thu, 11 Jun 1998 13:31:43 GMT, supermathie@sprint.ca (Super Mathie)
wrote:

: Whoah... hold on a minute here...
: 
: On 11 Jun 1998 08:07:08 GMT, "Larry E. Hayes" <larryh@wolfenet.com> wrote:
: 
: >NTFS should perform a defrag as part of it's normal process functioning. 
: >This is a major concept of an NTFS.  The only time you would need a defrag
: Sorry, no. NT does not defragment itself while it's running. The difference that
: I believe you're thinking about is that it actually "thinks" about where the
: best place for a new file would be, as apposed to FAT using first available
: cluster.

The principle of using "best fit" instead of "first fit" only works
effectively, only when the final size of file is known when the file
is created. Unfortunately, the CreateFile Win32 API does not allow the
initial allocation or the default file extension size to be specified.
AFAIK, the only way to create a file of a specific allocation size is
to use CreateFile+CreateFileMapping with the desired file size, but
even this does not allow controlling the file extension size (i.e. the
size how much the file is extended if the current allocation is not
enough).

In some sample programs from Microsoft, the data to be written out is
created in virtual memory and a single WriteFile is used to write out
the whole file at one. At least theoretically, this would permit the
use of the "best fit" algorithm and allocate a single contiguous area
for the file. However, I have no evidence if this algorithm is used or
not.

It appears that some language run time libraries or the Win32
subsystem itself (at least prior to NT4 SP3) seems to try to cache a
very large number of fprintf etc. requests into virtual memory before
writing out to disk, since when writing large amounts of data
(hundreds of MBs), the paging was enormous, putting the machine to
almost a complete standstill and data was written very slowly to the
actual output file.

Without simple means how every application could easily control the
initial allocation and file extension sizes, I do not see how the
"best fit" algorithm would be effective in preventing fragmentation.
Technical Details
Message-ID: <359bb2b9.520618579@news.sci.fi>
Path: arc1-ca.pugleaf.net!unknown!not-for-mail
References: <357C2FE0.1D44F1D5@ThePentagon.com> <01bd9510$4c00d420$0100007f@darland> <3586db2c.76485239@news.vaxxine.com>

Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 115135,a0d6565a0865548
X-Google-Attributes: gid115135,public
X-Google-Thread: 104ed6,a0d6565a0865548
X-Google-Attributes: gid104ed6,public
X-Google-Thread: fb9cd,a0d6565a0865548
X-Google-Attributes: gidfb9cd,public
X-Google-Thread: fb96d,a0d6565a0865548
X-Google-Attributes: gidfb96d,public
X-Google-Thread: fa335,a0d6565a0865548
X-Google-Attributes: gidfa335,public
From: keinanen@sci.fi (Paul Keinanen)
Subject: Re: Defrag for NTFS
Date: 1998/06/21
Message-ID: <359bb2b9.520618579@news.sci.fi>
X-Deja-AN: 364672208
Content-Transfer-Encoding: 7bit
References: <357C2FE0.1D44F1D5@ThePentagon.com> <01bd9510$4c00d420$0100007f@darland> <3586db2c.76485239@news.vaxxine.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Organization: Scifi Communications International, http://www.sci.fi/, helpdesk@sci.fi, +358 3 2899111
Newsgroups: comp.os.ms-windows.nt.misc,microsoft.public.windowsnt.misc,comp.os.ms-windows.nt,cis.winnt.general,at.tuwien.os.winnt