Article View: comp.os.ms-windows.nt.misc
Article #124Re: Defrag for NTFS
From: Paul Keinanen
Date: Sun, 21 Jun 1998 00:00
Date: Sun, 21 Jun 1998 00:00
43 lines
3238 bytes
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-mailReferences:
<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