Minimising defrag for partition copying by XP

[Franklin]

I run XP Pro.

I might need to copy some data files (say 50 GB) from one partition to
another. PerfectDisk's ANALYZE option shows that the files in the
target partition have a lot of directory fragmentation.

Are there any file copiers which do not fragment the target data so
heavily?

 

[Rod Speed]

I run XP Pro.

I might need to copy some data files (say 50 GB) from one
partition to another. PerfectDisk's ANALYZE option shows that
the files in the target partition have a lot of directory fragmentation.

No such animal as 'directory fragmentation'

Are there any file copiers which do not fragment the target data so heavily?

The fragmentation is the result of the state of the destination
drive before the copy happens, not what is used to do the copy.

Time to wake up, smell the coffee, and notice that fragmentation
cant even be detected in a proper double blind trial except in the
most exceptional circumstances and that isnt normally seen with
personal desktop systems.

 

[Franklin]

No such animal as 'directory fragmentation'

Yes, I am not too sure quite what this refers to. It may be just the
confusing way PerfectDisk reports its analysis. Whatever its term it
seems to be represented by green boxes in PerfectDisk and these green
boxes get very splattered around after new files (say 100 MB) have
been downloaded from the Net.

It seems to be some sort of index fragmentation but somehow it is not
shown as part of the MFT or as part of other NTFS metadata.

The fragmentation is the result of the state of the destination
drive before the copy happens, not what is used to do the copy.

Time to wake up, smell the coffee, and notice that fragmentation
cant even be detected in a proper double blind trial except in the
most exceptional circumstances and that isnt normally seen with
personal desktop systems.

I know I know I know! Heh! That's what I understand theory and
common sense say. And yet ...

I find defragging does help. Maybe it's to do with the fact that
many of my disks are too full (85% or more).

Am currently sorting that out and am migrating data. This is why I
posted as I was interested in getting the data into its new position
in as tidy condition as possible.

 

[Arno Wagner]

I run XP Pro.

I might need to copy some data files (say 50 GB) from one partition to
another. PerfectDisk's ANALYZE option shows that the files in the
target partition have a lot of directory fragmentation.

What is "directory fragmentation"?

Are there any file copiers which do not fragment the target data so
heavily?

File placement is the OSes task. If the OS is dumb, then there
is nothing you can do, except maybe after-the-fact defragmentation.

Arno

 

[Rod Speed]

Yes, I am not too sure quite what this refers to. It may be just the
confusing way PerfectDisk reports its analysis. Whatever its term it
seems to be represented by green boxes in PerfectDisk and these green
boxes get very splattered around after new files (say 100 MB) have
been downloaded from the Net.

It seems to be some sort of index fragmentation but somehow it is not
shown as part of the MFT or as part of other NTFS metadata.



I know I know I know! Heh! That's what I understand theory and
common sense say. And yet ...

I find defragging does help.

Bet thats an illusion and you wouldnt be able to pick it in a double blind trial.

Very few situations on a personal desktop system where
the extra seeks between fragments will even be noticeable.

Maybe it's to do with the fact that many of my disks are too full (85% or more).

Nope, that just affects how much fragmentation occurs, and a decent
file system doesnt fragment too badly even at that level, unless the
files being copied to it are a large percentage of that 15% thats free.

Am currently sorting that out and am migrating data.
This is why I posted as I was interested in getting the
data into its new position in as tidy condition as possible.

Thats a file system attribute, not what is used to do the copy.

 

[Franklin]

Bet thats an illusion and you wouldnt be able to pick it in a
double blind trial.

Very few situations on a personal desktop system where
the extra seeks between fragments will even be noticeable.


Nope, that just affects how much fragmentation occurs, and a decent
file system doesnt fragment too badly even at that level, unless
the files being copied to it are a large percentage of that 15%
thats free.


Thats a file system attribute, not what is used to do the copy.

Rod, I was thinking that some copy utilities might use only a single
thread or stream (rather than try and be quick with multiple threads).

I see parms can be set in copiers like this one
http://www.copyhandler.com/en/manual/configuration.html
and I guessed wildly that a copy app for me would not use buffers of
such a size which dump data onto the target drive in a way that a single
buffer-load causes the data to completely fill some clusters and then go
and put the rest of the buffer-data elsewhere. Maybe my wild guess
about what may happen is just too wild!

 

[Arno Wagner]

Bet thats an illusion and you wouldnt be able to pick it in a
double blind trial.

Very few situations on a personal desktop system where
the extra seeks between fragments will even be noticeable.


Nope, that just affects how much fragmentation occurs, and a decent
file system doesnt fragment too badly even at that level, unless
the files being copied to it are a large percentage of that 15%
thats free.

Thats a file system attribute, not what is used to do the copy.

[/QUOTE]

Rod, I was thinking that some copy utilities might use only a single
thread or stream (rather than try and be quick with multiple threads).

I see parms can be set in copiers like this one
http://www.copyhandler.com/en/manual/configuration.html
and I guessed wildly that a copy app for me would not use buffers of
such a size which dump data onto the target drive in a way that a single
buffer-load causes the data to completely fill some clusters and then go
and put the rest of the buffer-data elsewhere. Maybe my wild guess
about what may happen is just too wild!

It is. Cluster allocation is an OS task. It cannot really be bypassed.

Arno

 

[zappo]

It is. Cluster allocation is an OS task. It cannot really be bypassed.

That is just plain wrong. Obviously defraggers manage to do it fine.

 

[Arno Wagner]

That is just plain wrong. Obviously defraggers manage to do it fine.

Defraggers are not possible without direct OS support for them or
without disconnecting (unmounting) the partition from the OS before
defragging. Anything else would result in complete destruction of
the data.

Arno

 

[Eric Gisin]

Defraggers are not possible without direct OS support for them or
without disconnecting (unmounting) the partition from the OS before
defragging. Anything else would result in complete destruction of
the data.

As usual, you are an idiot. Windows 2K+ have an API to defrag a file.

 

[zappo]

Defraggers are not possible without direct OS support for them or
without disconnecting (unmounting) the partition from the OS before
defragging. Anything else would result in complete destruction of
the data.

Fact remains, your claim that cluster allocation is an OS task and
cannot be bypassed is just plain wrong when defraggers do just that.

 

[zappo]

Fact remains, your claim that cluster allocation is an OS task and
cannot be bypassed is just plain wrong when defraggers do just that.

AND there are some real time defraggers around that dont require that
the drive be unmounted for it to be defragged.

 

[Arno Wagner]

Fact remains, your claim that cluster allocation is an OS task and
cannot be bypassed is just plain wrong when defraggers do just that.

Defraggers can only ask the OS to either relocate some clusters or
ask it to not touch them while they are being relocated. This is
not in the standard filesystem interface.

Arno

 

[Arno Wagner]

AND there are some real time defraggers around that dont require that
the drive be unmounted for it to be defragged.

Read a book on OS design some time, especially the filesystem
buffer-cache layer. The hoops an OS has to jump through to allow
for filesystem defragmentation while it is mounted are astonishing.
It is still possible though and the defragger has to tell the
OS exactly what it is doing every step of the way.

Arno

 

[Eric Gisin]

Read a book on OS design some time, especially the filesystem
buffer-cache layer. The hoops an OS has to jump through to allow
for filesystem defragmentation while it is mounted are astonishing.
It is still possible though and the defragger has to tell the
OS exactly what it is doing every step of the way.

You are a ****ing retard, Annie. Win NT defrags OPEN files on mounted volumes.

 

[zappo]

Read a book on OS design some time,
especially the filesystem buffer-cache layer.

Dont need to. ALL I need to do is notice that there are real time
defraggers around that dont require the drive to be unmounted.

The hoops an OS has to jump through to allow for filesystem
defragmentation while it is mounted are astonishing.

Thats just plain wrong when there is an API to defrag a file.

It is still possible though and the defragger has to tell
the OS exactly what it is doing every step of the way.

So much for your claim that that it cannot be bypassed, clearly it can.

 

[zappo]

Defraggers can only ask the OS to either relocate some clusters or
ask it to not touch them while they are being relocated. This is
not in the standard filesystem interface.

Irrelevant to that claim you made that the OS cluster allocation cannot be bypassed.

Clearly it can.

 

[Arno Wagner]

Irrelevant to that claim you made that the OS cluster allocation
cannot be bypassed.

Clearly it can.

So? Moving clusters and allocating clusters are two entrierly
different operations. The second one is far, far more complicated.

Arno

 

[Arno Wagner]

Dont need to. ALL I need to do is notice that there are real time
defraggers around that dont require the drive to be unmounted.

Thats just plain wrong when there is an API to defrag a file.

So much for your claim that that it cannot be bypassed, clearly it can.

The OS cannot be bypassed. It can allow an application to tell it to
move a cluster. Cluster movement (the only thing needed for a
defragger) and allocation (the original discussion topic) are quite
different. As should be obvious to anybody that knows how a filesystem
works.

Or do you actually believe the defraggers do low-level disk access
themselves?

Arno

 

[zappo]

The OS cannot be bypassed.
Wrong.

It can allow an application to tell it to move a cluster.

It can ALSO be done that way.

Cluster movement (the only thing needed for a defragger) and
allocation (the original discussion topic) are quite different.

No it isnt when the file is defragged by moving it to a contiguous
series of clusters on the drive, with the defragger just telling the
OS that it owns the new clusters during the move.

As should be obvious to anybody that knows how a filesystem works.

Easy to claim. Pity about the above.

Or do you actually believe the defraggers do low-level disk access themselves?

That is indeed one way of doing a defragger. Its perfectly possible for a defragger
to identify a contiguous block of clusters where it wants to put the fragmented file,
for it to tell the OS that it has those clusters in various ways, and then to move the
contents of the fragged file to that contiguous block of clusters if it wants to do it like that.