🚀 go-pugleaf

Rod Speed wrote in message ...
>
>Aaron <chaaron@lave.net> wrote in message news:7pu7gj$7pn$1@mochi.lava.net...
>> Tom MacIntyre wrote
>
>>> Hyper, a good post, and the only scenario that I would
>>> add is that fragmentation also occurs as files (data, text)
>>> grow in size, past increments of the cluster size, where
>>> the next cluster is no longer available. This type of event
>>> is more likely on a FAT32 drive with its smaller clusters,
>>> if there are many smaller data/text files being generated.
>
>Wota pity that particular scenario wasnt even being discussed.
>
>What was being discussed was the boot drive, using
>FAT32, with either a single partition for the whole
>drive, or a multiple paritions. BOTH were using FAT32.
>
>> Great point Tom.
>
>Nope, just another complete missing of the point of what was being discussed.
>
>> I had thought to explain that fragmentation happens this way too, but
>> found that Rod can't handle the mental imaging of files getting larger.
>
>Pathetic really. I've been doing it since before
>you were born boy. Including using an OS that
>only ever wrote contiguous files for just that reason.
>
>> Never thought to correlate it to the smaller cluster of FAT32.
>
>Completely pointless when the alternate scenarious were BOTH Fat32.
>
>> Of course more fragmentation would occur
>> with a cluster size of 4KB instead of 16KB.
>
>Aint gunna happen when using multiple partitions
>or one partition WITH A FAT32 DRIVE.
>
>> As you add to a report or database, the
>> file will be fragmented all over the drive.
>
>Complete tripe. And YOU claimed that it would all end up on the front
>of the drive with the free space all down the back of the drive too. Wrong.
>
>> Actually, I have been thinking it would be nice to be able to reserve
>> a certain amount of space at the end of a file to prevent this.
>
>And that is precisely what happens with a decent database
>system. The file system cluster size is completely separated
>from what the database system does about extending the file.
>
>So your claim higher up is just plain wrong. As usual.
>
>> If each document file were to tag the next few clusters when it is saved,
>> and those tagged clusters would be preserved even after the drive is
>> defragged, then the file could have room to grow without fragmenting.
>
>That happens to some extent too. Not 'tagged', just that the
>file doesnt increment by one cluster at a time in normal use.
>
>> Maybe a check box available for certain file types
>> or programs, such as *.doc files, or the MS Word
>> program.  Same with database files and programs.
>
>Much better looked after by the app, and thats what happens.
>
>> But of course it isn't a big deal for me, as I only have to defrag
>> one drive usually anyway, where I keep my documents
>> and databases and files that I download off the web.
>
>And any decent defragger that doesnt mindless move around
>static files, will do just as well with a single partition too. The static
>files just stay at the front of the drive and the stuff that changes
>ends up at the boundary between the used and free space.
>
>
Rod, you have mentioned this "decent defragger" before, but I
am wondering what the name of it is.  Obviously you don't mean
the Windows Defrag.  What one do you use?
--
Aaron Marks