Minnesanvändning i XP

[Martin]

Claes och chilone, vad är anledningen till att använda andra defragmenteringsprogram än det som följer med operativsystemet, är det snabbhet, säkerhet eller funktioner? Har själv aldrig testat något annat än operativsystemets inbyggda.

Edit: ändrade lite på sista meningen.

För att det finns andra defragmenterings algoritmer i dem andra. En algoritm i mitt kallas "Stealth". När man kör med den så kan man i princip sitta i Reason samtidigt utan att man märker av att den defragmenterar. (smidigt) Sen kan man köra "Complete/Access" då lägger den filerna efter hur ofta du använder dem.

Utöver det man ställa in det som skärmsläckare så när man går ifrån datorn börjar den alltid defragmentera automatiskt. Man kan även lägga upp veckoscheman väldigt lätt och välja olika tider för olika diskar o.s.v.

Och Claes: Jag var trött 😛

Gör ett litet urklipp från manualen:

Each of these methods offers you an efficient and quick online defragmentation of your files, i.e., no service or application must be paused or stopped whilst the defragmentation takes place. STEALTH and SPACE are optimized for the fastest possible defragmentation of your files, whereas the COMPLETE methods provide a more thorough defragmentation. This requires more time and more free hard disk space. By re-arranging your files to use the available space as efficiently as possible, further fragmentation is avoided.

Redigerat 1 maj 2005 av chilone

[joachime]

Tack för infon!

[Martin]

- Grupperar upp allt innehåll i mappar (håller liknande filer på samma ställen).

det lär tyvärr inte göra ett skit för fragmeringen (om du inte har nått superhäftigt eget konstigt filsystem).

Det gör det faktiskt. Vet inte riktigt hur jag ska förklara det, men min intuition säger mig det 😉

Tänk att du har 25GB Wav-filer i slutet på en partition. Dem 25GB:n är konstanta.

I början på partitionen har du massor med ströfiler (40 GB). Och det är de 40 GB:en som fragmenteras ofta. Genom att du delat upp de filerna du använder mycket (ströfilerna) mot Wav-filerna (gamla sampels kanske) motverkar det fragmentation. Och framförallt går det snabbare att defragmentera för defragmenteringsprogrammet vet att de där 25GB:en har legat där så länge och används sällan. (lägger det längst bak).

Nu var det jävligt rörigt, men det blir så intrikat tänkande. Tror jag kom fram till det via lite logiskt tänkande och läsande av manueler. Och det behöver verkligen inte vara rätt 🙂

[MusicGene]

Part 2. Features of NTFS defragmentatoin

Let's return to one interesting enough and important moment - NTFS fragmentation and defragmentation. The situation with these two concepts at the moment can not be called satisfactory in any way. At the very beginning it was said that NTFS is not subject to file fragmentation. It is not exactly so and the statement was changed - NTFS prevents fragmentation. It is not exactly so either. That is it certainly prevents but... It is already clear that NTFS is a system which is predisposed to fragmentation inspite of official statements. But it doesn't suffer from it. All internal structures are constructed in such way that fragmentation does not hinder to find data fragments fast. But it doesn't save from the physical effect of fragmentation - waste disk heads motions.

To the source of the problem...

As it is known the system fragments files the best way when the free space is being ended, when it is necessary to use small-sized unused space remained from other files. The first NTFS property which directly promotes serious fragmentation appears here.

NTFS disk is divided into two areas. In beginning of the disk there is MFT area - the area where MFT grows (Master File Table). The area occupies minimum 12% of the disk, and the data record in this area is impossible. It is made not to let MFT be fragmented. But when all remaining disk is being filled in - the area is reduced twice:). And so on. Thus we have not single pass of the disk ending, but several. In result if NTFS works at the disk filled on about 90% - fragmentation grows greatly.

The incidental result - the disk filled more than on 88% is almost impossible to be defragmented - even defragmentation API cannot transfer the data in MFT area. It is possible that we will not have free space for a manoeuvre.

NTFS works and works and is fragmented - even in the case of free space is far from exhausting. This is promoted by the strange algorithm of finding free space for file storage - second serious omission. The action algorithm at any record is like this: some definite disk range is taken and filled in with a file. It is done by the very interesting algorithm: at first large unused space is filled in and then small one. I.e. the typical allocation of file fragments according to the size on fragmented NTFS looks so (sizes of fragments):

16 - 16 - 16 - 16 - 16 - [back] - 15 - 15 - 15 - [back] - 14 - 14 - 14.... 1 - 1 - 1 -1 - 1...

So the process goes up to most small-sized unused space in 1 cluster, in spite of the fact that on the disk there are also much larger pieces of free space.

Recall compressed files - at active overwriting of the large volumes compressed information on NTFS the huge quantity of "holes" are because of reallocation ñompressed cluster groups on the disk. If any file area began to be compressed better or worse, it is necessary either to take it from a continuous chain and to place in another place or to strap in size reserving unused space.

It is impossible to say that NTFS prevents file fragmentation. On the contrary it fragments them with pleasure. NTFS fragmentation can surprise any person familiar with file system operation in half a year of work. Therefore it is necessary to launch defragmentation. But here all our problems are not ended, they only start...

Means of the decision?

In NT there is standard API defragmentation. It has the interesting limit for files block relocating: it is possible to transfer not less than 16 clusters (!) at once, and these clusters should start from the position16 clusters aligned in a file. In common, the operation is carried out extremely for 16 clusters. The results:

It is impossible to transfer anything in the unused space less than 16 clusters (except compressed files but it is not interesting at the moment).

A file being transferred in another place leaves (in the new place) "the temporarily occupied space" adding it on the size up to multiplicity to 16 clusters.

At attempt to transfer a file the wrong way ("not multiply to 16 ") the result is often unpredictable. Something is just not transferred, but the whole arena is gracefully littered wit "the temporary occupied space". These "the temporarily occupied space" serves for simplification of system restoration in the case of a machine failure and is usually freed half a minute later.

Nevertheless it would be logical to use this API if it is in stock. And it is used. Therefore the standard defragmentation process with the corrections on limitation API consists of the following phases (not necessarily in this order):

Files extraction from MFT area. Not specially - just because it is impossible to put them back. This phase is harmless and even somehow useful.

Files defragmentation. Unconditionally it is a useful process but a bit complicated by limitings of relocatings multiplicity - we have to move files more that it would be otherwise necessary.

MFT, pagefile.sys and directories defragmentation. It is possible through API only in Windows2000, in the opposite case - at reboot, as a separate process like in old Diskeeper.

The addition of files is closer to the beginning - so-called free space defragmentation. It is a terrible process...

If we want to put files on end in the beginning of the disk, we shall put one file. It leaves unused space from its end up to the block (16 clusters) boundary for alignment. Then we put the following, and after that we have the unused space of size less than 16 clusters. Then it is impossible to fill in it through API defragmentation! In result before optimisation the overview of free space looked like this: there were a lot of unused space of the same size. After optimisation - one "hole" at the end of the disk, and a lot of small < 16 clusters ones in the section filled by files. What places are first to be filled in? mall-sized "holes" < 16 clusters taking place closer to the beginning of the disk... Any file slowly built on optimised disk will consist of great number of fragments. Then the disk can be optimised again. And then once again...

Thus there are two about equivalent options. The first one is to optimise the disk often by such defragmentator paying no attention to such great fragmentation of the newly created files. The second variant is not to change anything and put up with regular but much weaker fragmentation of all disk files.

While there is only one defragmentator which ignores API defragmentation and works more directly - Norton Speeddisk 5.0 for NT. When it is compared to all remaining - Diskeeper, O&O defrag, etc. - the main difference is not mentioned. It is just because this problem is carefully hidden. Speeddisk is the unique for today program which can optimise the disk completely not establishing small fragments of free space.

Unfortunately the defragmentator working through API which makes unused space <16 clusters was placed in Windows 2000.

All remaining defragmentators are just harmful at one-time application. If you launched it even one time, you would need to launch it then at least once a month to be saved from new files fragmentation. This is the problem of NTFS defragmentation by old means.

frånhttp://www.digit-life.com/articles/ntfs/

[LDB]

Kör själv Norton SystemWorks. Kostar runt 500 spänn på DustinHome, inkl antiVirus.

Finns en rutin i SystemWorks för att optimera hårddiskarna. Alltså läggs alla filer som ändras/läses ofta i början av partitionen/disken där åtkomsttiden är minst. Filerna som läses/ändras sällan eller aldrig läggs i slutet av disken. Samtidigt defragmenteras disken. Tar typ 1-2 timmar för en 100Gb disk om man kör det regelbundet.

Dessutom finns möjlighet att rensa XP-registry vilket kan vara ett riktigt lyft om man installerat och ominstallerat mjukvaror eller om man håller på med inspelningar då många tagningar skapar länkar som sedan raderas. XP-registry växer ju väldigt snabbt. Rensningen tar typ 1 minut bara!