|
[Original]
[Print]
[Top]
|
Hello,
My system is an HP X550 with dual PIII Xeons at 550MHz, FastEthernet
network card, 1GB RAM, Geforce 5200 and 18GB/9GB 10k SCSI drives on the
Adaptec 2940UW. I am fairly new to Gentoo 2005.0. I've installed the system
from scratch on my second SCSI hard disk drive (using a combination of
xfdisk and Grub) double-booting with Windows XP. I've already installed
grass, kde, xfree.org and some more using emerge. The system will mainly be
used as my linux desktop. Server performance is not an issue here, although
I might run LAMP now and then. BTW: Good job, I like Gentoo and coming from
Debian, the package/install system impresses me a lot.
Gentoo works fine. However, I have run out of space on / while emerging
openoffice.
Right now I have the following partition scheme:
/dev/sda1: Windows XP (18gigs)
/dev/sdb1: Windows XP storage and swap file (2.5GB)
/dev/sdb2: /boot (32MB), ext2
/dev/sdb3: swap (384MB)
/dev/sdb5: / (4.5gigs), ext3
/dev/sdb6: /home (1.3GB), ext3
It seems I am unable to get a second 18GB SCSI for a fair amount, so I'll
install a Promise IDE-addon card and revive a very slow 17GB IDE drive.
I'd like to free some more space on sdb1 for Windows XP yet maintaining the
already low enough compiling speed [1] on the 10k drives. Increasing
space for Gentoo would be nice, too :-) .
I guess, moving /tmp to /dev/hde1 (Promise 17GB) would mean a serious blow
to compiling times since the drive is a 5400rpm one? If not, where are
compile packages located?
Does anyone have suggestions for useful partition sizes? Should I separate
/usr? Does it make sense to move /home to /dev/hde? What else can I move
to keep things as fast as possible? What can I do to gain more space? Any
things to consider while moving partitions? I am familiar with qtparted,
but I guess, it's what makes a professional: knowing what can go wrong in
reality when playing with file systems, /etc/fstab, permissions and so
forth.
Any help is greatly appreciated. Thanks in advance.
Fußnoten:
=========
[1] emerging kde took nearly two full days
--
with kind regards
Christian Dürrhauer, Institute of Geography, FU Berlin
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
On Wednesday 31 August 2005 21:58, Christian Dürrhauer stood up and
spoke the following words to the masses...:
[snip]
Gentoo works fine. However, I have run out of space on / while
emerging openoffice.
Right now I have the following partition scheme:
/dev/sda1: Windows XP (18gigs)
/dev/sdb1: Windows XP storage and swap file (2.5GB)
/dev/sdb2: /boot (32MB), ext2
/dev/sdb3: swap (384MB)
/dev/sdb5: / (4.5gigs), ext3
/dev/sdb6: /home (1.3GB), ext3
It seems I am unable to get a second 18GB SCSI for a fair amount, so
I'll install a Promise IDE-addon card and revive a very slow 17GB IDE
drive.
I'd like to free some more space on sdb1 for Windows XP yet
maintaining the already low enough compiling speed [1] on the 10k
drives. Increasing space for Gentoo would be nice, too :-) .
I guess, moving /tmp to /dev/hde1 (Promise 17GB) would mean a serious
blow to compiling times since the drive is a 5400rpm one? If not,
where are compile packages located?
Gentoo's /Portage/ compiles the packages under */var/tmp/portage.* I
don't think compiling would be significantly slower with that directory
sitting on an IDE drive.
Mind you that you can safely delete the contents of */var/tmp/portage*
once you have finished compiling a given package.
It might be helpful in that respect to add "-pipe" to your CFLAGS and
CXXFLAGS. This will make /gcc/ use pipes rather than temporary files.
*/tmp* is also best split off - simply because you would want to keep
your root filesystem as static as possible - but it needn't be bigger
than 50-100 MB for a single-user workstation set-up.
Does anyone have suggestions for useful partition sizes?
Yup! :-)
Should I separate /usr?
Definitely! You should split off everything that one _can_ split off.
You want to keep your root partition itself as small as possible, i.e.
no more than 250-300 MB.
This does however not mean that you should try splitting off every
directory in the root directory, though. You can't even do that
without running into trouble.
The directories you can split off onto other partitions are:
- /boot (about 50-100 MB, depending on your kernel collection :-))
- /usr (about 9 GB for a fully-blown install)
- /var (about 5 GB for compiling things like OpenOffice or KDE)
- /tmp (about 50-100 MB, used for storing sockets et al)
- /opt (about 500 MB, add-on software that doesn't go under */usr*)
- /home (the rest of the space)
Those that you _*should*_ _*not*_ attempt to split off are:
- /initrd (if you have that, it's used by the initial RAM disk)
- /etc (contains your configuration files, needed at boot time)
- /bin (needed at boot time)
- /sbin (needed at boot time)
- /dev (device nodes; will be on /tmpfs/ if you use /udev/ or /devfs/)
- /proc (virtual filesystem, the contents are not on the disk itself)
- /sys (virtual filesystem, used by /udev/)
*/root* is a special case. It's the home directory for the root user,
and technically you can split it off. Yet, if you do so, make sure
that it's a mountpoint for a filesystem, not a symlink to something
like */home/root* - which some users like to set up.
You will need access to */root* to store the /bash/ history among other
things, even if you have bootstrapped the system up to single user
maintenance mode, in which case only the root filesystem ("/") will be
mounted.
I would personally also split off */usr/portage* and */usr/local,* and
on my system I have a */var/share* which I use as a network share and
which also sits on a separate partition.
When you're a bit more experienced, you can then also opt to have
several of those partitions mounted in read-only mode - i.e. */boot,*
*/usr* (and what sits below) and */opt.*
Below, you will see the current layout on my machine...
Filesystem Type Size Used Avail Use% Mounted on
/dev/sda2 xfs 514M 236M 278M 46% /
/dev/sda1 reiserfs 74M 54M 21M 73% /boot
/dev/sda3 xfs 7.6G 5.1G 2.6G 67% /usr
/dev/sda5 xfs 2.1G 26M 2.1G 2% /usr/local
/dev/sda7 xfs 1.5G 337M 1.2G 24% /opt
/dev/sda8 reiserfs 1.1G 35M 1.1G 4% /tmp
/dev/sda9 xfs 3.4G 875M 2.5G 27% /var
/dev/sda10 xfs 21G 14G 6.2G 70% /home
/dev/sdb3 xfs 8.7G 3.2G 5.6G 36% /var/share
*/boot,* */usr,* */usr/local* and */opt* are mounted read-only. Note
that I've chosen rather large sizes for */tmp* and *usr/local,* and a
rather small size for */var.*
This will be different when I'm installing Gentoo myself, though. I'm
currently still running Mandrake 9.2 with a vanilla 2.6.8.1 kernel.
Does it make sense to move /home to /dev/hde?
That depends. If you work with databases in your $HOME, then it would
not be a good idea.
You say that you have 1 GB of RAM in your system. In that case, you
could move the swap partition over to the slower disk as well. It's
not likely to ever get used anyway. ;-)
What else can I move to keep things as fast as possible? What can I do
to gain more space?
See the above paragraphs... :-)
Any things to consider while moving partitions?
Yes. Boot up the system in single user mode. Only the root partition
will be mounted (and maybe */boot*). Manually mount each partition
that needs modification.
Create temporary mountpoints and copy over what you need before you
start messing around with any partition tables. Edit your */etc/fstab*
after each filesystem copy if the target is to be permanent.
Make sure that */tmp* and */var/tmp* have the sticky bit set, e.g.
chmod +t /var/tmp
Just make sure you know what you're doing, and that you're familiar with
the commandline interface. Messing around with partitions is an easy
way to totally screw up your system... ;-)
Lastly, if you only plan on using your system as a workstation and you
don't have a UPS, then I would recommend the use of /reiserfs/ over
/XFS./ /ext3/ is also quite good, but by far not as fast as
/reiserfs./
I am familiar with qtparted, but I guess, it's what makes a
professional: knowing what can go wrong in reality when playing with
file systems, /etc/fstab, permissions and so forth.
Any help is greatly appreciated. Thanks in advance.
Fußnoten:
=========
[1] emerging kde took nearly two full days
Yes, KDE and OpenOffice are the two largest builds. ;-)
--
With kind regards,
*Aragorn*
(Registered Gnu/Linux user # 223157)
|
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
Christian =?ISO-8859-1?Q?D=FCrrhauer?= [cduerr@geog.fu-berlin.de] writes:
I guess, moving /tmp to /dev/hde1 (Promise 17GB) would mean a serious blow
to compiling times since the drive is a 5400rpm one?
I doubt that. On my 2GHz Athlon 64 with an 5400rpm IDE disk
compilation is CPU-bound, and that is certainly also the case on your
box, so the speed of the hard disk will make little difference. Just
make sure that you use DMA for accessing the IDE disk.
Does anyone have suggestions for useful partition sizes?
My mounted partitions currently look like this:
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/hdb14 9621848 3799600 5333472 42% /
udev 255568 632 254936 1% /dev
/dev/hdb7 20161172 12575684 6561348 66% /home
none 255568 0 255568 0% /dev/shm
/dev/hdb8 10080488 4196884 5371536 44% /usr/local
Should I separate
/usr?
If you don't have a reason to do it, don't. I separate /usr/local, so
I can use it with other Linux distros.
- anton
--
M. Anton Ertl Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
Aragorn wrote:
Definitely! You should split off everything that one _can_ split off.
Why? There should be good reasons for making the partition layout so
complex. Partitions are basically artificial size restrictions on
directory trees, which are dangerous to change at a later date (due to
the potentials for partition table corruption and filesystem
corruption).
A reasonable partition layout is:
/
swap (around half the RAM size)
/home
It is good to have /home on its own partition, so that a Linux
distribution can be installed without having to completely
repopulate /home (although a backup of /home should still be made,
before such a dangerous procedure).
For the security-minded, /boot could be put on its own partition so
that it is always mounted read-only unless a new kernel is being
installed. Whilst this counts as an additional layer of security, the
default layers of security are already sufficient.
Each additional partition adds to the potential confusion - one would
not wish the experience of reformatting the wrong partition by mistake.
Regarding the filesystem to use, there are lots of contradictory
anecdotes available. I personally recommend ext3. Whichever is
chosen, it is essential that the data recovery tools for that
filesystem be available for when a hard drive experiences nasty data
corruption.
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
Aragorn wrote:
Well, my advice is based upon the fact that splitting off the
directory tree over dedicated partitions protects the integrity of the
filesystems in the event of a user-initiated screw-up. This includes
partition table corruption - mostly due to Windows applications such
as Partition Magic, if not due to Windows itself - _and_ filesystem
corruption.
I don't understand that - how does having more partitions, guard
against Windows messing with Linux partitions/filesystems?
A screw-up could also include the root user getting his partitions
muddled because there are so many of them, and wiping the wrong
partition by mistake.
It also allows for the read-only mounting of partitions in order to
reduce the chances of damage due to attacks from the outside world, or
by malware - or exploits in legit software. A writable */usr* tree is
- because of its complexity - a great place to hide a rootkit or some
other cracking software.
A non-writable /usr is, surely, a huge PITA. It means that "emerge
--sync" will fail, as will emerging packages. A cracker with root
privileges could easily temporarily remount the partition as read/write
to plant his rootkit.
Additionally, splitting off as many directories as possible guarantees
that you won't experience a kernel panic due to the root filesystem
getting full over too many logs in */var/log,* too many /mp3's/ in
your $HOME, or too many leftovers from compiling in *var/tmp/portage.*
Would it really cause a kernel panic? Sounds like a horrendous bug in
the kernel, if true.
This is called "disk space management", a duty of the root user. Use a
logfile rotator for /var/log management, if desired. Use "quota"
for /home management, if desired (although I do recommend that /home be
on its own partition anyway). Run "df -h" occasionally. I'm not sure
whether "quota", "ulimit" or something else can prevent wayward
users/processes from filling /tmp. /var/tmp/portage on the other hand,
is in the sole control of the root user, who is assumed to be
monitoring dangerously low disk space as part of his duties.
http://packages.gentoo.org/packages/?categ...s-fs;name=quota
(Other duties of the root user, as an aside, include keeping the PC
safe from crackers trying to turn it into a spam zombie.)
Lastly, although fragmentation is a moot subject in regards to
multi-threading operating systems like Gnu/Linux - since the Linux
kernel bundles and reorganizes read/write requests to minimize head
movement - keeping static and variable directories separate reduces
the chances to fragmentation.
Well, choose - is it a moot subject, or a good-enough reason to go on a
partition spree? :)
I'd say that a swap partition of anything between 256 and 512 MB is
sufficient, and maybe - just maybe - up to 1 GB on a corporate server.
Whatever. It may be an issue on a 10gb hard drive, but on a 200gb
drive of today, the question of whether no swap, or 512mb swap, or 1gb
or 2gb is insignificant. The only real significance comes when the PC
runs out of virtual memory when it's doing something really
time-consuming, memory-intensive, important and urgent :) That's when
you kick yourself and wish that the "artificial limitations" had either
been removed or increased originally.
|
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
On Thursday 01 September 2005 01:43, Paul Bredbury stood up and spoke
the following words to the masses...:
Aragorn wrote:
Definitely! You should split off everything that one _can_ split
off.
Why? There should be good reasons for making the partition layout so
complex. Partitions are basically artificial size restrictions on
directory trees, which are dangerous to change at a later date (due to
the potentials for partition table corruption and filesystem
corruption).
[snip]
Well, my advice is based upon the fact that splitting off the directory
tree over dedicated partitions protects the integrity of the
filesystems in the event of a user-initiated screw-up. This includes
partition table corruption - mostly due to Windows applications such as
Partition Magic, if not due to Windows itself - _and_ filesystem
corruption.
It also allows for the read-only mounting of partitions in order to
reduce the chances of damage due to attacks from the outside world, or
by malware - or exploits in legit software. A writable */usr* tree is
- because of its complexity - a great place to hide a rootkit or some
other cracking software.
Additionally, splitting off as many directories as possible guarantees
that you won't experience a kernel panic due to the root filesystem
getting full over too many logs in */var/log,* too many /mp3's/ in your
$HOME, or too many leftovers from compiling in *var/tmp/portage.*
Lastly, although fragmentation is a moot subject in regards to
multi-threading operating systems like Gnu/Linux - since the Linux
kernel bundles and reorganizes read/write requests to minimize head
movement - keeping static and variable directories separate reduces the
chances to fragmentation.
I consider all of the above to be good reasons. But your mileage may
vary, of course... ;-)
P.S.: In regards to swap, the advice for making swap twice the size of
the physical memory is obsolete now that the average amount of RAM in
today's computers is 512 MB. My system for instance has 4 GB RAM. I
don't think I'd need to waste 8 GB on swap... ;-)
I'd say that a swap partition of anything between 256 and 512 MB is
sufficient, and maybe - just maybe - up to 1 GB on a corporate server.
--
With kind regards,
*Aragorn*
(Registered Gnu/Linux user # 223157)
|
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
Aragorn [stryder@telenet.invalid] wrote:
It also allows for the read-only mounting of partitions in order to
reduce the chances of damage due to attacks from the outside world, or
by malware - or exploits in legit software. A writable */usr* tree is
- because of its complexity - a great place to hide a rootkit or some
other cracking software.
One of the things that really irritates me is that so many of the Gentoo
package maintainers are unable to see beyond the narrow world of their
own systems. A common flaw is to require /home or user directories to
be writable by root. This will, of course, break on almost all systems
which use NFS mounted home directories (a quite common thing).
And no, I don't even want to start identifying all the packages that has
this problem, and report it to all the people involved (who obviously
cut/paste from each other without testing). It's a way too big job,
especially the way that emerge scrolls all the error messages off screen
and is so verbose that you can't even find the errors in the scroll
buffers and with -q won't even report the errors (but still lots of
irrelevant data).
Additionally, splitting off as many directories as possible guarantees
that you won't experience a kernel panic due to the root filesystem
getting full over too many logs in */var/log,* too many /mp3's/ in
your $HOME, or too many leftovers from compiling in *var/tmp/portage.*
Lastly, although fragmentation is a moot subject in regards to
multi-threading operating systems like Gnu/Linux - since the Linux
kernel bundles and reorganizes read/write requests to minimize head
movement
Bzzt. You're assuming that *logical* blocks returned by the file system
are the same as the blocks that the file system itself use. Not so.
Also, the fragmentation problem /is/ a severe problem also under Linux,
especially for files that are concatenated to, like log files. You're
almost guaranteed to find that large logs have hundreds if not more
parts, unless you place each busy log on a separate partition or on a
partition with really huge block sizes. Bundling and reorganizing read
requests won't do much in cases like this.
Some file systems come with a defragmenter, like xfs_fsr. This despite
xfs being one of the absolutely best file systems in terms of avoiding
fragmentation in the first place, due to its invisible and dynamic
sub-partitioning based on write size.
If performance is important (and if it isn't, why use Gentoo?), I
strongly recommend putting /var on its own drive(s), because this is
where most write requests will go, which both increases the amount of
fragmentation as well as causing caching to be less efficient if mixed
with frequently read data.
For a mail server, I'd also recommend that /var/mail (or /var/spool/mail
if you use the defaults instead of Unix compatibility) be on its own
partition. (With permissions 3775/drwxrwsr-x, by the way. Gentoo's
default mail spool permissions are unsafe.)
Similar for other services that frequently use the disk under a specific
directories (like squid, large named/dhcp/radius servers).
And if not using NFS, home directories.
- keeping static and variable directories separate reduces
the chances to fragmentation.
Indeed. But keeping two or more frequently appended to logs on the same
partition is the main culprit for fragmentation. There's not much you
can do about that though, as putting each log file on a separate
partition is seldom a viable option. Making /var/log (or at least /var)
a separate xfs partition and running "xfs_fsr /var" every night helps.
P.S.: In regards to swap, the advice for making swap twice the size of
the physical memory is obsolete now that the average amount of RAM in
today's computers is 512 MB. My system for instance has 4 GB RAM. I
don't think I'd need to waste 8 GB on swap... ;-)
I'd say that a swap partition of anything between 256 and 512 MB is
sufficient, and maybe - just maybe - up to 1 GB on a corporate server.
It depends on how you use the server. If you run a bunch of programs
that you seldom use, but which are nevertheless loaded, a larger swap
can be beneficial. This allows the kernel to do things like swapping
out the firefox instance you have on desktop 4 but haven't used for
days, and free up that memory for disk cache use instead.
Even with plenty of memory, you *should* see some swapping. Here's one
of my systems:
# free
total used free shared buffers
cached
Mem: 1554692 1457384 97308 0 0
1105448
-/+ buffers/cache: 351936 1202756
Swap: 1004052 16440 987612
16 MB has been swapped out even though there's over a Gig free. That's
expected behaviour. (Note that if you use reiserfs, you'll probably see
a high amount of memory being used for "buffers". Consider it similar
to "cached", except that the kernel can't free it up until the file
system relinquishes it.)
Also, if you need suspend-to-disk (hibernation) support, you need a swap
partition large enough to hold all the memory that's in use, plus
whatever swap is normally used.
If you're a developer, and have full memory core dumps enabled, you also
want to keep the swap size larger than the memory size, or you can't
dump the entire memory.
But for most people, yes, you don't need all that much swap. 1 GB is
probably more than enough for most people these days.
Regards,
--
*Art
|
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
Arthur Hagen wrote:
If performance is important (and if it isn't, why use Gentoo?), I
strongly recommend putting /var on its own drive(s), because this is
where most write requests will go, which both increases the amount of
fragmentation as well as causing caching to be less efficient if mixed
with frequently read data.
I chose Gentoo, not for performance, but because of the easy ability to
mix & match my own particular set of stable/unstable packages, and the
features within those packages. And for its cutting/bleeding edgeness.
It could probably be argued (although I wouldn't bother) that time
spent compiling packages (as opposed to installing someone else's
binary) means an overall *drop* in "performance".
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
On Thursday 01 September 2005 03:33, Paul Bredbury stood up and spoke
the following words to the masses...:
Aragorn wrote:
Well, my advice is based upon the fact that splitting off the
directory tree over dedicated partitions protects the integrity of
the
filesystems in the event of a user-initiated screw-up. This includes
partition table corruption - mostly due to Windows applications such
as Partition Magic, if not due to Windows itself - _and_ filesystem
corruption.
I don't understand that - how does having more partitions, guard
against Windows messing with Linux partitions/filesystems?
Well, I am also active on the Mandrake/Mandriva groups. About 75% of
the posters there are newbies from the Windows world, and they will
almost always install Gnu/Linux in dual-boot with Windows.
Windows itself often appears to be doing strange things to partition
tables, especially when software like Partition Magic is being used. I
was thinking that the more partitions you have, the better your chances
that not all partition table entries had gotten screwed up.
Another thing I forgot to mention is that by using different partitions,
you can not only use different types of filesystems - should you so
desire - but you can also specify extra safe mount options in
*/etc/fstab* for each filesystem, e.g. /noexec,/ /nosuid/ or /nodev/ et
al.
A screw-up could also include the root user getting his partitions
muddled because there are so many of them, and wiping the wrong
partition by mistake.
That is possible, but one might expect a user who has the root password
to display a little more responsibility. ;-)
It also allows for the read-only mounting of partitions in order to
reduce the chances of damage due to attacks from the outside world,
or
by malware - or exploits in legit software. A writable */usr* tree
is - because of its complexity - a great place to hide a rootkit or
some other cracking software.
A non-writable /usr is, surely, a huge PITA. It means that "emerge
--sync" will fail, as will emerging packages. A cracker with root
privileges could easily temporarily remount the partition as
read/write to plant his rootkit.
So could the owner of the machine do if he wishes to upgrade software.
Yet the installing or upgrading of software does not fall under the
normal daily operations of a UNIX system. To say otherwise would be
just as bad as telling the newbie that it's allright to log in as root
for doing your normal daily work.
A cracker could indeed temporarily remount any read-only filesystems as
read-write, but the point is that crackers will generally not expect
any hard disk filesystems to be mounted read-only in runtime, and it
buys you some more time. Crackers are human too, and they too need
time to think or assess a situation.
In addition, you are assuming per default that the cracker has obtained
root privileges already. However, chances are that the cracker has
gotten in through a security breach in a program running in an
unprivileged user account.
Reality however shows - and I know this by experience - that most UNIX
administrators - and this definitely goes for Windows server admins as
well - are quite lax and don't even check their logs. Our organization
has been under attack for months in a row with daily attempts to log in
as root via /ssh,/ using a password generator and brute-force attacks.
One of the first things I did was to deny root logins over /ssh./ One
can just as easily log in as a regular user and they use /su/ to obtain
root privileges. A regular user account login is harder to guess, and
then even if they get in, they'd still have to try and gain root
privileges.
Additionally, splitting off as many directories as possible
guarantees that you won't experience a kernel panic due to the root
filesystem getting full over too many logs in */var/log,* too many
/mp3's/ in your $HOME, or too many leftovers from compiling in
*var/tmp/portage.*
Would it really cause a kernel panic? Sounds like a horrendous bug in
the kernel, if true.
No, it's not a bug in the kernel. The kernel writes to */var/log/dmesg*
during the boot process. If */var* or */tmp* sit on the root
filesystem, then it's only a matter of time - in theory, of course; one
could choose a root filesystem of 10 GB, so to speak - before the root
filesystem is full, and when that happens, the kernel panics.
I've seen it happen - not on my systems, though - usually during the
boot process, but also because of a runaway process writing to
*/var/log,* */var/mail* or whatever... ;-)
This is called "disk space management", a duty of the root user. Use
a logfile rotator for /var/log management, if desired.
Yes, but that is not the point. A system should be able to stay up
unmonitored as well. That's the whole point of automation, isn't it?
:-)
If Gnu/Linux (or any other UNIX clone) were to _need_ human intervention
to retain its runtime integrity, then it'd be not much better than that
particular platform from Redmond... :-)
Use "quota" for /home management, if desired (although I do recommend
that /home be on its own partition anyway).
Yes, having */home* separate does indeed offer you the possibility of
reformatting the system partitions without losing your data.
Run "df -h" occasionally.
Granted, but not picking different filesystems and having much more in
the root filesystem than necessary will require you to do that more,
and you want your system to be as autonomous as possible without
requiring human intervention.
The job of a system's administrator should be to monitor the systems,
not to keep them running. ;-)
I'm not sure whether "quota", "ulimit" or something else can prevent
wayward users/processes from filling /tmp.
Hmm... It's a bit tricky... One can limit the number of processes they
start, the amount of diskspace they use, the amount of RAM they use,
but it _is_ possible that they could somehow find a way to fill up
*/tmp.*
After all, it's got the sticky bit set...
/var/tmp/portage on the other hand, is in the sole control of the root
user, who is assumed to be monitoring dangerously low disk space as
part of his duties.
True, but having */var/tmp* controlled by /tmpwatch/ would not be a bad
idea. ;-)
http://packages.gentoo.org/packages/?category=sys-fs;name=quota
(Other duties of the root user, as an aside, include keeping the PC
safe from crackers trying to turn it into a spam zombie.)
Of course! Every computer connected to the internet requires that its
owner/administrator bears his/her responsibilities.
I hear newbies say all the time that they do their normal daily work
while logged in as root, because they don't care about security. Yet
if their box gets cracked or exploited in any way, then that has its
repercussions on everyone else connected to the internet.
Such a box could easily be used for a DDoS attack, for instance.
Lastly, although fragmentation is a moot subject in regards to
multi-threading operating systems like Gnu/Linux - since the Linux
kernel bundles and reorganizes read/write requests to minimize head
movement - keeping static and variable directories separate reduces
the chances to fragmentation.
Well, choose - is it a moot subject, or a good-enough reason to go on
a partition spree? :)
I wouldn't call it a spree, as it's well-defined. I don't create extra
partitions for everything. I just have a predefined partitioning
layout in my mind that I use all the time and that I find to be the
most stable - granted: on the condition that your hard disk is big
enough and that you're serious about setting up a stable and fairly
moderately secure system.
One of the reasons why it was a moot point is that you actually have no
direct control over the fragmentation. Most modern hard disks are
quite capable of remapping bad sectors and may already come with
remapped sectors while they're still new in the box. If your data is
in remapped sectors, then it's not contiguous either.
I'd say that a swap partition of anything between 256 and 512 MB is
sufficient, and maybe - just maybe - up to 1 GB on a corporate
server.
Whatever. It may be an issue on a 10gb hard drive, but on a 200gb
drive of today, the question of whether no swap, or 512mb swap, or 1gb
or 2gb is insignificant.
The prices for consumer-type hard disks of large capacity are quite low
these days, but SCSI disks are quite expensive, and even incredibly
expensive in the higher capacity ranges. ;-)
The only real significance comes when the PC runs out of virtual
memory when it's doing something really time-consuming,
memory-intensive, important and urgent :) That's when you kick
yourself and wish that the "artificial limitations" had either been
removed or increased originally.
Sadly enough, given the nature of the Western economy model, I think
it'll still be a few centuries before end-users can install a mainframe
in their homes.
Of course, by that time, Microsoft Windows - which still is what most
people use - will simply require computers of mainframe proportions to
give them the same (lack of) functionality that Windows has today.
Redmond has always been very good at artificially bloating their
software enough to require more powerful hardware, which in term keeps
the hardware manufacturers on their side when it comes to providing the
buyer of that hardware with drivers... [evil grin]
As an example: technically, there isn't all that much difference between
today's Windows XP and Windows NT 4.0. The box in which the latter
came stated that it required 16 MB to run in. I have a second-hand
laptop with a P-III Celeron and 128 MB of RAM. It came with Windows XP
Home installed, and out of curiosity I checked it out. It was slow as
Hell... ;-)
[confession]
Okay, the laptop is also slow when I use KDE, but then again KDE has
tons of eye-candy. It would be a lot faster if I just used Fluxbox or
IceWM or something though. ;-)
[/confession]
--
With kind regards,
*Aragorn*
(Registered Gnu/Linux user # 223157)
|
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
Aragorn wrote:
The job of a system's administrator should be to monitor the systems,
not to keep them running. ;-)
Having e.g. /tmp on its own partition, adds no magical method of
ensuring that /tmp is not in danger of becoming full. Nor does it add
a magical method of fixing it if it does become full.
The fewer the number of partitions, the fewer artificial space
restrictions, which lessens the probability of one of those space
restrictions being reached.
Partitions are fine, if there is good pre-meditated reason for them
based on plenty of experience. My point is that there is no advantage
in partitioning just because it is possible - which is the opposite to
your original statement: "You should split off everything that one
_can_ split off."
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
On Thursday 01 September 2005 19:35, Paul Bredbury stood up and spoke
the following words to the masses...:
Aragorn wrote:
The job of a system's administrator should be to monitor the systems,
not to keep them running. ;-)
Having e.g. /tmp on its own partition, adds no magical method of
ensuring that /tmp is not in danger of becoming full. Nor does it add
a magical method of fixing it if it does become full.
The fewer the number of partitions, the fewer artificial space
restrictions, which lessens the probability of one of those space
restrictions being reached.
Partitions are fine, if there is good pre-meditated reason for them
based on plenty of experience. My point is that there is no advantage
in partitioning just because it is possible - which is the opposite to
your original statement: "You should split off everything that one
_can_ split off."
I did give plenty of reasons which I consider to be important. But then
again, it only boils down to one's own preferences, I guess...
--
With kind regards,
*Aragorn*
(Registered Gnu/Linux user # 223157)
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
On the seventh day, Aragorn wrote...
[snip]
Hello,
thanks to all you guys :-)
I managed to add a dedicated decent gentoo disk (40gigs) and split some
partitions off so I have a SCSI system for Windows and an IDE system for
Gentoo while still booting from SCSI.
Everything is working as it should so: happy emerging... :-)
--
mit freundlichen Grüßen/with kind regards
Christian Dürrhauer, Institute of Geography, FU Berlin
Sgt. Toomey: You would need three promotions to be an asshole.
|
|
[Original]
[Print]
[Top]
|
|
The content of this page is collected from Linux Forum, All copyrights and other associated rights are reserved by the original authors of the articles.