Re: Page File Defragmentation
From: Gerry Cornell (gcjc_at_btinternet.com)
Date: 07/10/04
- Next message: johnny xia: "Can keybd_event and mouse_event send user input to a window in a hidden desktop"
- Previous message: Will Denny: "Re: XP Home and Professional"
- In reply to: David Candy: "Re: Page File Defragmentation"
- Next in thread: Alex Nichol: "Re: Page File Defragmentation"
- Messages sorted by: [ date ] [ thread ]
Date: Sat, 10 Jul 2004 09:23:58 +0100
David
Thanks for the comments. Of course from the picture of the disk one cannot
tell how large bits of free space are and 500 kb is quite small in global
terms.
Where did you get the 500 kb detail from? Do you know whether files are
written byte by byte or in multiples of a certain size? I am just trying to
figure out a logical explanation for so many copies of a single file
creating an identical number of fragments when differing numbers of
fragments would seem more likely if available space was the only governing
factor.
~~~~~~
Regards.
Gerry
~~~~~~~~~~~~~~~~~~~~~~~~
FCA
Stourport, Worcs, England
Enquire, plan and execute.
~~~~~~~~~~~~~~~~~~~~~~~~
"David Candy" <david@mvps.org> wrote in message
news:uae2mHjZEHA.2944@TK2MSFTNGP11.phx.gbl...
I've not seen the file write alogarithms for NTFS but
Fat 16 under Dos/Win9x is start writing at beginning of disk using whatever
free space you find.
Fat32 on (9.x) start searching from whereever the heads happen to be at this
moment for a 500K of contiguous space to write (this is done in memory). If
no 500K space just write it.
MS always claimed NTFS does not need defragmenting. The defrag is a
marketing tool as 9x people know defragmenting is important and NT people up
to ver 4 hotly debated it. Not that anyone believed them in an absolute
sense.
-- ---------------------------------------------------------- 'Not happy John! Defending our democracy', http://www.smh.com.au/articles/2004/06/29/1088392635123.html "Gerry Cornell" <gcjc@btinternet.com> wrote in message news:ORqnqyeZEHA.2844@TK2MSFTNGP12.phx.gbl... > Alex > > My initial reaction was to take your words "Again your restore points are > fragmented because there is no contiguous space for a complete cab (they > start off as a big set of smaller files that may have been in different > locations anyway)" as one, of more than one, explanation for the > fragmentation. Each restore point is shown as 19 mb on a partition with > 1.35 gb free space; free space equating to 32% of the size of the > partition. There is also a long run of contiguous free space. The position > is not, however, as I have now come to appreciate , what it appears to be. > Your latest post has changed my views on several of the details. > > The Report in Disk Defragmenter ( I am guessing ) is actually reporting > single files, which are only part of the restore point. Until this moment in > time I have been wrongly taking these to be the restore point. A silly > mistake on reflection! The 19 mb file covers part of the registry, namely > "Machine_Software". You cannot see this in the Disk Defragmenter Report > because the file description is so long that the file name is not visible. > As of this moment I have 9 such files; each were 19 mb but 8 of these files > have been compressed to 9 mb when the next restore point was created. Of > course "Machine_Software" is only the largest of a number of files, some > being quite large. I have 9 files ( objects.data ) at 5 mb or 1 at 5 mb with > 8 compressed to 2 mb. It emerged in earlier conversations that the accuracy > of some figures provided by the Disk Defragmenter tool may not be reliable, > noticeable where they differ from Windows Explorer which is seen to be more > accurate. Someone else's point, not one I think that you or I originally > picked up on. > > Each restore point on my machine is of the order of 35-40 mb and with 9 > restore points this equates to about 340 mb before compression or nearly 25 > % of the free space of 1.35 gb. If compression means rewriting the file to > another location you are looking at the utilisation of another 80 mb. > > Speculation on my part but I suspect another factor which may be coming into > play could be that the system writes data to disk from the beginning of the > disk to the end and then starts again at the beginning of the disk at the > first free space available. Each time it writes to disk it begins at the > point where it last wrote to disk. If it needs 19 mb for a file it does not > look for a contiguous 19 mb space but stuffs every nook and cranny it finds > as it moves across the disk. You would know more about how disk writes > occur. Is this the way it works? The result being fragmented files. However, > I am puzzled as to why each "Machine_Software" file has identical numbers of > fragments. I would have expected similar not identical numbers. > > I think some of the points I am making are ones you have hinted at in > previous conversations between us, which have not registered with me. Others > are me trying to rationalise from what I have seen. Please point out any > which you see as not being correct or better put a different way. We do seem > to differ in that you are saying that there is not the contiguous space > whereas I am suggesting that the system selects the free space more > immediately available. > > I do find your reference to the pagefile confusing. Perhaps because you are > making points about two different computers in the same paragraph. The page > file reference has application to the other persons situation but not to my > own computer, where the pagefile is in a different partition to the restore > points under discussion. > > I am not sure that your linkage of consolidation of free space to > fragmentation of restore points will always be germane. If you do not need > to access any System Restore file how does a fragmented file impact on > system performance? If there is no pagefile within the partition a major > cause of fragmentation of free space is removed. Does this not significantly > reduce the need for a third party Defragmenter? What affect does running > Disk Defragmenter immediately after rebooting rather than after having > performed other tasks have? Is it not the case that free space will become > more fragmented where unmovable files are present and less so when those > present are occupying far less space with a fragmented pagefile being the > major occupier of space? > > The issue with restore points, which you made before me, was that after > perhaps 10 / 14 days they lose their value but System Restore keeps > generating daily further restore points for up to 90 days within the disk > space limitation i.e. 12% of the hard disk. In situations where disk space > is at a premium System Restore is wasteful of a scarce resource. I think we > are agreed on this. An unresolved point is how to keep a restore point some > days old and one created yesterday but to delete the ones created in > between. This does not seem possible without corrupting the control files > which manage the System Restore function. At least I think that is where we > are? Your preferred solution seems at present to be if the user has > confidence in the current state of their system to reset system restore > thereby losing all existing restore points. An alternative is to use Disk > CleanUp to remove all but the last restore point. There is also an > unresolved issue of whether and in what circumstances one might change the > default disk space maximum of 12% to a lower figure. > > > ~~~~~~ > > Regards. > > Gerry > > ~~~~~~~~~~~~~~~~~~~~~~~~ > FCA > > Stourport, Worcs, England > Enquire, plan and execute. > ~~~~~~~~~~~~~~~~~~~~~~~~ > > "Alex Nichol" <alexn.mvpdts@ntlworld.delete.com> wrote in message > news:im6te0tl2ho17g3pcd5v17b6ahm6tfjkk7@4ax.com... > > Gerry Cornell wrote: > > > > > > > >System restore folders seem to break into large numbers of fragments! > Just > > >looked at mine -622 fragments! This is on an NTFS formatted partition > with a > > >4 kb cluster. > > > > That is of little consequence; you are probably not going to use the > > files, and anyway only once. > > > > The 48000 fragments of page file is unusual. It will have arisen > > because the inbuilt defrag does *not* consolidate free space, and that > > has got into a slew of tiny fragments, and incremental growth of the > > page file has latched onto them one by one. Again your restore points > > are fragmented because there is no contiguous space for a complete cab > > (they start off as a big set of smaller files that may have been in > > different locations anyway) You will only get free space consolidated > > by a third party program - and IIRC Diskeeper does not do it either (or > > not in normal use), which is a main reason I prefer (and use) Perfect > > Disk. Then having consolidated, set the initial size of page file big > > enough to cover normal need (but with a high max against contingencies > > and for other reasons) so it starts off in one piece > > > > > > > > -- > > Alex Nichol MS MVP (Windows Technologies) > > Bournemouth, U.K. Alexn@mvps.D8E8L.org (remove the D8 bit) >
- Next message: johnny xia: "Can keybd_event and mouse_event send user input to a window in a hidden desktop"
- Previous message: Will Denny: "Re: XP Home and Professional"
- In reply to: David Candy: "Re: Page File Defragmentation"
- Next in thread: Alex Nichol: "Re: Page File Defragmentation"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
