🚀 go-pugleaf

Really?  I though just about ALL of the core systems and kernal and what not
came from VMS?  Is NTFS really like/similar/from HPFS?

Paul Keinanen wrote in message <359bb2b9.520618579@news.sci.fi>...
>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.
>