Article View: alt.certification.mcse
Article #130Re: 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
235 lines
10673 bytes
10673 bytes
Aaron <chaaron@lave.net> wrote in message news:7povsr$adq$1@mochi.lava.net... > Rod Speed wrote in message ... >> Aaron <chaaron@lave.net> wrote I've flushed all your childish stuff. There isnt much left. >>>>>>>>> just to keep it orderly. >>>>>>>> You can have exactly the same orderly with trees >>>>>>>> off directorys in the root if you are that obsessive. >>>>>>> Yea, and then those apps that would only install >>>>>>> to C, can fill in all the fragments of 10gig instead >>>>>>> of 2, leaving you with an app that runs really slow. >>>>>> Doesnt work like that. Fragmentation is no big deal >>>>>> on a very large partition like that. Fragmentation is >>>>>> much more of a problem with multiple partitions. >>>>> Please explain that one. >>>> Partions become fragmented quickest when there is less free >>>> space. A single partition for the whole drive inevitably sees more free >>>> space in the partition, so fragmentation is rather less of a problem. >>> Oh, that is why a drive that has half the space available >>> always has most of the data in the first half of the drive. >>> Free space doesn't matter as much as you think. >> Sure does when there isnt much free space >> as far as fragmentation is concerned. >>> Ever look at the details view of Defrag? >> I might well have done. >>> On any disk that is not full, there is almost no data at the very end >>> of the disk, where the last bastions of free space would be dug in. >> Got SFA to do with how quickly a drive fragments >> when there isnt much free space and there is quite >> a bit of activity on that drive with larger files. > Right. Activity and large files. Thats what produces fragmentation, particularly with not much free space. > 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. > the files are getting fragmented. Nope, coz your 'doesnt use the rest of the drive' doesnt happen, and files dont get fragmented. > 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. > 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. >>>>> 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. 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. > 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. >>> 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. > 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. > 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. > 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. > 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. > Fragmentation doesn't go much deeper than that. Fraid it does.
Technical Details
Message-ID:
<mc0w3.6887$O_1.48574@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>Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 100597,5f6974e49456f2b4 X-Google-Attributes: gid100597,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: 1070cf,5f6974e49456f2b4 X-Google-Attributes: gid1070cf,public From: "Rod Speed" <rodspeed@ozemail.com.au> Subject: Re: help, windows will only start in safe mode Date: 1999/08/23 Message-ID: <mc0w3.6887$O_1.48574@ozemail.com.au> X-Deja-AN: 515962198 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> X-Priority: 3 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Trace: ozemail.com.au 935366546 203.108.163.25 (Mon, 23 Aug 1999 10:02:26 EST) Organization: OzEmail Ltd, Australia X-MSMail-Priority: Normal NNTP-Posting-Date: Mon, 23 Aug 1999 10:02:26 EST Newsgroups: alt.certification.mcse,alt.computer,alt.os.windows95,alt.windows95,alt.windows98,aus.computers