Re: Advantage of partitioning?
From: Peter T. Breuer (ptb_at_oboe.it.uc3m.es)
Date: 07/26/03
- Next message: no body: "Re: Advantage of partitioning?"
- Previous message: Ken Prox: "Re: static vs dynamic compiled versions of programs redhat 9.0 segmentation fault"
- In reply to: Nico Kadel-Garcia: "Re: Advantage of partitioning?"
- Next in thread: Wayne Pollock: "Re: Advantage of partitioning?"
- Reply: Wayne Pollock: "Re: Advantage of partitioning?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sat, 26 Jul 2003 17:37:51 +0200
Nico Kadel-Garcia <nkadel@verizon.net> wrote:
> Peter T. Breuer wrote:
>> Nico Kadel-Garcia <nkadel@verizon.net> wrote:
>>>Apache gets put in all sorts of odd places, such as /home/httpd,
>>
>> You know, that's true. Let's settle on putting it in /usr. and putting
>> the docroot in ~www, and the rest is config for you to do.
> No, because you can't then use the distribution's package management
> without symlinking.
It'll go in /usr (or /opt). If it doesn't, register a bug.
>>>/var/www, and /opt depending on your distribution, along with software
>>
>> Wherever it goes, you get to sit and watch. None of the common places
> "Wherever the flying glass as you overflow a partition goes, you can
> sweep it up".
You don't overflow a partition by installing apache (0.6MB). And it
goes in /usr or /opt. If it goes in /var, then you have no space
problem at all, since /var by definition has plenty of space.
> No.
Just stop being silly - apache is 06MB with docs If you were complaining
about where the 35MB of mozilla gets put I might have a tiny bit more
sympathy. It should go in /usr, as I said, and if you don't have 35M
there, then put it in /opt or make /usr bigger.
>> is hazardous to life or health. Oh - are you saying that /opt would be
>> on root if you hadn't symlinked it elsewhere or had a separate
>> partition for it? I have a separate (very unfull) partition for such
> Bingo. Symlinking it elsewhere is an emergency practice, and too damn
There is nothing wrong with symlinking /opt to /usr/local/lib (for
example). That's my opinion of where extra large packages should go!
> many installation tools do relative path tricks (config files in
> /opt/dirnameme/etc looking up things in ../../etc/passwd and that sort
That all works right.
> of silliness) to rely on symlinking the root of a hard-coded
> installation directory.
Eh? Now you are thinking of something that looks itself up in its own
code. That would be a bug if it did so. The script should locate the
place by tracing symlinks.
>> major packages. Office stuff is about all I put there. Nowadays much
>> more is going in /usr where it used to go in /opt as the focus of
>> packaging shifts more to the distros. A subdir of /usr/lib is
>> a good alternative in general.
> Well, that's nice. So now, because we've made /usr and /opt and /var
> separate partitions for no overwhelming reason, we get to try to
> outguess the package authors as to how large they will be.
Why do you think this is difficult? Do you think the package authors
are geniuses? I don't guess - I just know. And if I'm wrong I change
the sizes to suit. But I'm not wrong. 1GB has been more than enough for
me in /usr forever, and 512MB has been more than enough for me in /opt
forever. And surprise surprise, you always have the wonderful option of
"NOT installing" something that won't fit. I do it all the time. I
don't install oracle for example. I don't install, errr, the SuSE book
in german (or english). Try it. It's real easy. And then you always
have that amazing other option too: "REMOVE something else first".
For some reason I have removed all of my previous versions of netscape
when installing the latest in /opt. I wonder why I did that ...
it was because they wouldn't fit what with the new version I wanted to
install. SO you know .. I removed them.
And I didn't cry and wail and say, oh gosh, that's the fault of my
making partitions that are too small to contain all the dross of the
universe, and my own fault for being too lazy to change their sizes.
No. For some reason I say how good it is that I made the partitions
small so that it forces me to clear out all that dross that I don't
need any more. I mean, I don't want Acrobat3 any more, nor
enlightenment, nor that failed matlab replacement that I never use, and
realplayer 5, that can go, as can that silly asWedit editor, and the
wp6 copy I still have around, and ... well, you get the picture. Now my
disk is nice and organised and has just what I want in it, and the
partitions are just nicely filled with what I want, and are the size I
want them to be. Good, isn't it?
> No. It's a complete waste of time unless you have compelling performance
> reasons to separate the partitions.
Everyone has. I really hate it when my root partition breaks. So I make
sure it is separate from everything else, nice and small, and not
touched by anything. That means putting /opt /usr /home /var /tmp
somewhere else.
>>>packages distributed as web services. mailman has also wondered from
>>>/var to /usr in different distributions, and plenty of commercial
>>
>> It doesn't matter - much. /var always has plenty of space - enough to
>> take a MB or two of confused looking files anyway.
> You've never run mailman, have you? It's mailing list software, and can
Yes I have. In fact I wrote a secure version of it. One that uses
ssl connections.
> easily take up Gigs at a slightly busy site that archives the email.
No it can't. It doesn't put the mail anywhere else but where the mail
spool is. I don't know what you mean. As it is, I have a 2GB mail spool
on my main swerver, and if any of its 100 or so users pushes over the
100MB mark in there, I warn them.
>> None of that stuff matters. Wherever it goes, the data will go in /var
>> and the rest is trivial (e.g. 0.5M for mysql). The /usr vs /usr/local
>> is up to you if you are compiling, and you should always decide for
>> /usr/local unless replacing a distro package with one of your own that
>> you expect the distro to later catch up with.
> Again, no. I just gave you a dozen examples of programs that put their
> data in all sorts of weird places, including databases and web servers.
No you didn't. They put their data exactly where I tell them too. And
the programs themselves are the order of 1MB or so and go where they
should.
>>>supplied distributions, building them locally, or what. *Logging* of
>>>software results also depends wildly on particular configuration, with
>>
>> logging always goes in /var/log. That's what it's for.
> Except, of course, when it doesn't. See Apache and mailman source code.
They log in /var/log. Register a bug if your compilation doesn't. Or
hit yourself up the side of the head with the cluestick until you fix
their config.
>>>along with ()/bin, ()/lib, and ()/etc. Dont't get me *started* on trying
>>>to build and install X windows from scratch in a spare locationtesting
>>
>> Why? I have done it. It needs at least 1GB of compile space! Maybe 3.
> Which isn't available if you've already got your nominial 1.5 Gig of
> /var filled with a mail spool, Apache, print services, and who knows
If I compile X, I temorarily mount myself some extra tmp space, over
nfs if necessary. I'm not goiing to keep 3GB of space around in /tmp
just in case I might want to compile X.
> what else.
I know exactly what else. If you don't, tough. I keep about 250MB of
log files per swerver, going on 400MB max. I adjust logrotate to keep it
that way.
>>>purposes. And the usage of /tmp, /var/tmp, and /usr/tmp is its own
>>>special little bit of fun.
>>
>> The usage is fine and correct. I link them together since my opinion is
>> that I have the right to kill tmp files whenever I want.
> Which many folks do. Then some cretin writes one of those relatively
> addressed "look in /tmp/../etc/hosts" sorts of programs and it goes to
> hell in a handbasket.
Relative addressing works fine. I don't know what you have in your head
about this, but you can't go wrong if you always use relative symlinks.
Your shell will remember how you got there and trace back
appropriately.
> Mind you, a lot of these practices are simply due to unfortunate
> programming practices by the authors. But others have historically been
> serious problems requiring repartitioning to address.
They would be bugs if they are as you describe, and they would earn the
author a bug reprt.
>>>You, umm, don't get out much, do you?
>>
>> Only on thursday lunchtimes.
> Heh. OK, fair enough, I shouldn't be so snide. But really, I've just run
> too many times into machines I've partitioned per people's requests in
> what seemed a sensible fashion, then altered a service or updated
> packages on it that moved a lot of material elsewhere. It's just simpler
> to not use additional partitions unless compelled to. These days, if you
> *really* need another partition, it's often easier to just use another
> disk as well and guarantee spare space.
I have never needed "spare space". Really - "delete random garbage that
nobody uses" makes as much space as I ever need, whenever I need it.
Peter
- Next message: no body: "Re: Advantage of partitioning?"
- Previous message: Ken Prox: "Re: static vs dynamic compiled versions of programs redhat 9.0 segmentation fault"
- In reply to: Nico Kadel-Garcia: "Re: Advantage of partitioning?"
- Next in thread: Wayne Pollock: "Re: Advantage of partitioning?"
- Reply: Wayne Pollock: "Re: Advantage of partitioning?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
