Virtual Machine and NTFS

Philo Pastry wrote:
John John - MVP wrote:

Other than saying that this behavior was "by design", Microsoft
has never said *why* they gave the NT line of OS's the handicap
of not being able to create FAT32 volumes larger than 32 gb.

Raymond Chen talks about this he

Windows Confidential A Brief and Incomplete History of FAT32

=============
For a 32GB FAT32 drive, it takes 4 megabytes of disk I/O to compute the
amount of free space.
============

You do realize how trivial a 4 mb data transfer is, today and even 5, 10
years ago - don't you?

Chen doesn't mention any other file or drive operation as being impacted
by having a large cluster count other than the computation of free space
- which I believe is infrequently performed anyways.

I formatted a 500 gb drive as a single FAT32 volume using 4kb cluser
size just as an excercise to test if Windows 98se could be installed and
function on such a volume, and it did - with the exception that it would
not create a swap file on such a volume.

Well, that's really nice. No swap file? Great. (Plus the other utilities
you said that won't work anymore (like the much faster version of Defrag
from WinME).

And as Chen mentions, yes - the *first* directory command on FAT32
volumes with a high cluster-count does take a few minutes (but not
successive directory commands).

A few *minutes*???? Are you kidding me??? THAT is totally unacceptible.
I get annoyed when XP takes 5 seconds to initially display something that
should be near instantaneous.

With all the things you've mentioned it sure seems like there is a price to
pay. Oh yeah, not the least of which is you can't *ever* have a file
larger than 4 GB (this can be a pit of a PIA for some photo, video, and disk
imaging work)

(All that being said, I do miss the ability to boot up into DOS, if I ever
want to or had to. But that's about the only thing) Well, actually I
can still boot into DOS on my thumb drive, but it's not quite the same thing
as having the good ole DOS fallback option).

What I found in my testing that either
in DOS or under Win-98, that the first dir command (or explorer-view) is
instantaneous as long as the number of clusters doesn't exceed 6.3
million. This equates to a FAT size of about 25 mb.

Which is a LONG ways from the 500 MB mentioned.

"Philo Pastry" wrote in message
...

About 3 years ago I installed XP on a 250 gb FAT-32 partitioned hard
drive and installed Adobe Premier CS3. It had no problems creating
large video files that spanned the 4 gb file-size limit of FAT32.

XP install Hmm that can not be right
it have to be a NTFS for a 250 gb to install
or you do not partition all the Hard Drive

Now I have to see this
Make a Screen Capture
And post it to http://mynews.ath.cx/doc/phUploader.php
Here my Screen Capture
http://mynews.ath.cx/doc/uploads/ntfs.jpg

"Philo Pastry" wrote in message
...
John John - MVP wrote:

People working with video editing and multimedia files often run
across this 4GB file limitations. Backup/imaging utilities also
often run into problems caused by this file size limitation,

About 3 years ago I installed XP on a 250 gb FAT-32 partitioned hard
drive and installed Adobe Premier CS3. It had no problems creating
large video files that spanned the 4 gb file-size limit of FAT32.

OK, explain how I get (Using Acronis True Image Backup)
"The incremental backup will exceed the 4Gb limit in your backup file
location"

After I raised a new backup location on a NTFS partion I never get the
above warning.


Windows XP cannot format partitions larger than 32GB to FAT32
because the increasing size of the FAT for bigger volumes makes
these volumes less efficient (bla bla bla)

Other than saying that this behavior was "by design", Microsoft has
never said *why* they gave the NT line of OS's the handicap of not being
able to create FAT32 volumes larger than 32 gb.

It's a fallacy that the entire FAT must be loaded into memory by any OS
(win-9x/XP, etc) for the OS to access the volume.

Go ahead and cite some performance statistics that show that performance
of random-size file read/write operations go down as the FAT size (# of
clusters) goes up.

Remember, we are not talking about cluster size here. FAT32 cluster
size (and hence small file storage efficiency) can be exactly the same
as NTFS regardless the size of the volume.

On Sun, 17 Oct 2010 10:15:49 -0400, Philo is wrong
wrote:


What you don't understand about NTFS is that it will silently delete
user-data to restore it's own integrity as a way to cope with a failed
transaction, while FAT32 will create lost or orphaned clusters that are
recoverable but who's existance is not itself a liability to the user or
the file system.

I'll say this. At first when win98FE crashed, I would find files that
were missing, whole mailboxes of my email program iirc. I would do
chkdsk and in the chk files I would find much of the data that was
missing. At the least I could search it for lost info, and maybe I
was able to rename the files to the original names, even if there was
garbage (prior data) at the end of the cluster or whatever.

I wondered why there was nothing in Windows, afaik, like there is in
mainframes. When one copies a 1000 byte file to a 100 byte file in an
IBM mainframe with languages like Cobol, it gives a 100 byte result,
with the other 900 truncated. That's what I wanted to do here, but I
couldn't find a way to do it.

The thing some people find convenient about fat32 is that the
system can easily be accessed by a win98 boot floppy.

Or, if you've installed DOS first on an FAT32 drive, and then install XP
as a second OS, you can have a choice at boot-up to run DOS or XP.

Why not just put all the dos files in the XP partition, and use a dos
boot disk to boot to that? Like with win98. There aren't many DOS
files, and none that I know of will used by XP. Nor will DOS have to
use any XP files, except when trying to fix things.

However an NTFS drive can still be accessed from the repair
console...

The repair console is garbage and does not compare in any way to the
utility and capability of a real DOS-type command environment.

I've used it for fixboot and fixmbr, but I thought the set of commands
was small, and I read they don't work in the same way dos commands do.


But I still haven't read most of this thread or formed any
conclusions.

On Sun, 17 Oct 2010 10:05:14 -0400, "glee"
wrote:

"mm" wrote in message
.. .
On Sat, 16 Oct 2010 07:16:58 -0500, philo wrote:

On 10/16/2010 12:33 AM, mm wrote:
Hi! I"m moving to a new machine that probably won't run win98, so I
planned to run it from a Virtual Machine under winxpsp3

Is it okay to have all the harddrive partitions NTFS, even though
win98 can't normally read NTFS?




It should work just fine.

If there are any problems they will not be due to the drive being NTFS
at any rate

Great, thank you. Now I have all the parts to fix up my friends old
2.4 gig Dell for myself. I think I'll like the increased speed.

snip

Are you using XPSP3 Home or Pro Edition as the host OS?

Pro, it appears. That was what was on this DELL before the HD failed
and he gave me the computer and the CD's that came with it.

If you find the old Connectix version 5 does not do all you want, try
the newer free version, Virtual PC 2007:
http://www.microsoft.com/downloads/e...displaylang=en

I would rather have newer! Thanks.

I read, probably in the wikip entry for this, that it was free for a
while after MS bought it, but it also gavem me the impression it
wasn't anymore. No time now to go reread it. I'm happy to have the
new version.

Thanks.

On Mon, 18 Oct 2010 09:16:29 -0400, "glee"
wrote:

"J. P. Gilliver (John)" wrote in message
...
In message , glee
writes:
[]
Are you using XPSP3 Home or Pro Edition as the host OS?

If you find the old Connectix version 5 does not do all you want, try
the newer free version, Virtual PC 2007:
http://www.microsoft.com/downloads/e...d=04D26402-319
9-48A3-AFA2-2DC0B40A73B6&displaylang=en

Thanks for the link.

That page says:

Supported Operating Systems:Windows Server 2003, Standard Edition
(32-bit x86);Windows Server 2003, Standard x64 Edition;Windows Vista
Business;Windows Vista Business 64-bit edition;Windows Vista
Enterprise;Windows Vista Enterprise 64-bit edition;Windows Vista
Ultimate;Windows Vista Ultimate 64-bit edition;Windows XP Professional
Edition;Windows XP Professional x64 Edition;Windows XP Tablet PC
Edition

...

Virtual PC 2007 runs on: Windows Vista™ Business; Windows Vista™
Enterprise; Windows Vista™ Ultimate; Windows Server 2003, Standard
Edition; Windows Server 2003, Standard x64 Edition; Windows XP
Professional; Windows XP Professional x64 Edition; or Windows XP
Tablet PC Edition

under "System Requirements". It's not clear to me, but I think the
first list must be the OSs the virtual machine can run, and the second
list the host OSs it'll run under. But anyway, I see no mention of
Home in either list; are you saying it will and they're just not
telling us?

The second list are the operating systems you can install it on, as a
host machine. I have read elsewhere that it will install and run on XP
Home as well as Pro, but have never tried.

The first list is what operating systems are "supported" to be run as a
virtual system on the host. Other systems can be run....Win98, Linux,
etc...they are just not "supported" , meaning you won't get any help or
support for issues, there may not be Additions available for everything,
or there may only be partial functionality of the unsupported virtual
system.

The version I bought, albeit for 3 dollars, Connectix Virtual PC for
Windows version 5, says on the box that it allows as a guest system
DOS, 3.1, ....up to XP home and pro, Linux, Netware, OS/2 and Solaris
8.

It doesn't say anything about supporting them or not, and I figure
that's because Connectix was not an MS company and there was no reason
to think it could support OSes.

But MS has to disclaim support for OSes it no longer supports, or some
crank will sue them, they fear.

As to Host OSes, it lists 2000, NT 4, ME, 98SE, XP Home and XP Pro.

Of course they could have removed functionality, perhaps for very good
reason in V. PC 2007. It might be years before I actually try this,
since I plan to keep the old win98/xp computer in my basement.
Hopefully win98 will work by then.

On Tue, 19 Oct 2010 02:39:08 -0500, wrote:

On Sat, 16 Oct 2010 01:33:28 -0400, mm
wrote:

Hi! I"m moving to a new machine that probably won't run win98, so I
planned to run it from a Virtual Machine under winxpsp3

Is it okay to have all the harddrive partitions NTFS, even though
win98 can't normally read NTFS?

Thanks


Much Less important:
Is Connectix Virtual PC for Windows, version 5, okay? Or is it
obsolete by now. It lists XP on the box, but I wonder if it will have
USB support with version 5.


Use FAT. Why use NTFS for ANYTHING? If you encounter an error on a
FAT partition, you can retrieve everything unless the hard drive
itself fails. If you crash a NTFS partition, kill ALL your data
goodbye, because there is no way to retrieve anything.

Heck, on a FAT partition, you can just stick in a DOS bootdisk and
access all your data. Why make life complicated when there is no
advantage whatsoever to using NTFS.

You know, until just now, I figured there was something like DOS to
access NTFS partitions. It never occurred to me that there wouldn't
be.

Thanks.

Even if your drive access is a
tiny bit faster with NTFS, is this worth losing everything? I always
tell people who format NTFS that they damn well better backup their
hard drive at least twice every hour, because if a NTFS installation
fails, IT'S OVER.....

mm wrote:
On Tue, 19 Oct 2010 02:39:08 -0500, wrote:

On Sat, 16 Oct 2010 01:33:28 -0400, mm
wrote:

Hi! I"m moving to a new machine that probably won't run win98, so I
planned to run it from a Virtual Machine under winxpsp3

Is it okay to have all the harddrive partitions NTFS, even though
win98 can't normally read NTFS?

Thanks


Much Less important:
Is Connectix Virtual PC for Windows, version 5, okay? Or is it
obsolete by now. It lists XP on the box, but I wonder if it will have
USB support with version 5.


Use FAT. Why use NTFS for ANYTHING? If you encounter an error on a
FAT partition, you can retrieve everything unless the hard drive
itself fails. If you crash a NTFS partition, kill ALL your data
goodbye, because there is no way to retrieve anything.

rubbish

Heck, on a FAT partition, you can just stick in a DOS bootdisk and
access all your data.

Well, at least that statement is true.

Why make life complicated when there is no
advantage whatsoever to using NTFS.

sigh ignorance is bliss

You know, until just now, I figured there was something like DOS to
access NTFS partitions.

And there is.

It never occurred to me that there wouldn't be.

Thanks.

In fact, there ARE such utilities. NTFS4DOS, Bart's Boot CD, etc, come to
mind. Research 101. :-)

"mm" wrote in message
...

You know, until just now, I figured there was something like DOS to
access NTFS partitions. It never occurred to me that there wouldn't
be.

While XP's recovery console was severely crippled, it is not so for Vista's
or Windows 7's - and there is also support for NTFS in Linux.

On 10/19/2010 1:17 AM, Philo Pastry wrote:
John John - MVP wrote:

Let's address your blatant lie:

"What you don't understand about NTFS is that it will silently
delete user-data to restore it's own integrity as a way to cope
with a failed transaction..."

It is you who doesn't understand anything about how NTFS works
so you spread lies and nonsence! NTFS DOES NOT silently delete
user data to replace it to restore it's own integrity and
C. Quirke does not in anyway say that in his blog.

Perhaps you have a reading comprehension problem.

This is what Quirk says, and what I've experienced first-hand when I see
IIS log file data being wiped away because of power failures:

-----------
It also means that all data that was being written is smoothly and
seamlessly lost. The small print in the articles on Transaction Rollback
make it clear that only the metadata is preserved; "user data" (i.e. the
actual content of the file) is not preserved.
-----------

You REALLY don't understand anything! What Chris is saying is that when
writes are interrupted the *NEW* data being written is not kept, not
that what is *already* on the disk (flushed) is discarded or in anyway
deleted! Listen, most of us who have been using NTFS have at one time
or another experienced glitches, crashes or unprotected power failures
while working with files, with NTFS when the computer is rebooted most
of the time it's like nothing happened at all, you might have lost the
work that was being saved at the time of the crash but the file itself
and what was successfully saved and flushed while working will still be
stored on the disk and will still be intact, don't try to lie and twist
the facts, everyone reading here will see right through your lies! Your
statement that NTFS silently deletes user-data to restore it's own
integrity was made in ignorance and to make readers think that any and
all of their files are at risk as NTFS will modify their user data, the
false statement even gives the impression that this will even happen on
files that are not being used.



Do you understand the difference between metadata and "user data" ?

Oh please, don't try to be smart and to obfuscate the issue by trying to
bring in things that will only end up biting you in the a$$! If you are
so smart about metadata you should already know that some of it is user
defined or user owned! Or do you think that the file system should
sacrifice critical system metadata and risk corrupting the MFT in order
to try save user data which was damaged or lost during a write
operation? Are you saying that the file system should not first and
foremost attempt to guarantee the integrity of of the file system
structure and the safe keeping of all the files on the disk at the
expense of one user file when glitches and failures occur?


What is being described is journaling and it is perfectly normal
NTFS behaviour, this journaling ensures atomicity of the write
operations.

Journalling ensures the *complete-ness* of write operations. Partially
completed writes are rolled back to their last complete state. That can
mean that user-data is lost.

It means that the incomplete write was not flushed to the disk and that
the old version of the file will not be updated, what will be lost will
be what was in the RAM when the file system was attempting to commit and
flush it to the disk!


You on the other hand seem to think that it is preferable to
have the file system keep incomplete or corrupt write operations
and then have scandisk run at boot time so that it may /try/
to recover lost clusters or so that it may save damaged file
segments

In my experience, drive reliability, internal caching and bad-sector
re-mapping have made most of what NTFS does redundant.

The odd thing is - I don't believe I've ever had to resort to scouring
through .chk files for data that was actually part of any sort of user
file that was corrupted. Any time I've come across .chk files, I've
never actually had any use for them.

And I can tell you that I would really be ****ed off if I was working on
a file on an NTFS system and it suffered a power failure or some other
sort of interruption and my file got journalled back to some earlier
state just because the file system didn't fully journal it's present
state or last write operation.

You still don't understand, the last successful write will be present,
what was successfully saved and flushed while you were working with the
file will be intact.


I've seen too many examples of NT-server log files that contain actual
and up-to-date data one hour, and because of a power failure the system
comes back up and half the stuff that *was* in the log file is gone.
That's an example of meta-data being preserved at the sake of user data.

You're lying again and the above statement proves beyond the shadow of a
doubt that you have absolutely no experience whatsoever on NT server
systems!

Look, no one is saying that everything NTFS is perfect and that data
loss never occurs with NTFS, that is why smart computer users keep
backups! On the other hand stop lying about things you know nothing of
and stop trying to make us believe that FAT32 is more robust than NTFS,
those who have real life experience know better. FAT32 has some
advantages in certain situations and NTFS has advantages in other
situations, by and large in today's computing environment for most users
the advantages offered by NTFS far outweigh those offered by FAT32.

John

Sunny wrote:

OK, explain how I get (Using Acronis True Image Backup)
"The incremental backup will exceed the 4Gb limit in your
backup file location"

Simple. Acronis doesn't have the brains to split it's backup files into
4 gb chunks. Which is a useful feature the user might want even if it
was being written to an NTFS volume.

Bill in Co wrote:

I formatted a 500 gb drive as a single FAT32 volume using 4kb
cluser size just as an excercise to test if Windows 98se could
be installed and function on such a volume, and it did - with
the exception that it would not create a swap file on such a
volume.

Well, that's really nice. No swap file? Great.

I created a swap file on a second hard drive that had a smaller-sized
volume.

(Plus the other utilities you said that won't work anymore
(like the much faster version of Defrag from WinME).

Those utilities will work on volumes that have around 25 to 30 million
clusters. Again, this far exceeds the upper limit of 4.2 million that
microsoft claimed was the max number of clusters for a FAT32 volume.

And as Chen mentions, yes - the *first* directory command
on FAT32 volumes with a high cluster-count does take a few
minutes (but not successive directory commands).

A few *minutes*???? Are you kidding me???
THAT is totally unacceptible.

Sure, but that's if you've booted the machine into DOS.

I really don't remember if it took that long to view the drive in
explorer under win-98 or not, and there is no such delay to view the
drive under XP. So the delay is not so much the fault of the file
system as it is the overlying OS and the strategy it uses to compute
free space - and whether or not it has to compute free space each and
every time the drive is viewed, or whether it can save that info
somewhere on the drive without having to recompute it periodically.

With all the things you've mentioned it sure seems like there is
a price to pay.

When it comes to running XP on a FAT32 drive, the only price is a max
file size of 4 gb. The benefits are a more accessible and portable file
system, more third-party tools and utilities, faster performance,
arguably better / simpler data recoverability (and I don't mean the
creation of .chk files when I say that).

Oh yeah, not the least of which is you can't *ever* have a file
larger than 4 GB (this can be a pit of a PIA for some photo,
video, and disk imaging work)

Like I said earlier, I've seen Adobe Premier CS3 on an XP system running
on a FAT32 drive create large video files by segmenting the output
across multiple 4 gb files automatically.

What I found in my testing that either in DOS or under Win-98,
that the first dir command (or explorer-view) is instantaneous
as long as the number of clusters doesn't exceed 6.3 million.
This equates to a FAT size of about 25 mb.

Which is a LONG ways from the 500 MB mentioned.

6.3 million clusters, at 32 kb each, results in a 200 gb volume, which
isin't a LONG way from 500 gb.

If you want the first DOS dir command to be instantaneous, limit the
number of clusters to be 6.3 million (max volume size = 200 gb, 32kb
cluster size). If you can tolerate the first dir to be up to several
minutes, then DOS is compatible with many millions of clusters on a
FAT32 drive - at least 120 million.

If running win-98 and you want all your tools and diagnostic programs to
run, limit the number of clusters to 30 million (max volume size = 980
gb, 32 kb cluster size).

If running XP, I'm not aware of any limit to the number of clusters
affecting the performance of the volume or latency of any drive
operation.

On 10/18/2010 11:01 PM, Philo Pastry wrote:
John John - MVP wrote:

People working with video editing and multimedia files often run
across this 4GB file limitations. Backup/imaging utilities also
often run into problems caused by this file size limitation,

About 3 years ago I installed XP on a 250 gb FAT-32 partitioned hard
drive and installed Adobe Premier CS3. It had no problems creating
large video files that spanned the 4 gb file-size limit of FAT32.

Wow! How absolutely unbeleivable! Now you are telling us that you
broke the binary limits of the FAT32 file system! The BS never
stops...what next?

On 10/19/2010 10:01 AM, Philo Pastry wrote:
Sunny wrote:

OK, explain how I get (Using Acronis True Image Backup)
"The incremental backup will exceed the 4Gb limit in your
backup file location"

Simple. Acronis doesn't have the brains to split it's backup files into
4 gb chunks. Which is a useful feature the user might want even if it
was being written to an NTFS volume.

Splitting a file in multiple segments of less than 4GB and then saying
that you created files greater than 4GB on FAT32 is just you trying to
spread more of your lies and BS! You just never give up with your nonsense!

mm wrote:

I'll say this. At first when win98FE crashed, I would find files
that were missing

Which proves my point.

How long ago does your recollection date to?

Win-98, first edition? So we are talking about 10, 12 years ago?
That's when many people formed their impressions of win-98 and FAT32,
back when you might have had 8 or 16 mb of system ram, and when
motherboards and video cards and drivers and application software were
barely functional for anything beyond 30 minutes of operation.

Microsoft came out with XP when the reliability and performance of PC
hardware took a major improvement turn in late 2002 / early 2003, when
PC's had 256 if not 512 mb of ram and hard drives started to do their
own internal error correction and began to have descent-sized internal
cache buffers.

Of course, millions of home XP-pc's were soon used as botnet trojans
because XP was designed to be used by corporations, managed by IT staff,
behind hardware firewalls and other sophisticated network appliances,
but none of that sank in to most people - because XP was the emporer
with no clothes from 2002 though late 2006 at least.

Or, if you've installed DOS first on an FAT32 drive, and then
install XP as a second OS, you can have a choice at boot-up to
run DOS or XP.

Why not just put all the dos files in the XP partition, and use
a dos boot disk to boot to that?

Who wants to mess with a dos boot disk?

On some of my XP systems, I start with a large drive, divide it up into
the volumes I want, format all volumes as FAT32 with a custom-selected
cluster size, and then I install DOS 7.1 so that the drive boots into
DOS on C drive. I then install XP onto C as well, and when the system
boots I get a menu asking if I want to boot into DOS or XP. What could
be simpler or more ergonomic than that?