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@xxxxxxxxxxxxxxxxxxxxxxx Z1aaaaaaa@xxxxxxxxxxxxxxxxxxxxxxx
Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/
do not reply off-list
