NTFS scanning directories painfully slow

  • Thread starter Thread starter snotty2000
  • Start date Start date
S

snotty2000

Hi All,

I am having a problem where my NTFS volumes are taking a very long
time to do directory scanning tasks.

For example, a directory containing ~2500 files will take twice as
long to show the files in explorer than a FAT32 directory containing
~15000 files.

Even a directory with only 20 or so movie files in it will take ~30
seconds before it retuns control back to the explorer window and show
the listing.

It seems to affect some directories and not others.

I have disabled indexing services and last accessed date setting.

This has happened on 3 different hard drives, a Western Digital,
Seagate, and Maxtor.

Anyone have any ideas?
 
If you defrag the drive and look at the report what is the status o
your mft? You will find this under volume information. It sounds lik
it may be fragmented into multiple parts.

Utilities like perfect disk and diskeeper can do a boot time defra
that will consolidate the mft


-
wandere
 
Hi All,

I am having a problem where my NTFS volumes are taking a very long
time to do directory scanning tasks.

For example, a directory containing ~2500 files will take twice as
long to show the files in explorer than a FAT32 directory containing
~15000 files.

Even a directory with only 20 or so movie files in it will take ~30
seconds before it retuns control back to the explorer window and show
the listing.

It seems to affect some directories and not others.

I have disabled indexing services and last accessed date setting.

This has happened on 3 different hard drives, a Western Digital,
Seagate, and Maxtor.

Anyone have any ideas?


download the eval version of PerfectDisk (www.raxco.com) and analyze
the disk. Do a reboot defrag (I _think_ the eval version will let you
do that.

I have no relationship with Raxco other than being a long-time
satisfied customer.
 
I tried defraging the mft a while ago, but it didn't help the problem.

Maybe it's a hardware problem in my system somewhere or something.

Whatever it is, it's making me seriously think about converting to
fat32 on those drives.
 
*I tried defraging the mft a while ago, but it didn't help the
problem.

Maybe it's a hardware problem in my system somewhere or something.

Whatever it is, it's making me seriously think about converting to
fat32 on those drives. *

this has nothing to do with fragmenting. It's NTFS's security crap. I
get the same thing and it's really, really annoying. If Fat32 could
support 80 gigs I'd use that instead.
 
I tried defraging the mft a while ago, but it didn't help the problem.

Maybe it's a hardware problem in my system somewhere or something.

Whatever it is, it's making me seriously think about converting to
fat32 on those drives.


Were you _able_ to defag the $MFT ?


Perfectdisk can, during a reboot-defrag.
 
this has nothing to do with fragmenting. It's NTFS's security crap. I
get the same thing and it's really, really annoying. If Fat32 could
support 80 gigs I'd use that instead.


Have you looked in tvent viewer to see if there are any system error
messages ? Soft disk errors will show up there.
 
Maybe? Turn off indexing service? Turn off short filename or 8.3 name
creation? Turn off LastAccessDate? It might speed things up a bit...
but then it may not make any noticable difference. Just ideas.

John
 
When we migrated from Windows 95 clients to Windows 2000 clients a few years
ago we had a similar issue. I agree with one respondent who says it's just
the NTFS crap, except I wouldn't describe it as crap, just annoying. We
used to open a networked (NTFS) file folder containing some 50,000 files in
a few seconds with the Windows 95 client, and the same folder being browsed
from a Windows 2000 client would take upwards of a minute to open ... users
were not impressed with this 'improvement' we were giving them. Not sure
if this is the same as your problem, but it is similar, and we just live
with it. Tests showed an NT4 Workstation client performed about as badly as
the 2000 client. I put it down to the fact that both W2000 client and
server were communicating over a secure channel, whereas the 95 client
wasn't.

PJ
 
Back
Top