Sorry - had to pipe in....here's some info on this that I have gathered....
So far, I havn't heard much in why you would want a flat file system - "becuase we have been doing it for years" is not compelling enough.
What if you want to ramp up on file system security, prevent accidental deletes etc.
How do you make /usr a read only file system if it is part of / ?????
And from Sun, they do NOT recommend a flat file system either...
Here are the default Solaris File Systems:
root (/) (system files, kernel, devices)
/usr (system files, openwin, and commands)
/home (user directories)
/var (systeam files, logs, queues, spool)
/opt (third party software and applications)
/tmp (temporary - cleared at boot)
Here's some more info from ITRC:
Anyway, I'd always use multiple filesystems unless disk space is tight (see reasons that others have given). My primary reason is so a user doesn't crash the system when he mistakenly fills up the filesystem. He may interrupt what other users are doing for a time but he shouldn't crash my system.
And I used AIX 3.2.3e with JFS in 1993. There was no separate "online" JFS product. Those features came with the OS. I was shocked the first time I was exposed to HP-UX and found online JFS was an add-on.
The isolation of the operating system files into multiple filesystems is a protective measure.
The idea is to not let something like the root ("/") filesystem fill to capacity (because you mis-spelled '/dev/rmt/om' [note the letter, not the number]), while retaining space in other mountpoints like '/tmp' and '/var' for the operating system to continue to work.
With regard to mountpoints, *do* use the standard mountpoints for the HP-UX operating system. Segregation of /home, /var, /usr, /opt, etc. is a protective approach which allows a filesystem to fill without (hopefully) causing the entire system to grind to a halt. It also provides a logical division of function (see 'man 5 heir').
On systems with not much diskspace we do create them with only 3 lvols (/, /stand and swap) - it then merges all free space into one lvol (/) which is easier to administer then.
Its a question of whats easier to administer.
If you have enough diskspace then with /usr, /opt, /home, /tmp, /var etc. its easier to administer because only certain types of files go into each one (or not - as in the case of opt or usr unless someone installs something new). So as space grows you can easily find out who/what. Eg. if you have a /home then if some moron user fills it up it wont screw (or possibly crash) the system (as it could do if only a / lvol), same for /tmp and /var.
So its not only easier to administer and to find out who is using up the diskspace but much safer too to have multiple lvols.
Having recently recovered some corrupt volumes on a system, my opinion is that the better option is to use the multiple filesystem layout.
If you have a single filesystem, and it gets corrupted due to a system failure, you're straight into a pretty serious recovery situation. With multiple filesystems, you've got a fair chance that you'll still be able to access most or all of the commands on the system to carry out repair work on those areas that are corrupt.
You could of course argue that it was possible for all the filesystems to become corrupt at the same time, but that's not too likely.
Multiple lvols do add a little more maintenance for the SA, but it does reduce system downtime when problems occur.
If you have only one file system and it becomes corrupted, you will have recover the entire system. For me, that's about 4 to 6 hours of downtime. With multiple file systems, a corruption has a chance of occurring in a non critical file system. In this case, there is no system downtime. An application may be unavailable during recovery, but the recovery should take a lot less than 4 hours.
Run away applications that fill up a file system can crash the system if you have only one file system. / and /var are 2 areas that cause problems when they fill up. The last time I had /var fill up, I had to reboot the system to clear things up. I make it a point to give each application there own file system. That way, if they fill things up, they only hurt themselves. (I have a file system checker monitor in ITO to give early warning that an application is about to fill its file system).
To summarize, system downtime costs money and aggravates customers. Using multiple file systems reduces potential system downtime.
There are issues where you can keep going over this question. There are very good advantages of splitting into logical volumes the root partition.
1) It is easy to keep and identify every subdirectory that you maintain on your system. e.g. when you partition your /stand, you know that only system specific files are in there.
2) /var will contain only logs and other normal configuration data. It is easy to identify how much capacity it is using. Sometimes, your system get's too slow and you can identify what's causing issues. There might be a open file taking a lot of disk space. You can identify easily which partition is using what space and is increasing drastically or not. Even though you have a big disk size, you need to analyze issues and here it helps.
3) Your /application directories can be used seperately to identify through bdf how many seperate applications are there. By this i mean independent applications.
4) We can get to know if the system crash directory has enough space or not by looking at bdf instead of finding disk space for each directory. like /var/adm/crash.
5) You can mount or unmount filesystems, depending on how you would like to mount them. It is easier for tracking and management of all such filesystems if they are configured as seperate logical volumes instead of a flat / filesystem.
6) You can use maximum I/O utilization by having some free disk space which will not be used and i/o use will be less spanning through the whole disks. The free disk space can be utilized as and when necessary. This would help specifically when multiple disks are in question.
There are arguments for and against making the system disk a "flat" filesystem. You don't have worry too much about wasted disk space. This is probably the main argument for making it one filesystem.
If you plan on separating "data" type information from the actual system
resources, then breaking the disk up into separate filesystems is preferred. Sun does make allowances for putting everything under root.
If you use ufsdump or some other utility to backup your system disk, it is
nice to break it up, so that you can reduce what you backup and limit things to necesary files.
At least on the suns, there isn't really a set way for the disk layout. I
am not sure about some other systems, like HP-UX and AIX machines.
At home I have a tendancy to have a few partitions. /, /usr, /usr2
It helps me to layout my disk for system, products/programs, user data. It
allows me to breakup my backups in a more logical manner.
Since disk space isn't an issue, Things like backups will probably determine your layout.
One other thing that you can do, if you partition the drive, is you can
configure the partitions so that ones which might be accessed
more often are placed at the faster access locations on the disk. This
would be getting quite serious in your disk planning, Since
most disks these days are quite fast, this is probably not much of an issue anymore.
We use both HP-UX and Solaris. The reason the "Sun Guys" like one big partition is for ease of upgrades and the lack of tools to expand root slices. Unlike HP, Sun has not integrated volume management and VxFS into their kernel, so you cannot easily increase the size of the root slices. The volume management is supposedly integrated into Solaris 9, but /, /usr, /var, /opt, etc must be UFS and cannot be increased online. It also has traditionaly made upgrades much easier. Back in the days of 2 & 4 G drives moving to a new release of Solaris was much easier with one big slice, since you did not have to worry about runnng out of space on indidvidual slices.
With OnlineJFS, the only filesystem you cannot increase online is /stand (HFS), which makes it practical to leave everything in seperate lvols. I think everyone else has indicated all of the reasons why they (and I) prefer the multiple lvols, just make sure you invest in OnlineJFS if you need to maximize uptime.
I think if the "Sun Guys" had the flexibility of using a Volume Manager and OnlineJFS they too would choose multiple lvols.
Well, seein as how Im a Sun guy, I'll have to say that most real Sun guys dont believe in a flat file system either.
The default layout for Sun OS is to have swap, data, and OS segregated since Solaris 2.5.1. In Solaris 7,8,9 they are defaulting to a more LVM structure minus logging for UFS.
Three reasons for splitting up disks (either LVM or partitioning in solaris).
First is security.
As someone else mentioned, if a user types in tar cvf /dev/tape, then the OS disk can fill up causing the system to fail. This same thing occurs with core files, temp files, etc... Watch how fast users hound you when the system will not let them log in and hangs for 10 minutes before disconnecting them because the OS disk is full and they can not see it.
Second is Control/?Mmanagement
First, I like to control how much goes to what. I.E. /tmp is generally 512MB on a CAD/FEA server, but only 256MB on others. So I can control how much space goes to each area, without risk or worry.
If my data drives /1a, /2a, etc.. get full I can add to them with other disks. I can not do the same with the OS as it will negatively impact performance, so have to end up splicing in mounts and this gets ugly to manage.
This brings me to the last part.. performance.
If is use different partitions/volumes, I can tune each filesystem for it's job. I.E. SunUFS/VxFS for critical files systems (/opt /usr, etc...), but why use this for /tmp or fea scratch areas?
S???cratch directories for databases and FEA can use huge block sizes to improve performance, where in user data disks I would loose 5-10% of my space if I used large blocks.
Old school SunOS used to teach the flat file system method (so did HP-UX back in 9.0X), but the servers for the last several years are shipping with Veritas which is much more powerfull than HP's on-line JFS. Both systems allow you to push/pull file systems and make changes on the fly to disks, volume groups, and logical volumes without much more than a bit of knowledge and a few mouse clicks.
You may be interested in the "Filesystem Hierarchy Standard", here:
http://www.pathname.com/fhs/...which says, among many other things:
* Disk errors that corrupt data on the root filesystem are a greater problem than errors on any other partition. A small root filesystem is less prone to corruption as the result of a system crash.
First of all, sun people are idiots, I mean, look at their archaic operating system, the damn thing doesn't have a logical volume manager! They were the LAST to adopt linux! Hell, IBM beat them to it by YEARS! They rely TOO much on third party dealers, most that I wouldn├в t trust to get me a cup of coffee, let alone a napkin for my bagel!
And to clear anything up, I am a certified (probably crazy) solaris admin. Plus I moved to the DARK side this afternoon: I just installed AIX 5L on an IBM power-e 650. OK, now back to the argument:
Any admin will tell you to break up root for MANY reasons:
(1) So that some ROGUE application doesn├в t fill up the OPERATING SYSTEM filesystem├в s causing the WHOLE server to CRASH. If you got everything under ├в /├в , then you risk this EVERY SINGLE DAY. Like I want that! We have over 600 unix servers (400-500 HP 9000├в s, ~100 solaris servers, & 1 AIX box), you think we need a headache like that?
(2) So you can BALANCE filesystem├в s to other disks if necessary, for offloading disk contention.
(3) Backup├в s, one so you can backup the operating system without backing up the data/applications of the server, vice-versa.
(4) Searching, like when using ├в find├в with the ├в -xdev├в option.
(5) Security! if you have sensitive data on a MOUNTED filesystem you can control WHEN that FILESYSTEM is mounted during the boot process, try that with a FLAT filesystem.
SUN├в s problem is their limited eyesight. They can├в t see that they will be out of business within a few years if they don├в t get their act together. Their system management tool is just plain stupid. Their lack of a LVM is crazy. Their lack of a clear vision doesn├в t help. Trust me, when I get time to rotate the sun web servers out, I will! I helped put them there, I can take them out!
Even if you have large disks, there is a possibility to fill them up, e.g. by accidental extensive logging. So separate /var partrition is always the safest solution.
I think it depends on the use of your computer. If it is a server with a very static installationen (like database-server) you can split it up for the earlier stated reasons. If it is a very dynamic workstation (CAD/CAE station) i would use only /stand (hfs), swap and /, and maybe /var as an extra partition to prevent spooling files file up your /-filesystem.
We use on our workstations to following setup:
1. disk: vg00
/stand: 84m
swap
(add. swap if high memory)
/ 3gb
/var 2gb
/export/hostname (rest, for local installed applications, all other application are on a binary server)
2. disk: vg01
/export/hostname/u (userdata)
Proverbs 3:5,6 Trust in the Lord with all your heart and lean not on your own understanding; in all your ways acknowledge him, and he will make all your paths straight.
