Win2KP Defrag

[STUBBY]

Archived from groups: microsoft.public.win2000.general (More info?)

Although defragging doesn't make any noticeable improvement in the
"feel" at the keyboard, I still do it once in awhile to make myself feel
productive. I just defragged a flash drive using the standard,
built-in defrag program that comes with Win2kP. On a solid state
drive, position of sectors doesn't matter at all. So why does defrag
do anything?

 

[Guest]

Archived from groups: microsoft.public.win2000.general (More info?)

I have a dual boot WinME/Win2K system and I use the WinME defrag because it
(a) does make a difference (b) can defrag all the hard drives, not just one
at a time (c) has a cool real time display, and (d) is much faster. (Of
course all the hard drive partitions have to be FAT32--NTFS won't work.)

The Win2K defrag is too slow and doesn't seem to do anything.

To answer your question (maybe), it rearranges the sectors so they are in
numerical order. It doesn't know your flash drive is solid state. Remember,
Win2k is old software.

"Stubby" <William.Plummer-NOSPAM-@comcast.net> wrote in message
news:eYudncKxSIOGBSjfRVn-jA@comcast.com...
> Although defragging doesn't make any noticeable improvement in the
> "feel" at the keyboard, I still do it once in awhile to make myself feel
> productive. I just defragged a flash drive using the standard,
> built-in defrag program that comes with Win2kP. On a solid state
> drive, position of sectors doesn't matter at all. So why does defrag
> do anything?

 

[Guest]

Archived from groups: microsoft.public.win2000.general (More info?)

The mistake that most people make is thinking that defragmentation is
something that is occuring at the sector level. Fragmentation in Windows is
something that is occurs at the file system level - at the logical cluster
level. When a file is logically fragmented, it means that there is stored
in the FAT/MFT for that file a series of "extents" - each with a starting
LCN and a number of clusters. To access the file means that for each
extent, a request has to be made to the hard drive controller. If a file is
in 1000 logical fragments, then 1000 logical requests have to be made to the
hard drive controller. Conversely, if a file is logical contiguous, it
means that only 1 logical request has to be made to the hard drive
controller. The performance improvement comes in because you are only
making 1 request - not 1000 requests.

- Greg/Raxco Software
Microsoft MVP - Windows File System

Disclaimer: I work for Raxco Software, the maker of PerfectDisk - a
commercial defrag utility, as a systems engineer in the support department.

Want to email me? Delete ntloader.

"Stubby" <William.Plummer-NOSPAM-@comcast.net> wrote in message
news:eYudncKxSIOGBSjfRVn-jA@comcast.com...
> Although defragging doesn't make any noticeable improvement in the
> "feel" at the keyboard, I still do it once in awhile to make myself feel
> productive. I just defragged a flash drive using the standard,
> built-in defrag program that comes with Win2kP. On a solid state
> drive, position of sectors doesn't matter at all. So why does defrag
> do anything?

 

[STUBBY]

Archived from groups: microsoft.public.win2000.general (More info?)

Greg Hayes/Raxco Software wrote:
> If a file is
> in 1000 logical fragments, then 1000 logical requests have to be made to the
> hard drive controller.
I admit I don't know how NT and following work inside, but I am certain
that DOS did sector-at-a-time. Later versions had a queue of pending
write-operations but nothing coalesed the pending operations.

Conversely, if a file is logical contiguous, it
> means that only 1 logical request has to be made to the hard drive
> controller. The performance improvement comes in because you are only
> making 1 request - not 1000 requests.
The cost of initiating a transfer is very low, insignificant. The cost
of actually executing a transfer is high because you need to wait for
the arm to position to the right cyclinder and for the disk to turn to
the right place. Of course the overhead due to physical movement is
non-existent on a solid-state disk. This is what prompted my original post.

If you are correct, current disk controllers must be able to start a
transfer, wait until it is almost ready to start, look at the disk queue
to see if more contiguous sectors have been added, and update the number
of sectors in the transfer if possible. Some how I don't think they are
this clever, but I could easily be wrong. But this is what it would
take to make defragmenting have an effect on efficiency.

If you could post a URL for how disk controllers work these days, I sure
would like to see it. I have some ideas for performance improvements
that are guaranteed to work but I need to understand all the low level
stuff as it exists today. Thanks.

 

[Guest]

Archived from groups: microsoft.public.win2000.general (More info?)

I'm a file system guy. I have no expertise at all when it comes to hard
drive controllers/hard drives and how they work.

- Greg/Raxco Software
Microsoft MVP - Windows File System

Disclaimer: I work for Raxco Software, the maker of PerfectDisk - a
commercial defrag utility, as a systems engineer in the support department.

Want to email me? Delete ntloader.

"Stubby" <William.Plummer-NOSPAM-@comcast.net> wrote in message
news:GoSdncN4_o3XDyTfRVn-3w@comcast.com...
> Greg Hayes/Raxco Software wrote:
> > If a file is
> > in 1000 logical fragments, then 1000 logical requests have to be made to
the
> > hard drive controller.
> I admit I don't know how NT and following work inside, but I am certain
> that DOS did sector-at-a-time. Later versions had a queue of pending
> write-operations but nothing coalesed the pending operations.
>
> Conversely, if a file is logical contiguous, it
> > means that only 1 logical request has to be made to the hard drive
> > controller. The performance improvement comes in because you are only
> > making 1 request - not 1000 requests.
> The cost of initiating a transfer is very low, insignificant. The cost
> of actually executing a transfer is high because you need to wait for
> the arm to position to the right cyclinder and for the disk to turn to
> the right place. Of course the overhead due to physical movement is
> non-existent on a solid-state disk. This is what prompted my original
post.
>
> If you are correct, current disk controllers must be able to start a
> transfer, wait until it is almost ready to start, look at the disk queue
> to see if more contiguous sectors have been added, and update the number
> of sectors in the transfer if possible. Some how I don't think they are
> this clever, but I could easily be wrong. But this is what it would
> take to make defragmenting have an effect on efficiency.
>
> If you could post a URL for how disk controllers work these days, I sure
> would like to see it. I have some ideas for performance improvements
> that are guaranteed to work but I need to understand all the low level
> stuff as it exists today. Thanks.