FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian User

 
 
LinkBack Thread Tools
 
Old 09-23-2011, 05:31 PM
Martin Steigerwald
 
Default regards the /

Am Donnerstag, 22. September 2011 schrieb lina:
> > Even low end SSD can do 2500 IOPS, 15x that of a 7.2k drive. And
> > most SSDs are small. So if you have an SSD in this runaway logging
> > scenario you could potentially fill the log filesystem in a matter
> > of minutes.
> >
> > Moral of the story: Keep /var/log on a separate filesystem for
> > laptops and desktops. Keep it on a separate physical device on
> > servers. With a RAID setup, a separate partition on the LUN/virtual
> > disk serves the same purpose.
> >
> > Unrelated to this particular problem, but valuable knowledge
> >nonetheless,
> >
> > is to have a boot partition separate from the / partition as well.
>
> What's the recommended reserved size for the /var/log partition. I can
> jotted down and take reference in future.

Logs usually compress well. Remember to setup logrotate for any non
standard logs that you let services generate, e.g. for virtual hosts in
Apache with own logfiles.

I fare quite well with:

mondschein:~> LANG=C df -hT | grep -v tmpfs
Filesystem Type Size Used Avail Use% Mounted on
/dev/mapper/mondschein-debian
ext4 2.0G 1.1G 809M 58% /
/dev/sda1 ext3 230M 31M 188M 15% /boot
/dev/mapper/mondschein-var
ext4 1008M 243M 714M 26% /var
/dev/mapper/mondschein-varlog
ext4 485M 118M 343M 26% /var/log
/dev/mapper/mondschein-home
ext4 1008M 330M 628M 35% /home
/dev/mapper/mondschein-srv
ext4 2.0G 996M 919M 53% /srv
mondschein:~>

If its on LVM you can adjust later.

This is a small private mail and web server with Apache 2, Postfix, Dovecot
and policyd-weight.

You only need /srv when you put something in there. I have websites in
there, cause I do think /srv/www is more proper location for it than
/var/www that Debian uses.

And yes, I do recommend LVM - also for desktops and laptops since it does
support passing through barriers / cache flushes.

--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201109231931.10879.Martin@lichtvoll.de">http://lists.debian.org/201109231931.10879.Martin@lichtvoll.de
 
Old 09-23-2011, 05:39 PM
Martin Steigerwald
 
Default regards the /

Am Freitag, 23. September 2011 schrieb shawn wilson:
> Either way, its been a while since I've seen a unix box fall over
> because of a full disc. So, if something fills up, go in, take your
> time and figure it out. You might not be able to run some GUI programs
> (and some services might act weird - who cares this is a home system)
> but you'll have all the time in the world to fix the issue.
>
> Partitions are great if you need then. Today, I think they are one of
> those things that, unless you can point to the use case you have, you
> don't need them.

At work and for customers we have a lot of servers and VMs. Often with
just one partition for / and for swap. I do not remember having had a
problem with any of these.

But I do remember problems with a customer machine that hat everything
including /usr on a different partition, *without* LVM and then due to ill-
estimation one partition was to small for a task to accomplish.

So the seperating of partitions introduced a problem where everything on /
would just have worked.

So I strongly recommend to use LVM when seperating out things to
partitions. Cause Linux machine do not always stick to initial estimations
even if they are good ones according to the workload.

And then when you are interested in high uptimes and service availibility:
Use Nagios or something else to monitor free disk spaces centrally. Cause
what use is a still working Linux box when the service that runs on it ran
out of free space? Especially when its a mail service not being able to
receive new mails anymore.

So I think there is no golden rule, but more a set of best practices to
follow. And then the separate partitioning isn´t that important anymore.
It might still be wise for servers which are at risk to be targers of
denial of service attacks or users storing large files in /tmp and whatnot.
For users quota might come in handy then.

Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201109231939.42960.Martin@lichtvoll.de">http://lists.debian.org/201109231939.42960.Martin@lichtvoll.de
 
Old 09-23-2011, 05:45 PM
Martin Steigerwald
 
Default regards the /

Am Freitag, 23. September 2011 schrieb Stan Hoeppner:
> > Partitions are great if you need then. Today, I think they are one of
> > those things that, unless you can point to the use case you have,
> > you don't need them.
>
> My hiking analogy sums it up pretty well:
> "Better to have it and not need it, than to desperately need it and
> not have it."
>
> By the time one may realize he needs it, it is too late. This is the
> difference between "proactive" administration and "reactive"
> administration that you should have read about somewhere in your IT
> career. Planning a system with a separate /var (and /boot) is being
> proactive. Using one big partition/volume/filesystem for everything
> is setting one's self up for a reactive situation, just as Lisi went
> through.
>
> In short, isolate certain functions and their write filesystems, so
> when one breaks it doesn't negatively affect the others, or the
> entire system, as a result.

Whether you separate partitions or not, you´d usually still have to react
when one partition becomes filled up. No?

For some setups, especially unattended setups with risk to be targets of
denial of service attacks or user putting large files everywhere,
separating partitions make sense. For others it might be easier to just go
with one bigger / and let the system distribute free space dynamically
between /, /var/log, /tmp and what not.

The more separate partitions you have the more flexibility in dynamic
freespace distribution you loose.

And since you´d usually have to react on a filled up filesystem anyway as
long as you have some server monitoring for free space on filesystem (and
other values) in place, IMHO the separating of partitions is not the one
and only golden rule anymore. It may well make sense on certain setups,
but on others it may raise administration overhead, especially when
partitions are used instead of logical volumes and the initial estimations
become obsoleted by real life scenarios.

--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201109231945.40742.Martin@lichtvoll.de">http://lists.debian.org/201109231945.40742.Martin@lichtvoll.de
 
Old 09-23-2011, 05:49 PM
Martin Steigerwald
 
Default regards the /

Am Freitag, 23. September 2011 schrieb Lisi:
> On Friday 23 September 2011 17:59:13 Martin Steigerwald wrote:
> > For KDE there is:
> You mean, I take it KDE 4? KDE 3 appears not to do so - tho' it may
> just be that the system didn't get a chance.

Yes, freespacenotifier is for KDE. It has been developed my one member of
the Debian Qt/KDE team AFAIR.

There is kdf any KDE 3 and 4, but I do not now whether it can run in the
systray and warn interactively.

Well it can warn, but it seems you have to keep the window around.

Well and then there is stuff you can put into the systray or other toolbars
you place on the desktop that can at least visually warn about low disk
space by showing it all the time. I think there is some applet where you
can drag KSysguard sensors into a tray.

--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201109231949.59666.Martin@lichtvoll.de">http://lists.debian.org/201109231949.59666.Martin@lichtvoll.de
 
Old 09-23-2011, 05:58 PM
Martin Steigerwald
 
Default regards the /

Hi Lina,

Am Donnerstag, 22. September 2011 schrieb lina:
> > > Thanks very much for explanation.
> > >
> > > Tell you one secret, I didn't know LANG means language environment.
> > > When I test each directory.
> > > I avoid using the up arrow to get history. I tried to type each
> > > time to enhance memory of it. How silly I was/am.
> >
> > He... that's a good gimmick I should also use to improve my memory
> > (it takes me some time to remember the commands I barely use) but
> > I'm so lazy than even to run history commands I use "!+history
> > number" instead of retyping it again :-P
>
> Ha ... it's not easy to remember the history number.

Then press Ctrl-R to search backwards in history. That is one of my
favorite functions in bash, zsh and other Unix shells.

Say you worked in a directory named "somecoolstuff" some days ago:

- press Ctrl-R
- type "someco"
- usually its there already
- to further go backward use Ctrl-R
- if you want to reuse a line press cursor right or left to edit it or
just return to send it to the shell again

Unfortunately search forwarding once you searched backwards once to much
is a bit of an issue. Ctrl-S stops output of the shell which seems
basically frozen then. But not on all Debian versions. Can be continued
with Ctrl-Q. Usually searching forward and stopping the output use
lowercase versus uppercase s, not sure what for which, but exactly this
does not appear to work on konsole from KDE 4.6.5 or gnome-terminal,
lxterminal or xterm from Squeeze.

Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201109231958.07882.Martin@lichtvoll.de">http://lists.debian.org/201109231958.07882.Martin@lichtvoll.de
 
Old 09-23-2011, 06:01 PM
Martin Steigerwald
 
Default regards the /

Am Donnerstag, 22. September 2011 schrieb Camaleón:
> On Thu, 22 Sep 2011 11:50:54 +0800, lina wrote:
> > On Thu, Sep 22, 2011 at 1:34 AM, Camaleón <noelamac@gmail.com> wrote:
> >> Hmm... you "/lib" seems a bit bloated (mine is 94 MiB), I would look
> >> inside it:
> >>
> >> du -h /lib | grep "[0-9]M" | sort -n -r | less
> >>
> >> 330M /lib
> >
> > 311M /lib/modules
> >
> > got several kernels here.
> >
> > linux-headers-2.6-amd64 install
> > linux-headers-2.6.32-5-common install
> > linux-headers-2.6.38-2-amd64 install
> > linux-headers-2.6.38-2-common install
[...]
> > after purging, only took
> >
> > # du -sh /lib
> > 128M /lib
> >
> > Thanks for your help. It's done.
>
> Hum... I hope those files are not going to be used anymore by your
> system. By the way, they're not kernels, but "kernel headers", mainly
> needed for compiling things but dunno what were they doing under "/lib/
> modules" :-?

Maybe kernels are still installed as well.

Lina, what does

dpkg -l | grep linux-

or

ls -lh /boot/{vm,init}*

show?

Removing packages for older, not used kernels will save some diskspace as
well.

--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201109232001.05403.Martin@lichtvoll.de">http://lists.debian.org/201109232001.05403.Martin@lichtvoll.de
 
Old 09-23-2011, 06:02 PM
Martin Steigerwald
 
Default regards the /

Am Donnerstag, 22. September 2011 schrieb Camaleón:
> > Here is the
> >
> >
> >
> > :/lib/modules/3.0.0-mbp82-lina$ ls
>
> (...)
>
> But that's not the same as the other folders.
>
> This one contains the modules for that kernel (3.0.0-mbp82-lina) but
> the folders you "cleaned" were pointing to kernel headers which now
> are not available anymore. I don't tend to compile programs or kernels
> unless I have a special need for doing it, so I can't tell what are
> the drawbacks the deletion of that folders may have.

Yes, this definately looks like a self-compiled kernel. To consider whether
its safe to remove those, I´d look at

uname -a

or

cat /proc/version

and

ls -lh /boot/{vm,init}*

--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201109232002.45533.Martin@lichtvoll.de">http://lists.debian.org/201109232002.45533.Martin@lichtvoll.de
 
Old 09-23-2011, 06:06 PM
Martin Steigerwald
 
Default regards the /

Am Freitag, 23. September 2011 schrieb Lisi:
> On Friday 23 September 2011 17:54:04 Martin Steigerwald wrote:
> > (now isn´t --sort=h cool? Just found out about it a moment ago as I
> > searched a solution to sort the G and the M´s as well.)
>
> sort -h does the same thing - and I only just found that out!! (So
> long as you are running Squeeze or later, that is.) Oh - and --sort=h
> is also only Squeeze -->, again, I just tried.
>
> Now, how have I lived my life without something so patently invaluable?

I find it amazing that I find out new stuff like this after years of in-depth
Linux experience. There is always something new to learn.

That and the accessibility of all of the Linux/GNU/BSD internals combined
with a stability, flexibility, and upgrade-friendlyness as well as the vast
amount of available packages make me happy having chosen Debian as my
operating system for anything serious and fun stuff as well.

--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201109232006.39156.Martin@lichtvoll.de">http://lists.debian.org/201109232006.39156.Martin@lichtvoll.de
 
Old 09-24-2011, 05:30 AM
lina
 
Default regards the /

On Sat, Sep 24, 2011 at 2:01 AM, Martin Steigerwald <Martin@lichtvoll.de> wrote:

Am Donnerstag, 22. September 2011 schrieb Camaleón:

> On Thu, 22 Sep 2011 11:50:54 +0800, lina wrote:

> > On Thu, Sep 22, 2011 at 1:34 AM, Camaleón <noelamac@gmail.com> wrote:

> >> Hmm... you "/lib" seems a bit bloated (mine is 94 MiB), I would look

> >> inside it:

> >>

> >> du -h /lib | grep "[0-9]M" | sort -n -r | less

> >>

> >> 330M * */lib

> >

> > 311M * */lib/modules

> >

> > got several kernels here.

> >

> > linux-headers-2.6-amd64 * * * * * * * *install

> > linux-headers-2.6.32-5-common * * * * * *install

> > linux-headers-2.6.38-2-amd64 * * * * * *install

> > linux-headers-2.6.38-2-common * * * * * *install

[...]

> > after purging, only took

> >

> > # du -sh /lib

> > 128M * */lib

> >

> > Thanks for your help. It's done.

>

> Hum... I hope those files are not going to be used anymore by your

> system. By the way, they're not kernels, but "kernel headers", mainly

> needed for compiling things but dunno what were they doing under "/lib/

> modules" :-?



Maybe kernels are still installed as well.



Lina, what does



dpkg -l | grep linux-

$ dpkg -l | grep linux-
ii* doc-linux-text*********************** 2008.08-1************************ Linux HOWTOs and FAQs in ASCII format
ii* linux-base*************************** 3.3****************************** Linux image base package

ii* linux-headers-3.0.0-mbp82-lina******* 1900***************************** Header files related to Linux kernel, specifically,
ii* linux-image-3.0.0-mbp82-lina********* 1900***************************** Linux kernel binary image for version 3.0.0-mbp82-lina

ii* linux-libc-dev*********************** 3.0.0-3************************** Linux support headers for userspace development
ii* linux-sound-base********************* 1.0.23+dfsg-4******************** base package for ALSA and OSS sound systems

ii* linux-source-2.6.39****************** 2.6.39-3************************* Linux kernel source for version 2.6.39 with Debian patches
ii* linux-source-3.0.0******************* 3.0.0-3************************** Linux kernel source for version 3.0.0 with Debian patches



Can I remove
ii* linux-source-2.6.39******************
2.6.39-3************************* Linux kernel source for version 2.6.39
with Debian patches
*


or



ls -lh /boot/{vm,init}**


show?
*$ ls -lh /boot/{vm,init}*
-rw-r--r-- 1 root root 9.9M Sep* 8 10:25 /boot/initrd.img-3.0.0-mbp82-lina
-rw-r--r-- 1 root root 3.1M Jul 26 22:12 /boot/vmlinuz-3.0.0-mbp82-lina

Thanks.




Removing packages for older, not used kernels will save some diskspace as

well.



--

Martin 'Helios' Steigerwald - http://www.Lichtvoll.de

GPG: 03B0 0D6C 0040 0710 4AFA *B82F 991B EAAC A599 84C7





--

To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org

with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Archive: http://lists.debian.org/201109232001.05403.Martin@lichtvoll.de





--
Best Regards,

lina
 
Old 09-24-2011, 05:34 AM
lina
 
Default regards the /

On Sat, Sep 24, 2011 at 2:02 AM, Martin Steigerwald <Martin@lichtvoll.de> wrote:

Am Donnerstag, 22. September 2011 schrieb Camaleón:

> > Here is the

> >

> >

> >

> > :/lib/modules/3.0.0-mbp82-lina$ ls

>

> (...)

>

> But that's not the same as the other folders.

>

> This one contains the modules for that kernel (3.0.0-mbp82-lina) but

> the *folders you "cleaned" were pointing to kernel headers which now

> are not available anymore. I don't tend to compile programs or kernels

> unless I have a special need for doing it, so I can't tell what are

> the drawbacks the deletion of that folders may have.



Yes, this definately looks like a self-compiled kernel. To consider whether

its safe to remove those, I´d look at



uname -a
*
$ uname -a
Linux debian 3.0.0-mbp82-lina #1 SMP Tue Jul 26 21:52:57 SGT 2011 x86_64 GNU/Linux





or



cat /proc/version


cat /proc/version
Linux version 3.0.0-mbp82-lina (3.0.0) (root@debian) (gcc version 4.6.1 (Debian 4.6.1-4) ) #1 SMP Tue Jul 26 21:52:57 SGT 2011

*

and



ls -lh /boot/{vm,init}*



It's the only kernel I have had on the laptop.

seems nothing left to remove.

Thanks with best regards,
lina
 

Thread Tools




All times are GMT. The time now is 09:37 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org