From: "Rich" 

This is a multi-part message in MIME format.

------=_NextPart_000_0060_01C338FE.064C53E0
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

   Let's be accurate.  I posted a message to Ellen telling her about the =
CONVERT command she can use on her Windows 2000 machine.  Bob Comer =
replied one portion of which was the statement "That said, I've never
= known convert to barf enough to kill things."  You replied to that =
statement alone with "Unlike converting under XP, where most
conversions = wind up with 512-byte clusters, and piglike disk
performance."  Now, do = you need to have your bogus claims identified
for you?  Let's assume so.

  1.. Your comparison to conversion on Windows XP, presumably to Ellen's =
Windows 2000.  Why did you mention Windows XP at all?
  2.. Your false claim about cluster size is exactly counter to the =
information on the web page to which you later referred in order to =
defend your false statement.  Specifically, that page claims that = cluster
size is 512 when converting on Windows 2000 and that it is the = FAT
cluster size or 4K, whichever is smaller, on Windows XP.
  3.. Your claim of "piglike disk performance".  Presumably this is the =
"technical detail" which you asked for of others.  As should be
obvious = from the page to which you referred, the file location on disk
and = fragmentation is the same as the FAT file layout.  The overhead of
the = fragmentation and smaller cluster size in general is unchanged by the
= conversion on Windows 2000 and reduced on Windows XP.

If your concern was honesty and to be helpful you would have mentioned =
that the conversion on Windows XP produces better results than on = Windows
2000 but that for even better performance you should backup, = reformat,
and restore.

   As for your performance comparison of NTFS to FAT32, NTFS has higher =
overhead for metadata operations like creating, renaming, deleting, even =
extending files because metadata changes are logged on NTFS but not FAT. =
 As you noted, this is the tradeoff journalling filesystems make for =
robustness.

Rich

  "Frank Haber"  wrote in message =
news:3ef65c97$1{at}w3.nls.net...
  I think what I said was forwards:

  o Formated with previous opsys

  o Bad luck or whatever causes format to be "unaligned," whatever =
boundaries
  that refers to.

  o Convert with XP.

  o Get 512-byte clusters.

  I saw slow  moves/deletes/copies of large files, with write operations =
slowed
  down more than read.  I was dealing with 5-15G logical volumes at that =
point.
  With an e database of 8000 records/30 fields, a reindex with =
NTFS/4k-clusters
  was 5% slower than FAT, if that.  Half-k clusters were about 20% =
slower.  The
  data started out unfragmented.

  On a fragmented disk, SCANDISKs were rattly, but only a little slower =
with the
  small clusters.  The percieved response was down significantly, =
though.  Since
  the client was complaining that NTFS was "more sluggish," I thought a =
few
  numbers were appropriate.  The client accepted the conversion, and was =
glad to
  get the increased crash resistance.

  What do you have?

------=_NextPart_000_0060_01C338FE.064C53E0
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable








   Let's be
accurate.  I =
posted a=20
message to Ellen telling her about the CONVERT command she can use on = her=20
Windows 2000 machine.  Bob Comer replied one portion of which was = the=20
statement "That said, I've never = known=20
convert to barf enough to kill things."  You
replied to that =

statement alone with "Unlike converting under XP, where most
conversions = wind up=20
with 512-byte clusters, and piglike disk performance."  Now,
do you = need to=20
have your bogus claims identified for you?  Let's assume =
so.
 

  Your comparison to conversion on =
Windows XP,=20
  presumably to Ellen's Windows 2000.  Why did you mention Windows =
XP at=20
  all?
  Your false claim about
cluster size is =
exactly=20
  counter to the information on the web page to which you later referred =
in=20
  order to defend your false statement.  Specifically, that page =
claims=20
  that cluster size is 512 when converting on Windows 2000 and that it =
is the=20
  FAT cluster size or 4K, whichever is smaller, on Windows =
XP.
  Your claim of "piglike disk =
performance". =20
  Presumably this is the "technical detail" which you asked for of =
others. =20
  As should be obvious from the page to which you referred, the file =
location on=20
  disk and fragmentation is the same as the FAT file layout.  The =
overhead=20
  of the fragmentation and smaller cluster size in general is unchanged =
by the=20
  conversion on Windows 2000 and reduced on Windows
XP.
 
If your concern was honesty and to be =
helpful you=20
would have mentioned that the conversion on Windows XP produces better = results=20
than on Windows 2000 but that for even better performance you should = backup,=20
reformat, and restore.
 
   As for
your performance =
comparison of=20
NTFS to FAT32, NTFS has higher overhead for metadata operations like = creating,=20
renaming, deleting, even extending files because metadata
= changes are=20
logged on NTFS but not FAT.  As you noted, this is the tradeoff =
journalling=20
filesystems make for robustness.
 
Rich
 

  "Frank Haber" <frhaber{at}N0SPMrcn.com>">mailto:frhaber{at}N0SPMrcn.com">frhaber{at}N0SPMrcn.com>
=
wrote in=20
  message news:3ef65c97$1{at}w3.nls.net...I=20
  think what I said was forwards:o Formated with previous =
opsyso=20
  Bad luck or whatever causes format to be "unaligned," whatever=20
  boundariesthat refers to.o Convert with
XP.o Get =
512-byte=20
  clusters.I saw slow  moves/deletes/copies of
large files, =
with=20
  write operations sloweddown more than read.  I was dealing =
with 5-15G=20
  logical volumes at that point.With an e database of 8000 =
records/30=20
  fields, a reindex with NTFS/4k-clusterswas 5% slower than FAT, if=20
  that.  Half-k clusters were about 20% slower. 
Thedata =
started=20
  out unfragmented.On a fragmented disk, SCANDISKs were rattly, =
but only=20
  a little slower with thesmall clusters.  The percieved =
response was=20
  down significantly, though.  Sincethe client was complaining =
that=20
  NTFS was "more sluggish," I thought a fewnumbers were =
appropriate. =20
  The client accepted the conversion, and was glad toget the =
increased crash=20
  resistance.What do you
have?

------=_NextPart_000_0060_01C338FE.064C53E0--

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