Virtual Machine and NTFS

On 10/17/2010 11:15 AM, Philo is wrong (98Guy) wrote:

Additionally , since many people are now storing movies and such
with large files sizes, fat32 cannot handle any files over 4 gigs.

While that is true, it rarely comes up as a realistic or practical
limitation for FAT32. The most common multimedia format in common use
is the DVD .VOB file, which self-limit themselves to be 1 gb.

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, it is a very practical
limitation of FAT32 and one that users often experience, people often
post asking about this problem.




The only file type that I ever see exceed the 4 gb size are virtual
machine image files, which you will not see on a win-9x machine but you
would see on an XP (or higher) PC running VM Ware, Microsoft Virtual PC,
etc. But 4 gb should be enough to contain a modest image of a virtual
windows-98 machine.

Additionally, XP is *deliberately* crippled in that it cannot create
a fat32 partition larger than 32 gigs.

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 and for performance reasons Microsoft decided to draw the
line at 32GB for FAT32 volumes.



[snip...]

The extra sophistication and transaction journalling performed by NTFS
reduces it's overall performance compared to FAT32. So for those who
want to optimize the over-all speed of their PC's, FAT32 is a faster
file system than NTFS.

That is not completely true. FAT32 is generally faster on smaller
volumes but on larger volumes NTFS is faster. This is why Microsoft
decided to put a limit of 32GB on the size of volumes which can be
formatted to FAT32 on Windows 2000 and later NT operating systems, the
size of the FAT on larger volumes is a hindrance on performance and
Microsoft decided that 32GB was an acceptable cut off point for FAT32
volumes.



I do a lot of computer repair work and have seen entire fat32
file systems hosed by a bad shut down. The user, in attempt to
fix things has typically run scandisk and *sometimes* has ended
up with a drive full of .chk files.

That's another common myth about FAT32 - that the appearance of many
.chk files must mean that it's inferior to NTFS.

While it might look untidy, the mere existance of those .chk files don't
mean anything about how compentent or capable FAT32 is, and it's not
hard to just delete them and get on with your business.

You did not say in your example if the user's drive and OS was operable
and functional despite the existance of those .chk files.

These .chk files are lost file segments that the scandisk utility could
not recover, damaged data! That the operating system remains "operable"
is a laughable excuse if user data is lost! Open a user file on a FAT32
drive then while the user is making changes to his file yank the plug on
the machine and tell us how well (or not) the user data survives such an
event!




What I am saying is that NTFS is considerably more resilient.

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.

Citations please...

John

In message , glee
writes:
[]
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.

That's what I thought. (Anyone else know?)

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.

Yes, I thought so too (-:. [What's an "Addition" in this context?]
--
J. P. Gilliver. UMRA: 1960/1985 MB++G.5AL-IS-P--Ch++(p)Ar@T0H+Sh0!:`)DNAf

"The people here are more educated and intelligent. Even stupid people in
Britain are smarter than Americans." Madonna, in RT 30 June-6July 2001 (page
32)

Virtual PC 2004 SP1

http://www.microsoft.com/downloads/e...displaylang=en

System Requirements

Supported Operating
Systems:Windows 2000 Service Pack 4
;Windows Server 2003,
Standard Edition (32-bit x86);
Windows XP Service Pack 2

Processor: Athlon®, Duron®, Celeron®, Pentium® II, Pentium III, or Pentium 4
Processor speed: 400 MHz minimum (1 GHz or higher recommended)

RAM: Add the RAM requirement for the host operating system that you will be
using
to the requirement for the guest operating system that you will be using.
If you will be using multiple guest operating systems simultaneously,
total the requirements for all the guest operating systems that you need to
run simultaneously.

Available disk space: To determine the hard disk space required,
add the requirement for each guest operating system that will be installed.

Virtual PC 2004 SP1 runs on:
Windows 2000 Professional SP4,
Windows XP Professional,
and Windows XP Tablet PC Edition.

John John - MVP Win The Debate Hands Down!

Philo Surrenders wrote:
philo top-poasted:

I have probably over 200 years worth of FAT32 hard-drive usage
experience

This is how Philo surrenders an argument. Watch:

200 years of experience...
ok you win, my computer experience only goes back to 1968.

Because he didn't quote the rest of my statement:

(if you add up all the years of service of various FAT32
drives that I've installed, maintained, touched in one way
or another, etc) over the past dozen years.
How stupid!!
You truely should just keep quiet and leave with any dignity that may
possibly remain.
Buffalo

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.

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:02:22 +0100, "J. P. Gilliver (John)"
wrote:

In message , mm
writes:
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

If you're actually starting from scratch (which "have all the parts"
suggests to me that you are) anyway, received wisdom here seems to be

I had everything but the harddrive, so yeah, I'm starting from scratch
on that. Thanks. There is a lot of thread to read. Been very busy,
but I'll have time soon, I think. I plan to get back to you.

that you should set it up as FAT anyway: the alleged benefits of NTFS
being largely moot for the single home user, and XP will operate
perfectly happily under FAT.

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.

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.

Raymond Chen talks about this he

Windows Confidential A Brief and Incomplete History of FAT32
http://technet.microsoft.com/en-us/m...fidential.aspx


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.

Of course it's a fallacy and no one here said that the entire FAT had to
be loaded in memory, what you don't understand is that the FAT is
extensively accessed during disk operations and having it cached in the
RAM is one of the most efficient methods of speeding up disk operations.
You on the other hand seem to think that having the FAT as large as
possible and then page it to disk is a smart thing to do... Why else
would anyone format a 500gb FAT32 volume with 4K clusters? What exactly
do you think that you will gain with this formatting scheme that will be
so great as to dismiss the whopping performance hit provided by a 500MB FAT?

John

John John - MVP wrote:
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.

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.

Raymond Chen talks about this he

Windows Confidential A Brief and Incomplete History of FAT32
http://technet.microsoft.com/en-us/m...fidential.aspx


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.

Of course it's a fallacy and no one here said that the entire FAT had to
be loaded in memory, what you don't understand is that the FAT is
extensively accessed during disk operations and having it cached in the
RAM is one of the most efficient methods of speeding up disk operations.
You on the other hand seem to think that having the FAT as large as
possible and then page it to disk is a smart thing to do... Why else
would anyone format a 500gb FAT32 volume with 4K clusters? What exactly
do you think that you will gain with this formatting scheme that will be
so great as to dismiss the whopping performance hit provided by a 500MB
FAT?

John

The idea of a having a super large, 500MB FAT, (that often has to be
accessed sequentially, instead of in a B-tree), I find *wholly* repugnant!!

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.
-----------

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

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.

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.

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.

Chris mentions in his blog how data which was recovered by
Scandisk should be treated as suspicious.

Recovered - as in the creation of .chk files? Like I said, I've never
had a use for them in the first place.

The NTFS method is to use journaling instead to guarantee
atomicity of the write operation, to guarantee that the write
is complete and free of errors.

No. You can still have erroneous write operations under NTFS and FATxx,
and the OS is supposed to retry the operation until the write succeeds.
If the write occurs during a system crash or power failure, there can be
no re-try. Journalling is meant to detect an erroneous write event that
was never corrected / completed and restore the file system to the
previous state before the event, even if some (or most, or all) user
data was in fact written to the drive prior to the failure but was not
journaled. That's where FAT32 will retain the user data, but it will be
lost under NTFS.

And as Quirke says, under FAT you can have a mis-match between the
file-size as recorded in the FAT vs the length of the file-chain, and
for which is easily fixable.

He talks a lot more about the relative complexity of the actual
structure of NTFS compared to FAT32, the lack of proper documentation,
of diagnostic and repair tools, and the idea that the MFT may not be as
recoverable or redundant as the dual FATs of FAT32.

What is especially interesting is that a faulty FAT32 volume can be
mounted and inspected with confidence that it won't be immediately
"attacked" by unknown or uncontrolled read/write operations during it's
mounting as a faulty NTFS volume would be by NTFS.SYS. You basically
have to trust that NTFS.SYS knows what it's doing, and that it knows
best how to recover a faulty NTFS volume, and if it places more value on
file recovery vs file-system integrity (there is a huge difference
between the two).

I prefer the later and I am sure that most reading here would
prefer to keep the previous good version of the file that
experienced a write failure rather than have a the file system
keep a newer copy of the file when it is incomplete or corrupt!

That depends on how large your "atoms" are in your "atomicity" analogy.

I have been burned and shake my head many times because I've seen data
lost on NTFS volumes because of the interplay between journalling and
write-caching after unexpected system shutdown events.

NTFS is more than journalling. There's the organizational structure or
pattern as to how you store files and directories, and there's the event
or transaction-monitoring and logging operations above that. You could
theoretically have journalling performed on a FAT32 file structure.

But like I said, NTFS is more convoluted and secretive than it needs to
be in the way it stores files on a drive (journalling or no
journalling).