ReactOS Forum

I was wondering if anyone had started working on ReactOS defrag...
if not Im going to start experimenting from this...
http://www.sysinternals.com/ntw2k/info/defrag.shtml

was wondering if these functions have been implemented in ROS
FSCTL_GET_VOLUME_BITMAP
FSCTL_GET_RETRIEVAL_POINTERS
FSCTL_MOVE_FILE

either way I'll try to work on a windows version..

Quigs wrote:I was wondering if anyone had started working on ReactOS defrag...
if not Im going to start experimenting from this...
http://www.sysinternals.com/ntw2k/info/defrag.shtml

was wondering if these functions have been implemented in ROS
FSCTL_GET_VOLUME_BITMAP
FSCTL_GET_RETRIEVAL_POINTERS
FSCTL_MOVE_FILE

either way I'll try to work on a windows version..

I don't exactly remember the reason why defragmenting on a multithreaded OS is (almost) worthless, but:
Defragmenting was great in DOS times, because only one program could run and access the HD. Means: The OS didn't have to jump around on the HD to find file parts if it was defragmented.
But now, with multithreaded systems, this problem isn't that big anymore, because when one program wants a file, another one wants another file and the OS has to jump around on the HD in any case.
Maybe I don't recall correctly, or this is just plain wrong, but it sounds logical to me.

Quigs wrote:I was wondering if anyone had started working on ReactOS defrag...
if not Im going to start experimenting from this...
http://www.sysinternals.com/ntw2k/info/defrag.shtml

was wondering if these functions have been implemented in ROS
FSCTL_GET_VOLUME_BITMAP
FSCTL_GET_RETRIEVAL_POINTERS
FSCTL_MOVE_FILE

either way I'll try to work on a windows version..

Perhaps you should care to take look at http://sourceforge.net/projects/opendefrag/ this project claimes to support ReactOS

Jaix wrote:

Quigs wrote:I was wondering if anyone had started working on ReactOS defrag...
if not Im going to start experimenting from this...
http://www.sysinternals.com/ntw2k/info/defrag.shtml

was wondering if these functions have been implemented in ROS
FSCTL_GET_VOLUME_BITMAP
FSCTL_GET_RETRIEVAL_POINTERS
FSCTL_MOVE_FILE

either way I'll try to work on a windows version..

Perhaps you should care to take look at http://sourceforge.net/projects/opendefrag/ this project claimes to support ReactOS

Project Admins:
w3seek


however he has no releases since 2003... maybe he never got around to it or he added it in ROS instead of doing it on the side.

Perhaps you should care to take look at http://sourceforge.net/projects/opendefrag/ this project claimes to support ReactOS

I did, I dont see any releases, or website...

Quigs wrote:

Perhaps you should care to take look at http://sourceforge.net/projects/opendefrag/ this project claimes to support ReactOS

I did, I dont see any releases, or website...

You could send a private mess to w3seek, he is one of the ROS developers.
Private mess to w3seek
w3seek info page

Quigs wrote:was wondering if these functions have been implemented in ROS
FSCTL_GET_VOLUME_BITMAP
FSCTL_GET_RETRIEVAL_POINTERS
FSCTL_MOVE_FILE

FSCTL_GET_RETRIEVAL_POINTERS is implemented in VFat, FSCTL_GET_VOLUME_BITMAP and FSCTL_MOVE_FILE are stubs.

NetSlayer wrote:

Quigs wrote:I was wondering if anyone had started working on ReactOS defrag...
if not Im going to start experimenting from this...
http://www.sysinternals.com/ntw2k/info/defrag.shtml

was wondering if these functions have been implemented in ROS
FSCTL_GET_VOLUME_BITMAP
FSCTL_GET_RETRIEVAL_POINTERS
FSCTL_MOVE_FILE

either way I'll try to work on a windows version..

I don't exactly remember the reason why defragmenting on a multithreaded OS is (almost) worthless, but:
Defragmenting was great in DOS times, because only one program could run and access the HD. Means: The OS didn't have to jump around on the HD to find file parts if it was defragmented.
But now, with multithreaded systems, this problem isn't that big anymore, because when one program wants a file, another one wants another file and the OS has to jump around on the HD in any case.
Maybe I don't recall correctly, or this is just plain wrong, but it sounds logical to me.

There are definite advantages to defragmentation. Shorter seek times being the primary one. I'm pretty sure linux auto-defragments in the background and i know NT4 claimed to (i don't think 2000 or XP does, or if it does, it's even worse than NT4 at it). NT4 didn't come with a defragmentation tool because MS claimed NTFS would do it itself. They, of course, lied (http://www.digit-life.com/articles/ntfs/) but NTFS is definitely resistant to fragmentation. However, "resistant" only means it's a matter of time until the whole system is plagued by longer seek/read times.

I originally wanted to develop opendefrag but reactos took all my spare time so far

w3seek wrote:I originally wanted to develop opendefrag but reactos took all my spare time so far

Good choice! I am soooo greateful to you and the other developers!

Floyd wrote:There are definite advantages to defragmentation. Shorter seek times being the primary one. I'm pretty sure linux auto-defragments in the background

Nope. Ext2 simply does not fragment more than a fractional amount. People actually thought about that one.
http://portal.suse.com/sdb/en/2002/06/ext2frag.html