So then, you are saying that file fragmentation does NOT exist? And quite possibly never has? Or are you just saying that the Swap/Paging file has nothing to do with it?
Yeah, file fragmentation doesn't exist, that's exactly what I said. If you stopped skimming through my posts before getting diarrhea of the keyboard you would find you wouldn't be repeating the same sad rant over and over.
Just what style of Cracker Jacks did you get your certification from? Because I guess I've been looking in the wrong boxes.
Don't be so quick to pass judgement, I've still yet to see something intelligible in one of your posts.
It has already been identified that any file, even a TMP file, once written to a hard disk, shall remain untill such time as the space it takes up is overwritten. That space will never be overwritten unless/until that space is identified in the FAT table as being open and available for use.
Correct, it stays there until the entry in the FAT tables is deleted, and then it becomes free space.
If you read that MP3 file from a disk seperate from that which holds the virtual memory, and you never make any changes to that MP3 file, then it just stands to reason that it won't get moved around. Simply because nothing else is likely to be written to that disk before that file's use is complete. It can then be listed as being right back exactly where it came from.
See this is where I'm postive you're wrong. When you read a file from a hard disk the entry in the FAT table is not removed, and the file doesn't change at all. The file is still there on the disk, even if the swap file was on the same drive and data was read/written into the swap file. The file isn't removed from that portion of the drive and then written back when you close the program reading the file. It just doesn't happen that way, nor would it make sense to because of the unecessary bandwidth being eaten up.
Like I said before, try moving the virtual memory to the same drive as holds those MP3 files, then monitor the fragmentation on all drives. The drive, usually C:, which first held the V/M will show a marked reduction in fragmentation. While the drive which NOW holds it will show a marked INCREASE in fragmentation. This is one of the top reasons why, for so very long, those who wished maximum performance from their systems kept one extra drive on their system which was NOT used for user files. This drive was effectively dedicated for no other purpose then to house the Swap/Paging file.
Actually for maximum swap file performance the swap file should be striped across several drives not simply dumped onto a dedicated drive. That was even published in Maximum PC and can also be found in Logic's old UltraTech knowledge base.
As for file fragmentation, the virtual memory file doesn't cause it. I've got one system with 2GB of RAM and occasionally I've run it without any virtual memory at all. With this configuration, I'd still get fragmentation on my drives. Why? because at the very root of this entire thread which seems to be going on a lot longer then it should, fragmentation occurs simply because hard drives are lazy and will write any new data onto the nearest free space on the drive, which means if it needs space in several different places that's where it's going to put that data, which in turn, will be fragmented.
On Windows95 systems, using an old Seagate 127Mb drive was considered best for this purpose. As those drives were tough enough to handle the near constant read/write. (the older LARGE size drives lacked dependability what they gained in size)
I do hope you're referring to Windows 95 OSR2.x because the first two versions could only support 2GB volumes max. It'd really suck to have to partition a 127GB drive 60plus times.
Another means of raising the performance of systems was to lock the Swap/Paging file to a specific size, depending of course on the use you planned for that system. Usually up to about 4X the amount of physical RAM on the system, although some few may have set it higher. This had the effect of ensuring that there was ALWAYS enough room for the virtual memory while allowing the user to be certain of just how much of that drive was available for his/her own, user programs. It was also found that this practice tended to REDUCE file fragmentation to a measurable extent
Locking the swap file to a specific size won't reduce file fragmentation, it'll only stop fragmentation of the swap file itself because it won't be spread out in fragments across the drive when Windows decides to change the size.
I'm pretty sure this has been mentioned many times before on this forum that it's recommended to remove the swap file entirely, defrag the drive, then created a locked swap file, this will ensure that your swap file isn't fragmented at all, and being locked, never get fragmented.