🚀 go-pugleaf

The similarity to VMS ends at the conceptual stage.  The NT disk
and file systems have almost no similarity at all, with the
exception of a few hidden files at the root of an NTFS partition
that are not viewable unless you run NTFSDOS or some other utility.
--
Greg Askew
gba@REMOVE-THISmindspring.com

Andrew Sisson wrote:
> 
> 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.
> >