FAT 32 to NTFS

[Anomaly]

After much consideration based on information in the original thread "NTFS
to FAT 32 (dated Oct. 22 '04 10:53pm CST) and other sources, I now
understand that the limitations I felt existed in NTFS
aren't quite what I imagined them to be. Thanks for all the responses That
being said, I would like to impose yet once more with another few questions:

1) Since converting existing FAT 32 volumes via windows "convert" command
doesn't produce the same performance benefits as an initially NTFS formatted
volume, is it better to wait to convert my C:\ partition to NTFS until I
have time to re-format to NTFS (which would require re-installing all apps,
etc.), or would using a third party program such as BING provide the
benefits that the "convert" command alone cannot, especially since BING
provides the ability to "slide" the data into proper alignment in order to
accomodate 4kb clusters before using Window's "convert" command to partition
to NTFS? IOW, is the cluster size issue the only limiter to full performance
benefits when converting an existing FAT 32 partition via windows "convert"?

2) There are other systems in my small network that I will not be converting
to NTFS, some XP Pro and some 9x (I understand that 9x systems will not be
able to read the NTFS drives...I assume that the NTFS systems can read the
9x FAT systems). Other than the file size limitation, are there other
caveats that may exist between the NTFS and the non-NTFS machines?

3) Are there any caveats that I should be aware of? The machines I will be
converting to NTFS are my main systems, with which I run my business and
also use for various other tasks, including video (editing, recording,
transfering, burning, etc.) recording Internet audio, image editing, and
other tasks.
Should I expect a noticeable reduction in performance?

------------------------------

A comment:
After the conversations in the original thread regarding partition imaging,
I dusted
off Acronis 7 (I've been using DI 2002 and Ghost 2000) and it seems that it
will serve my purposes nicely, including the image restoration and rescue
booting aspects. The only thing I don't like about it is that it doesn't
accurately estimate the resulting image file size and it doesn't compress
the files to the smaller file sizes that DI and Ghost do (the reason I
stopped using TI...) .

I *do* appreciate the fact that, unlike Ghost and DI, it doesn't limit the
image file sizes to 2GB. I just created an image of my C:\ partition and, to
my surprise, the resulting image was an "unsplit" 4.3 GB!! You can, of
course, specify a point at which you want the
file to split.

Anyway, thanks again for all the input, and any further comments, advice or
tips are welcome.

Thanks,
Anom

 

[J. Clarke]

After much consideration based on information in the original thread "NTFS
to FAT 32 (dated Oct. 22 '04 10:53pm CST) and other sources, I now
understand that the limitations I felt existed in NTFS
aren't quite what I imagined them to be. Thanks for all the responses That
being said, I would like to impose yet once more with another few
questions:

1) Since converting existing FAT 32 volumes via windows "convert" command
doesn't produce the same performance benefits as an initially NTFS
formatted volume,

It doesn't? I've not heard that before.

is it better to wait to convert my C:\ partition to NTFS
until I have time to re-format to NTFS (which would require re-installing
all apps, etc.), or would using a third party program such as BING provide
the benefits that the "convert" command alone cannot, especially since
BING provides the ability to "slide" the data into proper alignment in
order to accomodate 4kb clusters before using Window's "convert" command
to partition to NTFS? IOW, is the cluster size issue the only limiter to
full performance benefits when converting an existing FAT 32 partition via
windows "convert"?

2) There are other systems in my small network that I will not be
converting to NTFS, some XP Pro and some 9x (I understand that 9x systems
will not be able to read the NTFS drives...I assume that the NTFS systems
can read the 9x FAT systems). Other than the file size limitation, are
there other caveats that may exist between the NTFS and the non-NTFS
machines?

What leads you to believe that a Windows 98 machine cannot read an NTFS
volume over a network share? The client program does not see the
filesystem structure on the host drive, just the network file system. If
you pull one of those drives out of the XP machine and install it in the 9x
machine then the 9x machine will not be able to read it, but as long as
it's installed in the XP machine and the 9x machine is accessing it across
the network, there will be no problem.

 

[Bob Willard]

After much consideration based on information in the original thread "NTFS
to FAT 32 (dated Oct. 22 '04 10:53pm CST) and other sources, I now
understand that the limitations I felt existed in NTFS
aren't quite what I imagined them to be. Thanks for all the responses That
being said, I would like to impose yet once more with another few questions:

1) Since converting existing FAT 32 volumes via windows "convert" command
doesn't produce the same performance benefits as an initially NTFS formatted
volume, is it better to wait to convert my C:\ partition to NTFS until I
have time to re-format to NTFS (which would require re-installing all apps,
etc.), or would using a third party program such as BING provide the
benefits that the "convert" command alone cannot, especially since BING
provides the ability to "slide" the data into proper alignment in order to
accomodate 4kb clusters before using Window's "convert" command to partition
to NTFS? IOW, is the cluster size issue the only limiter to full performance
benefits when converting an existing FAT 32 partition via windows "convert"?

2) There are other systems in my small network that I will not be converting
to NTFS, some XP Pro and some 9x (I understand that 9x systems will not be
able to read the NTFS drives...I assume that the NTFS systems can read the
9x FAT systems). Other than the file size limitation, are there other
caveats that may exist between the NTFS and the non-NTFS machines?

3) Are there any caveats that I should be aware of? The machines I will be
converting to NTFS are my main systems, with which I run my business and
also use for various other tasks, including video (editing, recording,
transfering, burning, etc.) recording Internet audio, image editing, and
other tasks.
Should I expect a noticeable reduction in performance?

------------------------------

A comment:
After the conversations in the original thread regarding partition imaging,
I dusted
off Acronis 7 (I've been using DI 2002 and Ghost 2000) and it seems that it
will serve my purposes nicely, including the image restoration and rescue
booting aspects. The only thing I don't like about it is that it doesn't
accurately estimate the resulting image file size and it doesn't compress
the files to the smaller file sizes that DI and Ghost do (the reason I
stopped using TI...) .

I *do* appreciate the fact that, unlike Ghost and DI, it doesn't limit the
image file sizes to 2GB. I just created an image of my C:\ partition and, to
my surprise, the resulting image was an "unsplit" 4.3 GB!! You can, of
course, specify a point at which you want the
file to split.

Anyway, thanks again for all the input, and any further comments, advice or
tips are welcome.

Thanks,
Anom

NTFS is a more reliable filesystem than FAT, in that files are less likely
to be corrupted by OS crashes and power failures.

On a network, the file systems are masked by the OSs. On my home LAN, I
have XP Pro, XP HE, W2K PRO, and W9x PCs; with mixtures of NTFS, FAT32,
and FAT16 filesystems. And, all of those PCs can read and write all of
those filesystems.

IOW, XP and W2K OSs can access all of those filesystems on their local HDs
and on remote HDs; W9x OSs can only access FAT32/FAT16 filesystems on their
local HDs, but they can access all of those filesystems on remote HDs.

If you have data that matters, then you should protect that data by running
backup regularly; and, create *and test* a restore procedure to get that
data back. Once you have backup/restore under control, migration from FAT
to NTFS should be easy (albeit somewhat time-consuming) -- but, make sure
the backup/restore app you pick can restore to a different partition and
to a different filesystem.

 

[Anomaly]

It doesn't? I've not heard that before.

This is from XP Help & Support:
--------------------------------------------------------
a.. Volumes converted from FAT to NTFS lack some performance benefits
compared to volumes initially formatted with NTFS. On converted volumes, the
MFT might become fragmented. In addition, on converted boot volumes, NTFS
permissions are not applied after the volume is converted.
--------------------------------------------------------

And here is an article addressing the "slide" function in BING:

http://aumha.org/win5/a/ntfscvt.htm

What leads you to believe that a Windows 98 machine cannot read an NTFS
volume over a network share?

I just incorrectly assumed it. Thanks for setting me straight!

 

[Anomaly]

NTFS is a more reliable filesystem than FAT, in that files are less likely
to be corrupted by OS crashes and power failures.

On a network, the file systems are masked by the OSs. On my home LAN, I
have XP Pro, XP HE, W2K PRO, and W9x PCs; with mixtures of NTFS, FAT32,
and FAT16 filesystems. And, all of those PCs can read and write all of
those filesystems.

IOW, XP and W2K OSs can access all of those filesystems on their local HDs
and on remote HDs; W9x OSs can only access FAT32/FAT16 filesystems on
their
local HDs, but they can access all of those filesystems on remote HDs.

Thanks for the info, Bob. That clears things up a bit.

If you have data that matters, then you should protect that data by
running
backup regularly; and, create *and test* a restore procedure to get that
data back. Once you have backup/restore under control, migration from FAT
to NTFS should be easy (albeit somewhat time-consuming) -- but, make sure
the backup/restore app you pick can restore to a different partition and
to a different filesystem.
--

I agree and am fanatical about backing my data up. Several "in program" back
ups and full partition images are a habit with me.

Thanks again!

 

[Andy Lee]

This is from XP Help & Support:

In terms of performance issues that may be true but can be easily
fixed using any of the 3rd party defragment programs

In addition, on converted boot volumes, NTFS
permissions are not applied after the volume is converted.

This is not a performance issue as such and again If the disk was
FAT32 originally it would not have had any security permissions anyway
and one of the good reasons for converting to NTFS especially on a
shard machine is the ability to aadd such permissions after the
conversion.

 

[Anomaly]

In terms of performance issues that may be true but can be easily
fixed using any of the 3rd party defragment programs

My understanding of the potential problems of using the "convert" command to
convert a data filled drive is as quoted from the article I posted the URL
for:

"What happens is that FAT32 partitions formatted by most Windows versions
except Windows XP itself (and possibly Windows 2000) have an odd multiple of
2 kilobytes in the "system" sectors before the data area, where the File
Allocation Tables themselves and clustering start. Therefore, clusters 4 KB
in size are not aligned on 4 KB boundaries, as NTFS will want. CONVERT.EXE,
finding it cannot use 4K clusters, gives up and makes the clusters only 512
bytes (one half KB) instead. (For a table of the varying default cluster
sizes used by FAT16, FAT32, and NTFS for partitions of varying sizes..."

This article further states that BING's "slide" function will alleviate this
issue, as it "slides" the data to the correct position to accomodate 4kb
clusters rather than 512 clusters, which, apparently, creates a performance
issue.

This is not a performance issue as such and again If the disk was
FAT32 originally it would not have had any security permissions anyway
and one of the good reasons for converting to NTFS especially on a
shard machine is the ability to aadd such permissions after the
conversion.

Agreed. That was just part of the same copy and pasted paragraph.

 

[Gary L.]

In terms of performance issues that may be true but can be easily
fixed using any of the 3rd party defragment programs

However, the conversion program results in a default cluster size of
512 bytes, which may not be ideal in terms of performance. I haven't
seen any option to change this with a command line option. When you do
a clean format as NTFS, the default cluster size is 4k bytes, which
may result in better performance and reduced file fragmentation.
- -
Gary L.
Reply to the newsgroup only