> Hans Eric Sandström wrote (hes@xinit.se)
> > Please, Can anoyone explain to me why you want to create separate filesystems for
> > / /usr /tmp/ /var /home. I really cant find any use for this! and I am speking
> > from over 10 yrs of experinece with lost of different unix systems here. And what
> > I want is reliable systems that dont fail because some filesystem that went full.
>
> There are several good reasons. First of all when a user wants to annoy other
> users he just fills up his home directory which also fills up /tmp. This stops
> a lot of software from working. Even worse, when the disk is out of inodes, you
> cannot even start X anymore. /tmp can be filled up the same way.
> Removing the file will not help if the user keeps the file open, as the disk-space
> is only reclaimed after the file is closed...
No, This is a quota issue. If you have lots of users on your machine, which is not too
common these days with web/ftp/database servers, you really need to use quotas. And it is
also a administrative issue, just throw users that misuse the system out...
>
>
> Another reason is to mount /home and /tmp with different options, such as no-suid
> and no-dev. This helps against exploits and stuff like that. Also being able to
> mount /usr read-only can be of great help (e.g., it can be shared between multiple
> machines. This saves time when the OS must be upgraded as all machines are
> upgraded in parallel).
This is a point. But we where sort of talking about the default installation layout for the
average user. I have actually used the read/write read-only scheme once but got tired of
all software packages that do not understand that /usr should be considered read-only.....
>
>
> When you run a news-server it pays of to mount the news-spool with the noatime option
> to increase performance.
INN stores the news spool in a few lagre files now. But still I was talking about the
layout of the system disk /news is usually put on separate striped disks. At our company we
have a 7 disk md stripe for /news.
>
>
> > My resason for this is mainly (KISS). I have come by HP and AIX boxes that have
> > actually crashed beacuse the people who did the original installation did to slim
> > / and /usr or whatever partitions.
>
> That's not smart, you need to anticipate the growth and make sure / and /usr
> are large enough. This is difficult and a way to grow partitions (or slices or whatever)
> helps in this area. By the way, crashing HP/AIX/Solaris is not difficult, even when
> they are installed on a single partition....
Here you must have missed my point. If you buy a system today you usually get a 4Gb or a
9Gb system disk. Put root and and one swap partition on this disk and noting else...
If you're growing out of this you must be doing something wrong like installing an oracle
databse on the system disk. For example in /usr.
>
> > What wrong with having a big / partition with lots of free space to grow in. And
> > leave the fragmentation/quota issues to the filesystem implementation.
>
> Quota can be used to prevent a lot of problems mentioned earlier, but it won't
> help agains suid files in home directories. Also quota don't help the performance
> of the system. I only use quota when needed (on /home that is), the rest of the
> system shouldn't have to suffer.
Correct. /home does not really belong on the system disk if you are talking about multi
user systems. /tmp should not have quotas either because of performance but tmp does not
belong in the root filesystem either. We are really drifting from the average user
installation here to some multi user/multi application server installation.
>
> Another handy-dandy feature of multiple partitions is that it saves time when
> the disks must be checked for errors. Ever tried scanning a single 50Gb drive?
> you wish you would have partitioned the disk after waiting for 4 hours on a
> Friday evening..
Well, I have actually never used a 50Gb root filesystem. This is where we need a log based
ext2 filesystem. The 50Gb filesystem belongs to some application perhaps /news and you
really want to minimize downtime.
Hans Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/