From: "Rich" 

This is a multi-part message in MIME format.

------=_NextPart_000_0103_01C33A5B.0155C8E0
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

   The web page to which you referred describes some improvements in =
Windows XP over Windows 2000 for FAT to NTFS conversion.  I made no =
attempt to verify what it says but did not see any reason to dispute the =
statements made on this specific topic.

   The reason the cluster size remains the same is that the conversion =
does not move files.  I suspect it may have to move files from a few =
fixed special locations but in general, everthing stays put.  Since FAT =
allocation could have every file completely fragmented, you can't change =
the size of the fragments without moving files.  The consquence of this =
is that the NTFS cluster size must be the same or smaller than the FAT =
cluster size.

Rich

  "Frank Haber"  wrote in message =
news:3ef7708c{at}w3.nls.net...
  I have no firsthand experience with FAT32=3D=3D>NTFS conversions under =
2000.  And
  you can *help* me by saying just why these conversions don't work out =
as well
  as those done under XP.

  The "technical detail" I hoped for was from your inside perspective, =
on just
  what this mysterious sector-cluster "alignment" thing is, how it fits =
in with
  the various extended-ATA schemes, what the boundaries are, etc.  I'm =
unable to
  see how data alignment would help perfomance on a physical medium with =
varying
  cluster sizes, granularity that bears little relation to cylinders, =
layered
  sector translation schemes, etc.  Lacking that, I'd just like an =
explanation
  of what XP's aligned formatting is supposed to be doing.

------=_NextPart_000_0103_01C33A5B.0155C8E0
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable








   The web
page to which you =
referred=20
describes some improvements in Windows XP over Windows 2000 for FAT to = NTFS=20
conversion.  I made no attempt to verify what it says but did not
= see any=20
reason to dispute the statements made on this specific =
topic.
 
   The
reason the cluster =
size remains=20
the same is that the conversion does not move files.  I suspect it
= may have=20
to move files from a few fixed special locations but in general, = everthing stays=20
put.  Since FAT allocation could have every file completely =
fragmented, you=20
can't change the size of the fragments without moving files. 
The=20 consquence of this is that the NTFS cluster size must be the same or
= smaller=20
than the FAT cluster size.
 
Rich
 

  "Frank Haber" <frhaber{at}N0SPMrcn.com>">mailto:frhaber{at}N0SPMrcn.com">frhaber{at}N0SPMrcn.com>
=
wrote in=20
  message news:3ef7708c{at}w3.nls.net...I
= have no=20
  firsthand experience with FAT32=3D=3D>NTFS conversions under =
2000. =20
  Andyou can *help* me by saying just why these conversions don't =
work out=20
  as wellas those done under XP.The
"technical detail" I =
hoped for=20
  was from your inside perspective, on justwhat this mysterious=20
  sector-cluster "alignment" thing is, how it fits in withthe =
various=20
  extended-ATA schemes, what the boundaries are, etc.  I'm unable =
tosee=20
  how data alignment would help perfomance on a physical medium with=20
  varyingcluster sizes, granularity that bears little relation to =
cylinders,=20
  layeredsector translation schemes, etc.  Lacking that, I'd =
just like=20
  an explanationof what XP's aligned formatting is supposed to be=20
doing.

------=_NextPart_000_0103_01C33A5B.0155C8E0--

--- BBBS/NT v4.01 Flag-4