Disk defragmenter in Linux

John Summerfied debian at herakles.homelinux.org
Wed Dec 28 13:39:48 UTC 2005


Tim wrote:
> On Wed, 2005-12-28 at 07:57 +0800, John Summerfied wrote:
> 
>>Might I observe that the many-partitions layout so often recommended 
>>gives you all the disadvantages of a fragmented drive from day one?
> 
> 
> Though, that would be in situation where the system is trying to read
> several different files at once.  

In a multi-tasking multi-user system that's quite probable. SUSE, for 
reasons I don't understand, tries to run the daily housekeeping every 24 
hours, timed from when the system last booted: if you boot at 8:00 then 
the housekeeping's done then and at 8:00 daily until the next boot.

I'm often using the system at 06:00 (Debian's time) and even sometimes 
at 04:00.

Then there's my tendency to run programs to read files and stuff their 
contents into a postgresql database on the same system, do download 
details of homes for sale and process the HTML to remove ads and other 
noise, or to point Mozilla at theregister.co.uk and then middle-click 
(opens links in a new tab) every unread interesting-looking story.

 > And even with one partition, it can
> still act that way, because your commands and your data files (for
> instance) might be nowhere near each other on the disk structure.

"can act that way" is quite different from "forcing it to act that way."

> 
> If you were doing something that needed very little interruptions of
> data traffic, like high resolution video capture straight to disk, I'd
> be recommending that you had a separate drive for such things, on a
> different host controller, too.
> 
> But I doubt, that for most people, the differences in timing between one
> partition or many are going to be that noticeable.  I've run systems
> using various permutations of partitions, none was really noticeably
> faster than others.  My main like for partitioning is other reasons.

OTOH years ago, when I used OS/2, I had two drives and thought my data 
drive was the right one for swap. I was very quickly disabused of that 
notion: my data got hit way harder than programs.


> 
> e.g. Ever had to sit through an 80 meg drive being checked, because one
> file that you probably don't care about caused the system to do so?  On
> a multi-partition system, if I see a warning about a error in /tmp, I
> won't fsck the drive.

On OS/2, before IBM fixed chkdsk, I used to sit through 45-minute checks 
at least one a day. I don't recall ever waiting that long for Linux, and 
it rarely needs to do more than a cursory check anyway.


> 
> And, as you say, backing up home, or updating a system leaving home
> untouched, and that sort of thing.  Not that I've noticed a way to get
> Linux to leave one partition alone during the installation routine, and
> use it afterwards.
> 
> There's one quite serious potential problem if you don't partition:
> Something that would otherwise have filled up a /tmp partition that's
> easy for you to work around to fix up, can fill up the entire drive
> space, and that's much harder to deal with.
> 

Umm.
I find the more partitions I have the more likely I am to run out of 
space somewhere. Regarding /tmp, I rather like the Debian approach: 
delete everything in it on reboot. (Actually, I'd like to leave it alone 
when booting to single-user mode as important diagnostic info can get 
lost, but that's a complaint for another forum).

I don't think I've ever found multiple partitions advantageous, except 
for multibooting. One case comes vividly to mind: /dev/sda died, and as 
it was in its final throes I backed it uo. However, of the several 
gigglebyte tarball, only the root partition was readable, and that of 
course was the least useful. /var, containing email and such, was a 
writeoff.

Of course, this is wandering a little from defraggers. I don't see a use 
for them:-)


-- 

Cheers
John

-- spambait
1aaaaaaa at computerdatasafe.com.au  Z1aaaaaaa at computerdatasafe.com.au
Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/

do not reply off-list




More information about the fedora-list mailing list