| TIP: Click on subject to list as thread! | ANSI |
| echo: | |
|---|---|
| to: | |
| from: | |
| date: | |
| subject: | Re: Copy From/To drives |
From: "Glenn Meadows"
Thanks, appreciate that link. I'm still investigating what's going on.
I'm going to move the drive to a different computer, and re-network them
back to the audio systems. The copying is NOT being done over the network,
btw, being done right at the machine that they're hard connected to.
It gets really weird. Sometimes, when burning a CD at a measly 4X speed,
the burn will crash, because the HD can't keep up with the CD drive. If I
do the move off and back, then do the burn again, it works fine. I've run
a Chkdsk, and all appears to be OK.
The Z drive, has about 24gig free out of the 160 (149 formatted). What I
might actually do, to see if this is a FAT32 vs NT problem, is get another
of these drives, format it as NTFS (don't know why I didn't do that to
start with, but I didn't), and just copy all 120 gig across to the new
drive, and reformat the old one to NTFS and see if that clears it all up.
The Convert doesn't seen to want to happen, as the drive is USB, and system
wants to do it during the next reboot, and I guess, the drive is not
visible during that part of the boot, so the conversion never gets done.
--
Glenn M.
"Rich Gauszka" wrote in message
news:41507f9d$1{at}w3.nls.net...
>
> "Glenn Meadows" wrote in message
> news:41506353{at}w3.nls.net...
> > Got this really weird observation.
> >
> > Copy a 2.8 gig audio folder (mixture of large files (music) and small
> > (waveform display files)) from one USB 2 160 gig WD HD to another.
Drive
> > Z
> > is formatted Fat32, and Drive Y is formatted NTFS.
> >
> > Going from Z to Y (FAT32 to NTFS), it takes 7-12 minutes. If I copy
that
> > folder BACK to Z (NTFS to FAT32) the copy takes about a minute or so.
> > Copy
> > it back once again (Z to Y), it takes about 4 minutes. Once again, back
> > to
> > Z from Y, it's a minute or less.
> >
> > Is Fat32 THAT inefficient on copy functions?
> >
> > These are identical drives, external USB2 drives. Seems really odd to
me.
> > The audio files are interleaved, and were recorded as the drive filled
up
> > from empty, so fragmentation should be minimal.
> >
> > Thoughts, comments, etc?
> >
> >
>
> I would have expected a speed up when writing large files to an NTFS
> partition. The opposite of what you are seeing
>
> http://www.microsoft.com/whdc/system/winpreinst/ntfs-preinstall.mspx
> NTFS Performance
>
> Disk subsystem performance is a critically important factor in overall
> system performance, and NTFS is generally believed to be slower than FAT.
> However, with a correctly created NTFS volume, NTFS performance
> optimizations, and improved disk defragmentation, NTFS performance
> (including the extra "journaling") is equivalent to FAT on
small disks and
> is faster than FAT on large disks.
>
> Furthermore, NTFS performs well when reading, writing, and mounting large
> volume sizes. FAT32 performance is reduced for volumes larger than 32 GB
in
> two areas:
>
> . Boot time with FAT32 is increased because of the time required to
> read all of the FAT structure. This must be done to calculate the amount
of
> free space when the volume is mounted.
>
> . Read/write performance with FAT32 is affected because the file
> system must determine the free space on the disk through the small views
of
> the massive FAT structure. This leads to inefficiencies in file
allocation.
>
>
> The following sections describe optimizations in Windows XP for disk
layout,
> Master File Table location, and cluster alignment for NTFS volumes.
>
>
--- BBBS/NT v4.01 Flag-5
* Origin: Barktopia BBS Site http://HarborWebs.com:8081 (1:379/45)SEEN-BY: 633/267 270 @PATH: 379/45 1 396/45 106/2000 633/267 |
|
| SOURCE: echomail via fidonet.ozzmosis.com | |
Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.