Article View: alt.certification.mcse
Article #114Re: help, windows will only start in safe mode
From: Rod Speed
Date: Mon, 23 Aug 1999 00:00
Date: Mon, 23 Aug 1999 00:00
335 lines
14614 bytes
14614 bytes
Hyper <jimb@snip.net> wrote in message news:37C0B916.67BA455@snip.net... > Rod Speed wrote >> Aaron <chaaron@lave.net> wrote >>> Rod Speed wrote in message ... >>>> Aaron <chaaron@lave.net> wrote >> I've flushed all your childish stuff. There isnt much left. > I've printed this message and flushed it down the toilet, how's that? Not good enough. If you cant manage any better than the childish stuff you have below, I'll be doing that with your crap too. >>> If the large FAT32 20GB drive has all the files at the beginning of >>> the drive, within the first 5GB, and doesn't use the rest of the drive, >> Doesnt happen. > yes it does Have fun explaining the drive I've currently booted. The figures arent that far from those above, 12GB drive, 6.5GB free. The files arent anything like all up the front of the drive, the space between the first and last file is about 50% free space, with huge holes, much bigger than the biggest files on the drive. It was obviously in his scenario after the clean install, and its nothing like that now, so his claim is complete crap. Bugger all has been wiped from the drive since the clean install too. Never been defraged. >>> the files are getting fragmented. >> Nope, coz your 'doesnt use the rest of the drive' >> doesnt happen, and files dont get fragmented. > see above see above >>> If the files were instead spread evenly over the disk, being placed >>> into the available free space, than they would not be fragmented. >> You dont need to spread the files right thru the drive to get >> a different result on fragmentation with that particular situation. > i really don't understand the point your making That 'the files were instead spread evenly over the disk' aint the only way to get little fragmentation with a drive with that much free space. >>> Since they are not being put in the free space, >> They cant go anywhere else. If a new file isnt being put into free space, >> it can only overwrite an existing file, and that obviously aint gunna happen. >>> they are being fragmented and placed in many >>> open spaces in the first part of the drive. >> Wrong. > sorry, that's entirely correct Nope. Have fun explaining the layout of the drive I'm currently booted off if it was. >>>>>>> If I install some applications to drive H:, then defrag >>>>>>> H:, it doesn't get very fragmented because I am not >>>>>>> constantly writing to it, and removing files from it. >>>>>> Yes, but a decent defragger doesnt mindlessly >>>>>> move that stuff around much too. >>>>>>> With one drive, you are constantly writing and >>>>>>> deleting files on that drive. No way around it. >>>>>> Yes, but if its got plenty of free space, and thats common with a single >>>>>> partition for the big drives we are discussing, they dont fragment much. >>>>> Again, you don't appear to understand how the free space is used. >>>> Again, you dont appear to have a clue about >>>> what produces significant fragmentation. >>>> And fragmentation is about FILES being fragmented and >>>> increasing the time to access that file because its fragmented. >>> Right, FILES being broken into many pieces, and those >>> pieces being placed into various available places on the disk. >> Doesnt happen with that 20GB FAT32 partition with 15GB free. > big old WRONG! Wota stunningly rational line of argument you have there. This is the crap that'll just get flushed if you cant manage any better than that. >> Happens far more if the drive is chopped up into separate >> partitions so there is much less free space in the partitions >> where there is much file writing activity. > WRONG! see above. >>> Those places are near the front of the drive. Newly formed files are >>> not simply places at the end of the 'used area' of the drive, they are >>> usually fragmented and placed in available holes in that used area. >> Wrong in that situation being discussed, a >> 20GB FAT32 drive with 15GB of free space. > what will happen is this. you have your nice > huge drive, little quick picture here for you: > |xxxxxxxxxxxxxxxxxxxxxxx| > |xxxxxxxxxxxxxxxxxxxxxxx| > |xxxxxxxxxxxOOOOOOOOOOOO| > |OOO | > | | > | | > let's pretend this is a picture of your drive in my cheap little 30 second ascii > world. x's are data and apps and whatever, O's are your swap file, the picture > isn't to scale or proportional to a 20 gig drive or anything, but follow along. > right now, it's at 0% fragmentation. now, let's say you delete a few things: > |xxxx xxxx xxxxxxxxxxxxx| > |xx xxxxxxxxxxx xxxxxxxx| > |xxx xxxxxxxOOOOOOOOOOOO| > |OOO | > | | > | | > you now have a few places that have little gaps in there, > still not really fragmented, as all of the data is still grouped > together. now, you install an app, represented by N's > |xxxxNxxxxNxxxxxxxxxxxxx| > |xxNxxxxxxxxxxxNxxxxxxxx| > |xxxNxxxxxxxOOOOOOOOOOOO| > |OOONNNNNNNNNNNNN | > | | > | | > what happened here? the app is installed in the first free > space on the drive, those little N's and stuff that are scattered > about are that apps files. you now have fragmentation. Only with your bogus little scenario where you have carefully chosen to delete just small files, and install large ones. Its nothing like the situation being discussed, a completely clean reinstall onto a 12GB drive which has been repartitioned into a single partition. In that case most of the installed stuff will be clustered at the front of the drive, and certainly will if you use a decent defragger after the completely clean reinstall, if you are that anal about fragmentation. And whether using multiple partitions on that drive instead helps any with fragmentation. It doesnt. I've flushed the rest of your long winded rambling, not relevant to what was being discussed, how to partition a FAT32 Win9x system when doing a completely clean reinstall. >>>>> Ever see a drive with data spread evenly across the surface, >>>>> when only a third of the clusters are full? Neither have I. >>>> Got nothing to do with fragmentation. >>> Obviously you can't get the picture in your >>> brain of what a fragmented drive looks like. >> Crap. > see above, i gave you a lot of pictures Completely irrelevant to the situation being discussed. >>> If you never use a defragger program, and you are creating and deleting >>> files, or adding to them, such as business reports that take you several >>> days to finish, your data is going to be fragmented. No question about that. >> Wrong with that particular situation being discussed, >> a 20GB FAT32 partition with 15GB of free space. >> And completely trivial to prove that. >>> If, as you say, the magical properties of free space on a drive were enough >>> to keep the drive from being fragmented, than why are the files fragmented. >> Files get fragmented when the partition has rather less free space on it. >> Particulary when the free space ends up being scattered right thru the >> drive and in mostly relatively small pieces. When a large file is written to >> that particular partition, there aint any choice on fragmenting it. With a drive >> with a much larger percentage of free space, as you said, the free space >> does end up clustered towards the end of the drive, so a new large file can >> usually be written unfragmented into that much larger chunk of free space. >> Completely trivial to prove too, use one of the utes that displays fragmented >> files graphically, write a new large file to that FAT32 20GB drive with 15GB >> of free space, and see where it gets written, and whether it gets fragmented. >>> They are fragmented because the system doesn't care >>> about how much free space is at the end of the drive. >> In practice it effectively does when the vast bulk of the files on that particular >> drive are relatively static files that dont move, clustered at the front of the drive. >>> For the most part, it breaks up files, and places >>> them in available holes in the front part of the drive. >> Wrong, if only because in that particular scenario, you dont get that >> much in the way of holes in the front part of the drive, because they >> are static files that end up being put there by a decent defragger. >>> If the free space were used by the system to write larger files, >>> without them being fragmented, than a disk which is only half full, >>> would have data spread across the entire surface of the drive. >> You've mangled that completely too. That only happens >> when the percentage of free space is getting low. >>> So, I ask, have you looked at the details view of Defrag? >> Corse I have. >>> If this is what you see, after going for a few months without >>> defragging the drive, then you would be correct. The free >>> space made a difference. But this is not what you would see. >> Fraid so. Have done just that on the free space >> making a dramatic difference to fragmentation. >>> There is only significant use of the second half >>> of a drive when the drive is over half full of data. >> Thats just simple arithmetic, if the drive is over half >> full of data, the second half of the drive has to be used. > if the drive is less than half full, however, the > second half WON'T get touched, period Wrong, and visibly wrong with the drive I am currently booted on. >>> There is only significant use of the end >>> of the drive when the drive is about 3/4 full. >> The end of the drive is irrelevant. What matters is fragmentation. > you missed the point Nope. >>> The end is not used just because you have 2GB of files on a >>> 20GB drive, no matter how much you manipulate that 2GB of files. >>> The files will be fragmented no matter how much free space you have. >> Crap. >> Try taking a FAT32 20GB drive, with 15GB of free space. Defrag >> it. Repeatedly copy around a very large file. It wont get fragmented. > no it won't, now make a hundred small files, delete 15 of them, now install > something on that drive, or copy something, whatever, see the fragmentation? Wota pity that that aint gunna happen with the scenario being discussed, a clean reinstall on a 12GB drive. You'll get bugger all fragmentation worth bothering with, because you wont be deleting lots of files from the front of the drive, particularly if you anally defrag the drive after doing the clean reinstall. And if you are just talking about data files alone, you'll get precisely the same fragmentation with those data files on their own partition, with less free space on the drive, so you'll get more fragmentation if you do much with large files copying and deleting wise. >>> That is what an even spread of data has to do with fragmentation. >> You've mangled the story completely. >>>>>>> I keep my working files on one partition, and it >>>>>>> does get fragmented, the others generally don't. >>>>>> And single partitions for the whole large drive >>>>>> being discussed dont get fragmented much either. >>> Since I haven't added anything to my Apps drive for a few months, >>> and fragmented it after installing anything, which do you think is >>> more fragmented? My apps drive, or your 20GB drive? >> The 20GB drive aint fragmented enough to warrant defragging >> it to get better performance. THATS what matters. >>>>>>>>> Not to mention the need to defrag the >>>>>>>>> entire drive when only one partition needs it. >>>>>>>> And defragging is needed much less >>>>>>>> with a single partition for the entire drive. >>>>>>> You are still causing file fragmentation to occur, >>>>>>> no matter the size of the partition or drive. >>>>>> Its more complicated than that. >>>>> Yes it is, but I didn't have time to write a thesis paper. >>>> Or have a clue about fragmentation either. >>> When you manipulate files on a disk, they get fragmented. >> Not when there is plenty of free space. > you are assuming that your drive doesn't have any files deleted off of it, Nope, just assuming that with a completely clean install, you wont get any different effect on that stuff than with the data in a separate partition, and you will have much more free space with a single partition, so you wont see the other effect, significant fragmentation when the free space is getting to something like the size of the large files copied and deleted. Most dont actually do much of that anyway on the very large files. > which leaves holes which get filled with other data from other programs and such Just as true of a separate partition for the data, so his claim that there is an advantage in that is just plain wrong. >>> Fragmentation doesn't go much deeper than that. >> Fraid it does. > no, it doesn't Fraid it does.
Technical Details
Message-ID:
<7q8w3.7189$O_1.49659@ozemail.com.au>Path:
arc1-ca.pugleaf.net!unknown!not-for-mailReferences:
<7pa1p4$32i$1@ffx2nh5.news.uu.net> <ET5u3.3532$O_1.20832@ozemail.com.au> <37B8FA7A.63CBEE72@snip.net> <7pbg26$1p8$1@mochi.lava.net> <LZku3.3975$O_1.24517@ozemail.com.au> <rrkt80ge3uk62@corp.supernews.com> <KDwu3.4394$O_1.26477@ozemail.com.au> <7pgnc8$dd7$1@mochi.lava.net> <b8%u3.5129$O_1.34931@ozemail.com.au> <7pivo2$n65$1@mochi.lava.net> <aNmv3.5785$O_1.42099@ozemail.com.au> <7povsr$adq$1@mochi.lava.net> <mc0w3.6887$O_1.48574@ozemail.com.au> <37C0B916.67BA455@snip.net>Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1070cf,5f6974e49456f2b4 X-Google-Attributes: gid1070cf,public X-Google-Thread: 1020d9,5f6974e49456f2b4 X-Google-Attributes: gid1020d9,public X-Google-Thread: f42b5,5f6974e49456f2b4 X-Google-Attributes: gidf42b5,public X-Google-Thread: 108c83,5f6974e49456f2b4 X-Google-Attributes: gid108c83,public X-Google-Thread: fde9e,5f6974e49456f2b4 X-Google-Attributes: gidfde9e,public X-Google-Thread: 100597,5f6974e49456f2b4 X-Google-Attributes: gid100597,public From: "Rod Speed" <rodspeed@ozemail.com.au> Subject: Re: help, windows will only start in safe mode Date: 1999/08/23 Message-ID: <7q8w3.7189$O_1.49659@ozemail.com.au> X-Deja-AN: 516098694 Distribution: world References: <7pa1p4$32i$1@ffx2nh5.news.uu.net> <ET5u3.3532$O_1.20832@ozemail.com.au> <37B8FA7A.63CBEE72@snip.net> <7pbg26$1p8$1@mochi.lava.net> <LZku3.3975$O_1.24517@ozemail.com.au> <rrkt80ge3uk62@corp.supernews.com> <KDwu3.4394$O_1.26477@ozemail.com.au> <7pgnc8$dd7$1@mochi.lava.net> <b8%u3.5129$O_1.34931@ozemail.com.au> <7pivo2$n65$1@mochi.lava.net> <aNmv3.5785$O_1.42099@ozemail.com.au> <7povsr$adq$1@mochi.lava.net> <mc0w3.6887$O_1.48574@ozemail.com.au> <37C0B916.67BA455@snip.net> X-Priority: 3 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Trace: ozemail.com.au 935400195 203.108.163.71 (Mon, 23 Aug 1999 19:23:15 EST) Organization: OzEmail Ltd, Australia X-MSMail-Priority: Normal NNTP-Posting-Date: Mon, 23 Aug 1999 19:23:15 EST Newsgroups: alt.certification.mcse,alt.computer,alt.os.windows95,alt.windows95,alt.windows98,aus.computers