My server is running W2K and the primary application utilizes MySQL. I have noticed that my C: drive has been getting more and more fragmented. The D: drive is good but guess on which drive MySQL is on? I am defragmenting on a daily basis but the defrager spends about 2-3minutes and gives up on the C: drive. I'm not sure if this matters but I have a 3-drive Raid-5 system.

Can anyone tell me if this is a W2K or MySQL or other issue and how I might be able to correct the problem?

I appreciate the help.

Surge

How much free space is on the drive? As drive space declines fragmentation
will increase. Also, how the drive is formatted will play a big role. The
C drive is almost always formatted as 4k. If you extend a file beyond the
4k, then a new cluster is needed. If the cluster next to the original is
not available, then you will fragment.

If the defragger is giving up, it probably means that there is relatively
little space available on C (which is preventing the defrag). Most likely
MySQL is extending its files a little at a time and inducing the issue.

What can you do?

You could move the MySQL to a volume formatted with a larger cluster size.
This will actually improve perf for 2 reasons. One, fewer fragments and
two, there will be fewer seeks for a given query. I would recommend a 16k
cluster size if possible.

Alternatively, clean up the C drive prior to attempting the defrag. You
could also try a different defrag app.

Pat

"Surge" <(E-Mail Removed)> wrote in message
news:7CB50199-DEB9-409D-A215-(E-Mail Removed)...
> My server is running W2K and the primary application utilizes MySQL. I
> have noticed that my C: drive has been getting more and more fragmented.
> The D: drive is good but guess on which drive MySQL is on? I am
> defragmenting on a daily basis but the defrager spends about 2-3minutes
> and gives up on the C: drive. I'm not sure if this matters but I have a
> 3-drive Raid-5 system.
>
> Can anyone tell me if this is a W2K or MySQL or other issue and how I
> might be able to correct the problem?
>
> I appreciate the help.
>
> Surge

Thank you for taking the time to respond.
I am posting the defrag analyzed data below:
Volume (C:
Volume size = 12,291 MB
Cluster size = 512 bytes
Used space = 5,308 MB
Free space = 6,983 MB
Percent free space = 56 %

Volume fragmentation
Total fragmentation = 5 %
File fragmentation = 10 %
Free space fragmentation = 0 %

File fragmentation
Total files = 19,517
Average file size = 355 KB
Total fragmented files = 18
Total excess fragments = 6,614
Average fragments per file = 1.33

Pagefile fragmentation
Pagefile size = 1,536 MB
Total fragments = 1

Directory fragmentation
Total directories = 2,669
Fragmented directories = 1
Excess directory fragments = 1

Master File Table (MFT) fragmentation
Total MFT size = 37,754 KB
MFT record count = 22,635
Percent MFT in use = 59 %
Total MFT fragments = 3

Fragments File Size Most fragmented files
2 56 KB \WINNT\system32\dhcp\backup\DhcpCfg
2 5 KB \Program Files\APC\PowerChute Business Edition\agent\EventLog
5 1,013 KB \WINNT\security\logs\winlogon.log
3 12 KB \WINNT\system32\config\software.LOG
2 1 KB \WINNT\system32\config\default.LOG
4 1 KB \WINNT\system32\config\SECURITY.LOG
2 608 KB \WINNT\security\logs\scepol.log
2 1,083 KB \WINNT\ShellIconCache
2 7 KB \WINNT\system32\dhcp\DhcpSrvLog.Thu
2 19,003 KB \Program Files\TapeWare\database\TW6XXINS.TWD
2 1,984 KB \Program Files\TapeWare\database\TW6XXMED.TWD
2 86 KB \WINNT\tracing\PPP.LOG
11 8 KB \Documents and Settings\xxxxxxx\NTUSER.DAT.LOG
2 25,417 KB \Program Files\xxxx\System Backup\Registry\03_31_04.reg
25 2,064 KB \WINNT\Debug\NtFrs_0005.log
3 32 KB \Documents and Settings\xxxxxxxx\Local Settings\Temp\MMC18.tmp
2 1,032 KB \WINNT\system32\dhcp\backup\Jet\new\dhcp.mdb


"Pat [MSFT]" wrote:

> How much free space is on the drive? As drive space declines fragmentation
> will increase. Also, how the drive is formatted will play a big role. The
> C drive is almost always formatted as 4k. If you extend a file beyond the
> 4k, then a new cluster is needed. If the cluster next to the original is
> not available, then you will fragment.
>
> If the defragger is giving up, it probably means that there is relatively
> little space available on C (which is preventing the defrag). Most likely
> MySQL is extending its files a little at a time and inducing the issue.
>
> What can you do?
>
> You could move the MySQL to a volume formatted with a larger cluster size.
> This will actually improve perf for 2 reasons. One, fewer fragments and
> two, there will be fewer seeks for a given query. I would recommend a 16k
> cluster size if possible.
>
> Alternatively, clean up the C drive prior to attempting the defrag. You
> could also try a different defrag app.
>
> Pat
>
> "Surge" <(E-Mail Removed)> wrote in message
> news:7CB50199-DEB9-409D-A215-(E-Mail Removed)...
> > My server is running W2K and the primary application utilizes MySQL. I
> > have noticed that my C: drive has been getting more and more fragmented.
> > The D: drive is good but guess on which drive MySQL is on? I am
> > defragmenting on a daily basis but the defrager spends about 2-3minutes
> > and gives up on the C: drive. I'm not sure if this matters but I have a
> > 3-drive Raid-5 system.
> >
> > Can anyone tell me if this is a W2K or MySQL or other issue and how I
> > might be able to correct the problem?
> >
> > I appreciate the help.
> >
> > Surge
>
>
>

Thank you for taking the time to help me out.
I am posting the defrag analyzed information below:
Volume (C:
Volume size = 12,291 MB
Cluster size = 512 bytes
Used space = 5,308 MB
Free space = 6,983 MB
Percent free space = 56 %

Volume fragmentation
Total fragmentation = 5 %
File fragmentation = 10 %
Free space fragmentation = 0 %

File fragmentation
Total files = 19,517
Average file size = 355 KB
Total fragmented files = 18
Total excess fragments = 6,614
Average fragments per file = 1.33

Pagefile fragmentation
Pagefile size = 1,536 MB
Total fragments = 1

Directory fragmentation
Total directories = 2,669
Fragmented directories = 1
Excess directory fragments = 1

Master File Table (MFT) fragmentation
Total MFT size = 37,754 KB
MFT record count = 22,635
Percent MFT in use = 59 %
Total MFT fragments = 3

--------------------------------------------------------------------------------
Fragments File Size Most fragmented files
2 56 KB \WINNT\system32\dhcp\backup\DhcpCfg
2 5 KB \Program Files\APC\PowerChute Business Edition\agent\EventLog
5 1,013 KB \WINNT\security\logs\winlogon.log
3 12 KB \WINNT\system32\config\software.LOG
2 1 KB \WINNT\system32\config\default.LOG
4 1 KB \WINNT\system32\config\SECURITY.LOG
2 608 KB \WINNT\security\logs\scepol.log
2 1,083 KB \WINNT\ShellIconCache
2 7 KB \WINNT\system32\dhcp\DhcpSrvLog.Thu
2 19,003 KB \Program Files\TapeWare\database\TW6XXINS.TWD
2 1,984 KB \Program Files\TapeWare\database\TW6XXMED.TWD
2 86 KB \WINNT\tracing\PPP.LOG
11 8 KB \Documents and Settings\xxxx\NTUSER.DAT.LOG
2 25,417 KB \Program Files\xxxxx\System Backup\Registry\03_31_04.reg
25 2,064 KB \WINNT\Debug\NtFrs_0005.log
3 32 KB \Documents and Settings\xxxxxx\Local Settings\Temp\MMC18.tmp
2 1,032 KB \WINNT\system32\dhcp\backup\Jet\new\dhcp.mdb

"Pat [MSFT]" wrote:

> How much free space is on the drive? As drive space declines fragmentation
> will increase. Also, how the drive is formatted will play a big role. The
> C drive is almost always formatted as 4k. If you extend a file beyond the
> 4k, then a new cluster is needed. If the cluster next to the original is
> not available, then you will fragment.
>
> If the defragger is giving up, it probably means that there is relatively
> little space available on C (which is preventing the defrag). Most likely
> MySQL is extending its files a little at a time and inducing the issue.
>
> What can you do?
>
> You could move the MySQL to a volume formatted with a larger cluster size.
> This will actually improve perf for 2 reasons. One, fewer fragments and
> two, there will be fewer seeks for a given query. I would recommend a 16k
> cluster size if possible.
>
> Alternatively, clean up the C drive prior to attempting the defrag. You
> could also try a different defrag app.
>
> Pat
>
> "Surge" <(E-Mail Removed)> wrote in message
> news:7CB50199-DEB9-409D-A215-(E-Mail Removed)...
> > My server is running W2K and the primary application utilizes MySQL. I
> > have noticed that my C: drive has been getting more and more fragmented.
> > The D: drive is good but guess on which drive MySQL is on? I am
> > defragmenting on a daily basis but the defrager spends about 2-3minutes
> > and gives up on the C: drive. I'm not sure if this matters but I have a
> > 3-drive Raid-5 system.
> >
> > Can anyone tell me if this is a W2K or MySQL or other issue and how I
> > might be able to correct the problem?
> >
> > I appreciate the help.
> >
> > Surge
>
>
>

Was this an upgrade install? 512byte cluster size is *tiny* and
inefficient. That's why even 1k files are fragmenting. If you had 4k
clusters, it would be impossible to fragment any file <4k (all of those .log
files for example). Basically what is happening is that every time a file
needs to extend 1byte beyond the 512byte cluster, a new cluster is having to
be allocated. The probability that the next cluster is free is relatively
low and you will fragment. This provides very little room for the files to
expand as needed. With 4k clusters, the 1st byte will cause a 4k
allocation, but no new allocations will occur until the 4k is filled up.

The average file size is pretty big (355k) which is partly due to the
pagefile skewing the average high. But even without that, the average file
size is probably close to 256k.

On the good news side, virtually none of the fragmented files are used very
often, if at all (most are only there for troubleshooting or .tmp files).
So, the fact that they are fragmented isn't going to hurt much. If the DB
files are fragmenting, then you will see a perf issue.

Since this is the System drive, there isn't much you can do at this point
other than work to mitigate the problem. If you have another volume
available, move files that are touched a lot (e.g. the DB files) there.
Make sure to format it with a larger cluster size (if it is primarily for
DB, use 16k which will help with lookup times too).

Pat



"Surge" <(E-Mail Removed)> wrote in message
news:1AACC5F5-99BF-4819-8BAC-(E-Mail Removed)...
> Thank you for taking the time to help me out.
> I am posting the defrag analyzed information below:
> Volume (C:
> Volume size = 12,291 MB
> Cluster size = 512 bytes
> Used space = 5,308 MB
> Free space = 6,983 MB
> Percent free space = 56 %
>
> Volume fragmentation
> Total fragmentation = 5 %
> File fragmentation = 10 %
> Free space fragmentation = 0 %
>
> File fragmentation
> Total files = 19,517
> Average file size = 355 KB
> Total fragmented files = 18
> Total excess fragments = 6,614
> Average fragments per file = 1.33
>
> Pagefile fragmentation
> Pagefile size = 1,536 MB
> Total fragments = 1
>
> Directory fragmentation
> Total directories = 2,669
> Fragmented directories = 1
> Excess directory fragments = 1
>
> Master File Table (MFT) fragmentation
> Total MFT size = 37,754 KB
> MFT record count = 22,635
> Percent MFT in use = 59 %
> Total MFT fragments = 3
>
> --------------------------------------------------------------------------------
> Fragments File Size Most fragmented files
> 2 56 KB \WINNT\system32\dhcp\backup\DhcpCfg
> 2 5 KB \Program Files\APC\PowerChute Business
> Edition\agent\EventLog
> 5 1,013 KB \WINNT\security\logs\winlogon.log
> 3 12 KB \WINNT\system32\config\software.LOG
> 2 1 KB \WINNT\system32\config\default.LOG
> 4 1 KB \WINNT\system32\config\SECURITY.LOG
> 2 608 KB \WINNT\security\logs\scepol.log
> 2 1,083 KB \WINNT\ShellIconCache
> 2 7 KB \WINNT\system32\dhcp\DhcpSrvLog.Thu
> 2 19,003 KB \Program
> Files\TapeWare\database\TW6XXINS.TWD
> 2 1,984 KB \Program
> Files\TapeWare\database\TW6XXMED.TWD
> 2 86 KB \WINNT\tracing\PPP.LOG
> 11 8 KB \Documents and
> Settings\xxxx\NTUSER.DAT.LOG
> 2 25,417 KB \Program Files\xxxxx\System
> Backup\Registry\03_31_04.reg
> 25 2,064 KB \WINNT\Debug\NtFrs_0005.log
> 3 32 KB \Documents and Settings\xxxxxx\Local
> Settings\Temp\MMC18.tmp
> 2 1,032 KB
> \WINNT\system32\dhcp\backup\Jet\new\dhcp.mdb
>
> "Pat [MSFT]" wrote:
>
>> How much free space is on the drive? As drive space declines
>> fragmentation
>> will increase. Also, how the drive is formatted will play a big role.
>> The
>> C drive is almost always formatted as 4k. If you extend a file beyond
>> the
>> 4k, then a new cluster is needed. If the cluster next to the original is
>> not available, then you will fragment.
>>
>> If the defragger is giving up, it probably means that there is relatively
>> little space available on C (which is preventing the defrag). Most
>> likely
>> MySQL is extending its files a little at a time and inducing the issue.
>>
>> What can you do?
>>
>> You could move the MySQL to a volume formatted with a larger cluster
>> size.
>> This will actually improve perf for 2 reasons. One, fewer fragments and
>> two, there will be fewer seeks for a given query. I would recommend a
>> 16k
>> cluster size if possible.
>>
>> Alternatively, clean up the C drive prior to attempting the defrag. You
>> could also try a different defrag app.
>>
>> Pat
>>
>> "Surge" <(E-Mail Removed)> wrote in message
>> news:7CB50199-DEB9-409D-A215-(E-Mail Removed)...
>> > My server is running W2K and the primary application utilizes MySQL. I
>> > have noticed that my C: drive has been getting more and more
>> > fragmented.
>> > The D: drive is good but guess on which drive MySQL is on? I am
>> > defragmenting on a daily basis but the defrager spends about 2-3minutes
>> > and gives up on the C: drive. I'm not sure if this matters but I have a
>> > 3-drive Raid-5 system.
>> >
>> > Can anyone tell me if this is a W2K or MySQL or other issue and how I
>> > might be able to correct the problem?
>> >
>> > I appreciate the help.
>> >
>> > Surge
>>
>>
>>

Nope. The cluster size is tied to the volume. So, you would have to
re-format at that level to get anything.

Pat

"Surge" <(E-Mail Removed)> wrote in message
news:5EEC1859-9CAA-4A1D-85F7-(E-Mail Removed)...
> Pat,
> Again thank you. This server was bought new from Dell and came
> preconfigured. I'm surprised that they formated it with such a small
> cluster size given that it is a server.
>
> You mentioned that there is little I can do given that it is the system
> drive. I am running a RAID-5 system with hot swappable drives. Do you
> think that if I swapped the system drive out and replaced it with a new
> drive that is formatted with 4K clusters that it will rebuild the data
> correctly?
>
> Regards,
> Surge
> "Pat [MSFT]" wrote:
>
>> Was this an upgrade install? 512byte cluster size is *tiny* and
>> inefficient. That's why even 1k files are fragmenting. If you had 4k
>> clusters, it would be impossible to fragment any file <4k (all of those
>> .log
>> files for example). Basically what is happening is that every time a
>> file
>> needs to extend 1byte beyond the 512byte cluster, a new cluster is having
>> to
>> be allocated. The probability that the next cluster is free is
>> relatively
>> low and you will fragment. This provides very little room for the files
>> to
>> expand as needed. With 4k clusters, the 1st byte will cause a 4k
>> allocation, but no new allocations will occur until the 4k is filled up.
>>
>> The average file size is pretty big (355k) which is partly due to the
>> pagefile skewing the average high. But even without that, the average
>> file
>> size is probably close to 256k.
>>
>> On the good news side, virtually none of the fragmented files are used
>> very
>> often, if at all (most are only there for troubleshooting or .tmp files).
>> So, the fact that they are fragmented isn't going to hurt much. If the
>> DB
>> files are fragmenting, then you will see a perf issue.
>>
>> Since this is the System drive, there isn't much you can do at this point
>> other than work to mitigate the problem. If you have another volume
>> available, move files that are touched a lot (e.g. the DB files) there.
>> Make sure to format it with a larger cluster size (if it is primarily for
>> DB, use 16k which will help with lookup times too).
>>
>> Pat
>>
>>
>>
>> "Surge" <(E-Mail Removed)> wrote in message
>> news:1AACC5F5-99BF-4819-8BAC-(E-Mail Removed)...
>> > Thank you for taking the time to help me out.
>> > I am posting the defrag analyzed information below:
>> > Volume (C:
>> > Volume size = 12,291 MB
>> > Cluster size = 512 bytes
>> > Used space = 5,308 MB
>> > Free space = 6,983 MB
>> > Percent free space = 56 %
>> >
>> > Volume fragmentation
>> > Total fragmentation = 5 %
>> > File fragmentation = 10 %
>> > Free space fragmentation = 0 %
>> >
>> > File fragmentation
>> > Total files = 19,517
>> > Average file size = 355 KB
>> > Total fragmented files = 18
>> > Total excess fragments = 6,614
>> > Average fragments per file = 1.33
>> >
>> > Pagefile fragmentation
>> > Pagefile size = 1,536 MB
>> > Total fragments = 1
>> >
>> > Directory fragmentation
>> > Total directories = 2,669
>> > Fragmented directories = 1
>> > Excess directory fragments = 1
>> >
>> > Master File Table (MFT) fragmentation
>> > Total MFT size = 37,754 KB
>> > MFT record count = 22,635
>> > Percent MFT in use = 59 %
>> > Total MFT fragments = 3
>> >
>> > --------------------------------------------------------------------------------
>> > Fragments File Size Most fragmented files
>> > 2 56 KB \WINNT\system32\dhcp\backup\DhcpCfg
>> > 2 5 KB \Program Files\APC\PowerChute Business
>> > Edition\agent\EventLog
>> > 5 1,013 KB \WINNT\security\logs\winlogon.log
>> > 3 12 KB \WINNT\system32\config\software.LOG
>> > 2 1 KB \WINNT\system32\config\default.LOG
>> > 4 1 KB \WINNT\system32\config\SECURITY.LOG
>> > 2 608 KB \WINNT\security\logs\scepol.log
>> > 2 1,083 KB \WINNT\ShellIconCache
>> > 2 7 KB \WINNT\system32\dhcp\DhcpSrvLog.Thu
>> > 2 19,003 KB \Program
>> > Files\TapeWare\database\TW6XXINS.TWD
>> > 2 1,984 KB \Program
>> > Files\TapeWare\database\TW6XXMED.TWD
>> > 2 86 KB \WINNT\tracing\PPP.LOG
>> > 11 8 KB \Documents and
>> > Settings\xxxx\NTUSER.DAT.LOG
>> > 2 25,417 KB \Program Files\xxxxx\System
>> > Backup\Registry\03_31_04.reg
>> > 25 2,064 KB \WINNT\Debug\NtFrs_0005.log
>> > 3 32 KB \Documents and Settings\xxxxxx\Local
>> > Settings\Temp\MMC18.tmp
>> > 2 1,032 KB
>> > \WINNT\system32\dhcp\backup\Jet\new\dhcp.mdb
>> >
>> > "Pat [MSFT]" wrote:
>> >
>> >> How much free space is on the drive? As drive space declines
>> >> fragmentation
>> >> will increase. Also, how the drive is formatted will play a big role.
>> >> The
>> >> C drive is almost always formatted as 4k. If you extend a file beyond
>> >> the
>> >> 4k, then a new cluster is needed. If the cluster next to the original
>> >> is
>> >> not available, then you will fragment.
>> >>
>> >> If the defragger is giving up, it probably means that there is
>> >> relatively
>> >> little space available on C (which is preventing the defrag). Most
>> >> likely
>> >> MySQL is extending its files a little at a time and inducing the
>> >> issue.
>> >>
>> >> What can you do?
>> >>
>> >> You could move the MySQL to a volume formatted with a larger cluster
>> >> size.
>> >> This will actually improve perf for 2 reasons. One, fewer fragments
>> >> and
>> >> two, there will be fewer seeks for a given query. I would recommend a
>> >> 16k
>> >> cluster size if possible.
>> >>
>> >> Alternatively, clean up the C drive prior to attempting the defrag.
>> >> You
>> >> could also try a different defrag app.
>> >>
>> >> Pat
>> >>
>> >> "Surge" <(E-Mail Removed)> wrote in message
>> >> news:7CB50199-DEB9-409D-A215-(E-Mail Removed)...
>> >> > My server is running W2K and the primary application utilizes MySQL.
>> >> > I
>> >> > have noticed that my C: drive has been getting more and more
>> >> > fragmented.
>> >> > The D: drive is good but guess on which drive MySQL is on? I am
>> >> > defragmenting on a daily basis but the defrager spends about
>> >> > 2-3minutes
>> >> > and gives up on the C: drive. I'm not sure if this matters but I
>> >> > have a
>> >> > 3-drive Raid-5 system.
>> >> >
>> >> > Can anyone tell me if this is a W2K or MySQL or other issue and how
>> >> > I
>> >> > might be able to correct the problem?
>> >> >
>> >> > I appreciate the help.
>> >> >
>> >> > Surge
>> >>
>> >>
>> >>
>>
>>
>>

"If you had 4k clusters, it would be impossible to fragment any file "

This is grossly incorrect. Fragmentation is independent of cluster size.
Fragmentation will occur as long as there is insufficient contiguous free
space to create a new file contiguously or if a already contiguous files
"grows" and there is no free space immediately after the file for it to
"grow" into.

- 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.


"Pat [MSFT]" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Was this an upgrade install? 512byte cluster size is *tiny* and
> inefficient. That's why even 1k files are fragmenting. If you had 4k
> clusters, it would be impossible to fragment any file <4k (all of those
..log
> files for example). Basically what is happening is that every time a file
> needs to extend 1byte beyond the 512byte cluster, a new cluster is having
to
> be allocated. The probability that the next cluster is free is relatively
> low and you will fragment. This provides very little room for the files
to
> expand as needed. With 4k clusters, the 1st byte will cause a 4k
> allocation, but no new allocations will occur until the 4k is filled up.
>
> The average file size is pretty big (355k) which is partly due to the
> pagefile skewing the average high. But even without that, the average
file
> size is probably close to 256k.
>
> On the good news side, virtually none of the fragmented files are used
very
> often, if at all (most are only there for troubleshooting or .tmp files).
> So, the fact that they are fragmented isn't going to hurt much. If the DB
> files are fragmenting, then you will see a perf issue.
>
> Since this is the System drive, there isn't much you can do at this point
> other than work to mitigate the problem. If you have another volume
> available, move files that are touched a lot (e.g. the DB files) there.
> Make sure to format it with a larger cluster size (if it is primarily for
> DB, use 16k which will help with lookup times too).
>
> Pat
>
>
>
> "Surge" <(E-Mail Removed)> wrote in message
> news:1AACC5F5-99BF-4819-8BAC-(E-Mail Removed)...
> > Thank you for taking the time to help me out.
> > I am posting the defrag analyzed information below:
> > Volume (C:
> > Volume size = 12,291 MB
> > Cluster size = 512 bytes
> > Used space = 5,308 MB
> > Free space = 6,983 MB
> > Percent free space = 56 %
> >
> > Volume fragmentation
> > Total fragmentation = 5 %
> > File fragmentation = 10 %
> > Free space fragmentation = 0 %
> >
> > File fragmentation
> > Total files = 19,517
> > Average file size = 355 KB
> > Total fragmented files = 18
> > Total excess fragments = 6,614
> > Average fragments per file = 1.33
> >
> > Pagefile fragmentation
> > Pagefile size = 1,536 MB
> > Total fragments = 1
> >
> > Directory fragmentation
> > Total directories = 2,669
> > Fragmented directories = 1
> > Excess directory fragments = 1
> >
> > Master File Table (MFT) fragmentation
> > Total MFT size = 37,754 KB
> > MFT record count = 22,635
> > Percent MFT in use = 59 %
> > Total MFT fragments = 3
> >
>
> --------------------------------------------------------------------------
------
> > Fragments File Size Most fragmented files
> > 2 56 KB \WINNT\system32\dhcp\backup\DhcpCfg
> > 2 5 KB \Program Files\APC\PowerChute Business
> > Edition\agent\EventLog
> > 5 1,013 KB \WINNT\security\logs\winlogon.log
> > 3 12 KB \WINNT\system32\config\software.LOG
> > 2 1 KB \WINNT\system32\config\default.LOG
> > 4 1 KB \WINNT\system32\config\SECURITY.LOG
> > 2 608 KB \WINNT\security\logs\scepol.log
> > 2 1,083 KB \WINNT\ShellIconCache
> > 2 7 KB \WINNT\system32\dhcp\DhcpSrvLog.Thu
> > 2 19,003 KB \Program
> > Files\TapeWare\database\TW6XXINS.TWD
> > 2 1,984 KB \Program
> > Files\TapeWare\database\TW6XXMED.TWD
> > 2 86 KB \WINNT\tracing\PPP.LOG
> > 11 8 KB \Documents and
> > Settings\xxxx\NTUSER.DAT.LOG
> > 2 25,417 KB \Program Files\xxxxx\System
> > Backup\Registry\03_31_04.reg
> > 25 2,064 KB \WINNT\Debug\NtFrs_0005.log
> > 3 32 KB \Documents and Settings\xxxxxx\Local
> > Settings\Temp\MMC18.tmp
> > 2 1,032 KB
> > \WINNT\system32\dhcp\backup\Jet\new\dhcp.mdb
> >
> > "Pat [MSFT]" wrote:
> >
> >> How much free space is on the drive? As drive space declines
> >> fragmentation
> >> will increase. Also, how the drive is formatted will play a big role.
> >> The
> >> C drive is almost always formatted as 4k. If you extend a file beyond
> >> the
> >> 4k, then a new cluster is needed. If the cluster next to the original
is
> >> not available, then you will fragment.
> >>
> >> If the defragger is giving up, it probably means that there is
relatively
> >> little space available on C (which is preventing the defrag). Most
> >> likely
> >> MySQL is extending its files a little at a time and inducing the issue.
> >>
> >> What can you do?
> >>
> >> You could move the MySQL to a volume formatted with a larger cluster
> >> size.
> >> This will actually improve perf for 2 reasons. One, fewer fragments
and
> >> two, there will be fewer seeks for a given query. I would recommend a
> >> 16k
> >> cluster size if possible.
> >>
> >> Alternatively, clean up the C drive prior to attempting the defrag.
You
> >> could also try a different defrag app.
> >>
> >> Pat
> >>
> >> "Surge" <(E-Mail Removed)> wrote in message
> >> news:7CB50199-DEB9-409D-A215-(E-Mail Removed)...
> >> > My server is running W2K and the primary application utilizes MySQL.
I
> >> > have noticed that my C: drive has been getting more and more
> >> > fragmented.
> >> > The D: drive is good but guess on which drive MySQL is on? I am
> >> > defragmenting on a daily basis but the defrager spends about
2-3minutes
> >> > and gives up on the C: drive. I'm not sure if this matters but I have
a
> >> > 3-drive Raid-5 system.
> >> >
> >> > Can anyone tell me if this is a W2K or MySQL or other issue and how I
> >> > might be able to correct the problem?
> >> >
> >> > I appreciate the help.
> >> >
> >> > Surge
> >>
> >>
> >>
>
>

If the files themselves are <4k then they will fit in a single cluster. The
..log files are <4k in size so this would prevent their fragmenting. Files
>4k would still be possible to fragment.


Pat


"Greg Hayes/Raxco Software" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> "If you had 4k clusters, it would be impossible to fragment any file "
>
> This is grossly incorrect. Fragmentation is independent of cluster size.
> Fragmentation will occur as long as there is insufficient contiguous free
> space to create a new file contiguously or if a already contiguous files
> "grows" and there is no free space immediately after the file for it to
> "grow" into.
>
> - 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.
>
>
> "Pat [MSFT]" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> Was this an upgrade install? 512byte cluster size is *tiny* and
>> inefficient. That's why even 1k files are fragmenting. If you had 4k
>> clusters, it would be impossible to fragment any file <4k (all of those
> .log
>> files for example). Basically what is happening is that every time a
>> file
>> needs to extend 1byte beyond the 512byte cluster, a new cluster is having
> to
>> be allocated. The probability that the next cluster is free is
>> relatively
>> low and you will fragment. This provides very little room for the files
> to
>> expand as needed. With 4k clusters, the 1st byte will cause a 4k
>> allocation, but no new allocations will occur until the 4k is filled up.
>>
>> The average file size is pretty big (355k) which is partly due to the
>> pagefile skewing the average high. But even without that, the average
> file
>> size is probably close to 256k.
>>
>> On the good news side, virtually none of the fragmented files are used
> very
>> often, if at all (most are only there for troubleshooting or .tmp files).
>> So, the fact that they are fragmented isn't going to hurt much. If the
>> DB
>> files are fragmenting, then you will see a perf issue.
>>
>> Since this is the System drive, there isn't much you can do at this point
>> other than work to mitigate the problem. If you have another volume
>> available, move files that are touched a lot (e.g. the DB files) there.
>> Make sure to format it with a larger cluster size (if it is primarily for
>> DB, use 16k which will help with lookup times too).
>>
>> Pat
>>
>>
>>
>> "Surge" <(E-Mail Removed)> wrote in message
>> news:1AACC5F5-99BF-4819-8BAC-(E-Mail Removed)...
>> > Thank you for taking the time to help me out.
>> > I am posting the defrag analyzed information below:
>> > Volume (C:
>> > Volume size = 12,291 MB
>> > Cluster size = 512 bytes
>> > Used space = 5,308 MB
>> > Free space = 6,983 MB
>> > Percent free space = 56 %
>> >
>> > Volume fragmentation
>> > Total fragmentation = 5 %
>> > File fragmentation = 10 %
>> > Free space fragmentation = 0 %
>> >
>> > File fragmentation
>> > Total files = 19,517
>> > Average file size = 355 KB
>> > Total fragmented files = 18
>> > Total excess fragments = 6,614
>> > Average fragments per file = 1.33
>> >
>> > Pagefile fragmentation
>> > Pagefile size = 1,536 MB
>> > Total fragments = 1
>> >
>> > Directory fragmentation
>> > Total directories = 2,669
>> > Fragmented directories = 1
>> > Excess directory fragments = 1
>> >
>> > Master File Table (MFT) fragmentation
>> > Total MFT size = 37,754 KB
>> > MFT record count = 22,635
>> > Percent MFT in use = 59 %
>> > Total MFT fragments = 3
>> >
>>
>> --------------------------------------------------------------------------
> ------
>> > Fragments File Size Most fragmented files
>> > 2 56 KB \WINNT\system32\dhcp\backup\DhcpCfg
>> > 2 5 KB \Program Files\APC\PowerChute Business
>> > Edition\agent\EventLog
>> > 5 1,013 KB \WINNT\security\logs\winlogon.log
>> > 3 12 KB \WINNT\system32\config\software.LOG
>> > 2 1 KB \WINNT\system32\config\default.LOG
>> > 4 1 KB \WINNT\system32\config\SECURITY.LOG
>> > 2 608 KB \WINNT\security\logs\scepol.log
>> > 2 1,083 KB \WINNT\ShellIconCache
>> > 2 7 KB \WINNT\system32\dhcp\DhcpSrvLog.Thu
>> > 2 19,003 KB \Program
>> > Files\TapeWare\database\TW6XXINS.TWD
>> > 2 1,984 KB \Program
>> > Files\TapeWare\database\TW6XXMED.TWD
>> > 2 86 KB \WINNT\tracing\PPP.LOG
>> > 11 8 KB \Documents and
>> > Settings\xxxx\NTUSER.DAT.LOG
>> > 2 25,417 KB \Program Files\xxxxx\System
>> > Backup\Registry\03_31_04.reg
>> > 25 2,064 KB \WINNT\Debug\NtFrs_0005.log
>> > 3 32 KB \Documents and Settings\xxxxxx\Local
>> > Settings\Temp\MMC18.tmp
>> > 2 1,032 KB
>> > \WINNT\system32\dhcp\backup\Jet\new\dhcp.mdb
>> >
>> > "Pat [MSFT]" wrote:
>> >
>> >> How much free space is on the drive? As drive space declines
>> >> fragmentation
>> >> will increase. Also, how the drive is formatted will play a big role.
>> >> The
>> >> C drive is almost always formatted as 4k. If you extend a file beyond
>> >> the
>> >> 4k, then a new cluster is needed. If the cluster next to the original
> is
>> >> not available, then you will fragment.
>> >>
>> >> If the defragger is giving up, it probably means that there is
> relatively
>> >> little space available on C (which is preventing the defrag). Most
>> >> likely
>> >> MySQL is extending its files a little at a time and inducing the
>> >> issue.
>> >>
>> >> What can you do?
>> >>
>> >> You could move the MySQL to a volume formatted with a larger cluster
>> >> size.
>> >> This will actually improve perf for 2 reasons. One, fewer fragments
> and
>> >> two, there will be fewer seeks for a given query. I would recommend a
>> >> 16k
>> >> cluster size if possible.
>> >>
>> >> Alternatively, clean up the C drive prior to attempting the defrag.
> You
>> >> could also try a different defrag app.
>> >>
>> >> Pat
>> >>
>> >> "Surge" <(E-Mail Removed)> wrote in message
>> >> news:7CB50199-DEB9-409D-A215-(E-Mail Removed)...
>> >> > My server is running W2K and the primary application utilizes MySQL.
> I
>> >> > have noticed that my C: drive has been getting more and more
>> >> > fragmented.
>> >> > The D: drive is good but guess on which drive MySQL is on? I am
>> >> > defragmenting on a daily basis but the defrager spends about
> 2-3minutes
>> >> > and gives up on the C: drive. I'm not sure if this matters but I
>> >> > have
> a
>> >> > 3-drive Raid-5 system.
>> >> >
>> >> > Can anyone tell me if this is a W2K or MySQL or other issue and how
>> >> > I
>> >> > might be able to correct the problem?
>> >> >
>> >> > I appreciate the help.
>> >> >
>> >> > Surge
>> >>
>> >>
>> >>
>>
>>
>
>

Hi, Greg.

Looks like you were a victim of a copy'n'paste that was one word too short.
;^}

Pat said:
....fragment any file <4k (all of those .log files...

That is, not just "any file", but "any file shorter than 4K" - which would
all fit into a single 4K cluster.

RC
--
R. C. White, CPA
San Marcos, TX
(E-Mail Removed)
Microsoft Windows MVP

"Greg Hayes/Raxco Software" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> "If you had 4k clusters, it would be impossible to fragment any file "
>
> This is grossly incorrect. Fragmentation is independent of cluster size.
> Fragmentation will occur as long as there is insufficient contiguous free
> space to create a new file contiguously or if a already contiguous files
> "grows" and there is no free space immediately after the file for it to
> "grow" into.
>
> - Greg/Raxco Software
> Microsoft MVP - Windows File System
>
> "Pat [MSFT]" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> Was this an upgrade install? 512byte cluster size is *tiny* and
>> inefficient. That's why even 1k files are fragmenting. If you had 4k
>> clusters, it would be impossible to fragment any file <4k (all of those
> .log
>> files for example). Basically what is happening is that every time a
>> file
>> needs to extend 1byte beyond the 512byte cluster, a new cluster is having
> to
>> be allocated. The probability that the next cluster is free is
>> relatively
>> low and you will fragment. This provides very little room for the files
> to
>> expand as needed. With 4k clusters, the 1st byte will cause a 4k
>> allocation, but no new allocations will occur until the 4k is filled up.
>>
>> The average file size is pretty big (355k) which is partly due to the
>> pagefile skewing the average high. But even without that, the average
> file
>> size is probably close to 256k.
>>
>> On the good news side, virtually none of the fragmented files are used
> very
>> often, if at all (most are only there for troubleshooting or .tmp files).
>> So, the fact that they are fragmented isn't going to hurt much. If the
>> DB
>> files are fragmenting, then you will see a perf issue.
>>
>> Since this is the System drive, there isn't much you can do at this point
>> other than work to mitigate the problem. If you have another volume
>> available, move files that are touched a lot (e.g. the DB files) there.
>> Make sure to format it with a larger cluster size (if it is primarily for
>> DB, use 16k which will help with lookup times too).
>>
>> Pat

Oops - should teach me to pay attention more attention when I am reading...

- Greg/Raxco Software
Microsoft MVP - Windows File System

Want to email me? Delete ntloader.


"Pat [MSFT]" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> If the files themselves are <4k then they will fit in a single cluster.
The
> .log files are <4k in size so this would prevent their fragmenting. Files
> >4k would still be possible to fragment.
>
>
> Pat
>
>
> "Greg Hayes/Raxco Software" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > "If you had 4k clusters, it would be impossible to fragment any file "
> >
> > This is grossly incorrect. Fragmentation is independent of cluster
size.
> > Fragmentation will occur as long as there is insufficient contiguous
free
> > space to create a new file contiguously or if a already contiguous files
> > "grows" and there is no free space immediately after the file for it to
> > "grow" into.
> >
> > - 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.
> >
> >
> > "Pat [MSFT]" <(E-Mail Removed)> wrote in message
> > news:(E-Mail Removed)...
> >> Was this an upgrade install? 512byte cluster size is *tiny* and
> >> inefficient. That's why even 1k files are fragmenting. If you had 4k
> >> clusters, it would be impossible to fragment any file <4k (all of those
> > .log
> >> files for example). Basically what is happening is that every time a
> >> file
> >> needs to extend 1byte beyond the 512byte cluster, a new cluster is
having
> > to
> >> be allocated. The probability that the next cluster is free is
> >> relatively
> >> low and you will fragment. This provides very little room for the
files
> > to
> >> expand as needed. With 4k clusters, the 1st byte will cause a 4k
> >> allocation, but no new allocations will occur until the 4k is filled
up.
> >>
> >> The average file size is pretty big (355k) which is partly due to the
> >> pagefile skewing the average high. But even without that, the average
> > file
> >> size is probably close to 256k.
> >>
> >> On the good news side, virtually none of the fragmented files are used
> > very
> >> often, if at all (most are only there for troubleshooting or .tmp
files).
> >> So, the fact that they are fragmented isn't going to hurt much. If the
> >> DB
> >> files are fragmenting, then you will see a perf issue.
> >>
> >> Since this is the System drive, there isn't much you can do at this
point
> >> other than work to mitigate the problem. If you have another volume
> >> available, move files that are touched a lot (e.g. the DB files) there.
> >> Make sure to format it with a larger cluster size (if it is primarily
for
> >> DB, use 16k which will help with lookup times too).
> >>
> >> Pat
> >>
> >>
> >>
> >> "Surge" <(E-Mail Removed)> wrote in message
> >> news:1AACC5F5-99BF-4819-8BAC-(E-Mail Removed)...
> >> > Thank you for taking the time to help me out.
> >> > I am posting the defrag analyzed information below:
> >> > Volume (C:
> >> > Volume size = 12,291 MB
> >> > Cluster size = 512 bytes
> >> > Used space = 5,308 MB
> >> > Free space = 6,983 MB
> >> > Percent free space = 56 %
> >> >
> >> > Volume fragmentation
> >> > Total fragmentation = 5 %
> >> > File fragmentation = 10 %
> >> > Free space fragmentation = 0 %
> >> >
> >> > File fragmentation
> >> > Total files = 19,517
> >> > Average file size = 355 KB
> >> > Total fragmented files = 18
> >> > Total excess fragments = 6,614
> >> > Average fragments per file = 1.33
> >> >
> >> > Pagefile fragmentation
> >> > Pagefile size = 1,536 MB
> >> > Total fragments = 1
> >> >
> >> > Directory fragmentation
> >> > Total directories = 2,669
> >> > Fragmented directories = 1
> >> > Excess directory fragments = 1
> >> >
> >> > Master File Table (MFT) fragmentation
> >> > Total MFT size = 37,754 KB
> >> > MFT record count = 22,635
> >> > Percent MFT in use = 59 %
> >> > Total MFT fragments = 3
> >> >
> >>
>
>> -------------------------------------------------------------------------
-
> > ------
> >> > Fragments File Size Most fragmented files
> >> > 2 56 KB \WINNT\system32\dhcp\backup\DhcpCfg
> >> > 2 5 KB \Program Files\APC\PowerChute
Business
> >> > Edition\agent\EventLog
> >> > 5 1,013 KB \WINNT\security\logs\winlogon.log
> >> > 3 12 KB \WINNT\system32\config\software.LOG
> >> > 2 1 KB \WINNT\system32\config\default.LOG
> >> > 4 1 KB \WINNT\system32\config\SECURITY.LOG
> >> > 2 608 KB \WINNT\security\logs\scepol.log
> >> > 2 1,083 KB \WINNT\ShellIconCache
> >> > 2 7 KB \WINNT\system32\dhcp\DhcpSrvLog.Thu
> >> > 2 19,003 KB \Program
> >> > Files\TapeWare\database\TW6XXINS.TWD
> >> > 2 1,984 KB \Program
> >> > Files\TapeWare\database\TW6XXMED.TWD
> >> > 2 86 KB \WINNT\tracing\PPP.LOG
> >> > 11 8 KB \Documents and
> >> > Settings\xxxx\NTUSER.DAT.LOG
> >> > 2 25,417 KB \Program Files\xxxxx\System
> >> > Backup\Registry\03_31_04.reg
> >> > 25 2,064 KB \WINNT\Debug\NtFrs_0005.log
> >> > 3 32 KB \Documents and Settings\xxxxxx\Local
> >> > Settings\Temp\MMC18.tmp
> >> > 2 1,032 KB
> >> > \WINNT\system32\dhcp\backup\Jet\new\dhcp.mdb
> >> >
> >> > "Pat [MSFT]" wrote:
> >> >
> >> >> How much free space is on the drive? As drive space declines
> >> >> fragmentation
> >> >> will increase. Also, how the drive is formatted will play a big
role.
> >> >> The
> >> >> C drive is almost always formatted as 4k. If you extend a file
beyond
> >> >> the
> >> >> 4k, then a new cluster is needed. If the cluster next to the
original
> > is
> >> >> not available, then you will fragment.
> >> >>
> >> >> If the defragger is giving up, it probably means that there is
> > relatively
> >> >> little space available on C (which is preventing the defrag). Most
> >> >> likely
> >> >> MySQL is extending its files a little at a time and inducing the
> >> >> issue.
> >> >>
> >> >> What can you do?
> >> >>
> >> >> You could move the MySQL to a volume formatted with a larger cluster
> >> >> size.
> >> >> This will actually improve perf for 2 reasons. One, fewer fragments
> > and
> >> >> two, there will be fewer seeks for a given query. I would recommend
a
> >> >> 16k
> >> >> cluster size if possible.
> >> >>
> >> >> Alternatively, clean up the C drive prior to attempting the defrag.
> > You
> >> >> could also try a different defrag app.
> >> >>
> >> >> Pat
> >> >>
> >> >> "Surge" <(E-Mail Removed)> wrote in message
> >> >> news:7CB50199-DEB9-409D-A215-(E-Mail Removed)...
> >> >> > My server is running W2K and the primary application utilizes
MySQL.
> > I
> >> >> > have noticed that my C: drive has been getting more and more
> >> >> > fragmented.
> >> >> > The D: drive is good but guess on which drive MySQL is on? I am
> >> >> > defragmenting on a daily basis but the defrager spends about
> > 2-3minutes
> >> >> > and gives up on the C: drive. I'm not sure if this matters but I
> >> >> > have
> > a
> >> >> > 3-drive Raid-5 system.
> >> >> >
> >> >> > Can anyone tell me if this is a W2K or MySQL or other issue and
how
> >> >> > I
> >> >> > might be able to correct the problem?
> >> >> >
> >> >> > I appreciate the help.
> >> >> >
> >> >> > Surge
> >> >>
> >> >>
> >> >>
> >>
> >>
> >
> >
>
>