Mailing List Archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [tlug] join /tmp and /var



On Thu, Jun 26, 2003 at 04:30:59PM +0900, Joe Larabell wrote:
> > with critical i meant ONLY things that prevent you from loggin into your
> > machine and fixing the problem. everything else is NOT critical.
> That's what I meant. I *have* been unable to log into a system before
> because the shell decides it needs to write something into /tmp 

ugh, that is evil, and should NEVER happen.
if it does it is time for some bug reports!
but i do understand your reasoning now much better...
thanks for clearing that up.

> > and you don't need a gui to do that. (if you can't fix that problem
> > without a gui, chances are you can't fix the problem at all anyways)
> Yeah... But if it happens when I'm working in the GUI then I have the
> choice of bailing out and losing everything I was doing,

no.
just stop working, switch to a text console, log in remove some files,
go back to the gui, dave your data, and then find out what took up so
much space.

> Logs usually go to /var. If /var and /tmp are seperate, you don't run out
> of /tmp when a log writer fills up /var. 

but then you find out that on debian your shell writes the process id to
/var/run and not to /tmp, and the same problem starts all over again.

> I don't think the original
> question of whether the soft links from "/" would cause and performance
> degredation has been answered yet, though. I'd be interested in knowing
> that for other reasons, if anyone knows.

i think someone already said that the answer is no.
resolving the symlink is just one step that may take a microsecond once
for the whole read operation. the symlink only comes to play when open()
is called. once your file is open, there is no more difference.
reading datablocks will take several magnitudes longer than resolving
that one symlink.

greetings, martin.
-- 
Pike Conference 2003 - Sep 25-27  -  http://pike.ida.liu.se/conferences/2003/
-- 
interested in doing pike programming, sTeam/caudium/pike/roxen training,      
sTeam/caudium/roxen and/or unix system administration anywhere in the world.
--
pike programmer   working in europe                           open-steam.org
unix system-      bahai.or.at                       iaeste.(tuwien.ac|or).at
administrator     (stuts|black.linux-m68k).org        is.(schon.org|root.at)
Martin Bähr       http://www.iaeste.or.at/~mbaehr/


Home | Main Index | Thread Index

Home Page Mailing List Linux and Japan TLUG Members Links