Archived from groups: microsoft.public.win2000.file_system (
More info?)
Prior to running any sort of utility that can change the cluster size, I
would agree with Pat and strongly suggest that you backup everything (and
verify that you can read the backup).
We have seen instances where the file system looks at little "wierd" after
using a tool to change the cluster size. While the end result is
technically "legal", some of the file system internals end up in a state
that could never be gotten to if the drive was initially formatted with a 4k
cluster size.
- Greg/Raxco Software
Microsoft MVP - Windows File System
Want to email me? Delete ntloader.
"Pat [MSFT]" <patfilot@online.microsoft.com> wrote in message
news:e4L3vfcbEHA.1408@TK2MSFTNGP12.phx.gbl...
> I don't think that Paragon supports resizing the cluster size (though it
can
> resize the partition). The latest Partition Magic (v8.0) can, according
to
> their site, resize the clusters w/out data loss. I have never used
Paragon
> and have not used Partition Magic in quite a while. My only advice would
be
> (obviously) to back up anything you could not bear to lose prior to doing
> any low level disk operations. Generally speaking, there is no rollback.
>
>
> Pat
>
>
>
> "Surge" <Surge@discussions.microsoft.com> wrote in message
> news:ABDA6A7A-911B-4D51-BC68-53DDB8EF5633@microsoft.com...
> > Pat,
> > One final question. I've read some threads that indicate that
applications
> > such as Paragon Partition might be able to correct this problem. Would
you
> > have any experience or words of wisdom concerning such applications?
> >
> > Thank you and regards,
> > Surge
> >
> > "Pat [MSFT]" wrote:
> >
> >> Nope. The cluster size is tied to the volume. So, you would have to
> >> re-format at that level to get anything.
> >>
> >> Pat
> >>
> >> "Surge" <Surge@discussions.microsoft.com> wrote in message
> >> news:5EEC1859-9CAA-4A1D-85F7-522F3F936FD9@microsoft.com...
> >> > 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" <Surge@discussions.microsoft.com> wrote in message
> >> >> news:1AACC5F5-99BF-4819-8BAC-8A51C350B377@microsoft.com...
> >> >> > 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" <Surge@discussions.microsoft.com> wrote in message
> >> >> >> news:7CB50199-DEB9-409D-A215-DDAF0A6741E6@microsoft.com...
> >> >> >> > 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
> >> >> >>
> >> >> >>
> >> >> >>
> >> >>
> >> >>
> >> >>
> >>
> >>
> >>
>
>