using single disk slice for /, /usr, and /var
I'm trying to partition a 36 GB disk on my SF V480 box. I have two options to handle the partitioning job here, the only requirement here is that I need to allocate as much space as possible to /opt.
option 1:
c1t0d0s0/ 2.5 GB
c1t0d0s1swap2.5 GB (the on-board RAM size is 4GB)
c1t0d0s2overlay
c1t0d0s3/var 2 GB
c1t0d0s4unassigned
c1t0d0s5/opt 26 GB
c1t0d0s6/usr 3 GB
c1t0d0s7unassigned
option 2:
c1t0d0s0/7.5 GB
c1t0d0s1swap2.5 GB
c1t0d0s2unassigned
c1t0d0s3unassigned
c1t0d0s4unassigned
c1t0d0s5/opt26 GB
c1t0d0s6unassgined
c1t0d0s7unassigned
I just ponder over the pros and cons of option 1 and 2, any comments? Option 2 allows the /, /usr and /var file system to share the 7.5 GB of space whereas option 1 limits the file system to the allocated space, there will be wastage (for option 1) if usage of space is low in each file system (except /opt).
Apprecaite your comments.
[1014 byte] By [
cmk168] at [2007-11-25 23:25:14]
# 1
This is usually a topic that gets people upset - LOL many differing views.
I personally like /var split out for obvious reasons - one being someone puts logs into /var for something and doesn't do log maintenance eating up all the disk space.
Then I make root, /usr, and /opt share disk space. For me it makes laying out the disks a bit easier to manage - only 3 partitions to think out - assuming not messing with SDS that is. So make mine option #3.
But I'm sure there are folks who have some very good reasons why they like your option #1.
# 2
I agree with you that /var should <always> be its own separate mount point.
whether you have
/ + swap
/ + /usr + /opt + swap
/ + /opt + swap
or whatever else (for the remaining slices) really depeneds on the application you're going to be installing afterward.
Unless it's a Sun standard package that you don't want to move from the base install directory (for convenience sake), you can just about always make an /opt partition or /opt/vendor or /usr/local at a later date if needed.
36GB root disk, /opt optimized (assuming 34GB usable)
/ 4GB
swap 4GB
/var 8GB - big enough to handle at least one crash dump on most smaller systems - if not make and mount /var/crash from the freepool
<freepool> 18GB
I then carve up the freepool once Veritas is installed, but that's just my preference.
# 3
Great question!
I really go for the fewer filesystems the better. This is a 180 degree switch from a few years ago. I find that it's easier to manage two or three "local" filesystems on a system verses many. I even have several systems with only one filesystem. Yes, this even includes /var.
The /var filesystem should be on it's own if you perform quite a bit of logging and for DR (crash) purposes. The systems where I eliminated the /var filesystems are swappable (that's a word, right?) v100 systems. If one of those go down, I rebuild or swap it immediately.
On larger servers, /var is seperate.
I work with a SAN and I keep all my application data on filesystem(s) located there, so I'm not counting those.
# 4
Thanks for your reply.
How about the number of inode created on each slice? If several major file systems (such as "/", "/usr", "/var" and "/opt") are sharing a single slice, they will tend to compete for the inode resource when files are created. If these file systems are seperated from each other with each sits in its own slice then it has its own pool of inodes created when the file system is first created.
Any other comments about this?
Thanks!
# 5
If you're creating more than a million files in /, /opt, and /usr (without creating a second filesystem for your application - whether it's /opt/vendor or /opt/<your location here>) that that's a problem. You need to review what your application is doing, or what the users on the system are doing and fix your permissions accordingly as they SHOULDN'T be writing to protected system areas, creating buckets of files.
As in my first post, Sun Best Practices = /var on a separate slice - and they usually suggest making it big enough to hold a crash dump or two. Nowadays, if you ask Sun, they'll also say minimize your filesystems. As with most of their recommendations, it works fine for most situations, but may not work for all (for example a jailed environment or a system that might live in a DMZ that needs to be completely hardened might want to have /usr and /opt separate as read-only filesystems)
Since you haven't said what your application does, let's assume its a web server, that's going to sit under /opt. If you intend on having all the bells and whistles, and will be creating dynamic html files, logfiles, etc, etc filling up that filesystem, *wouldn't it make sense to you* to make a separate partition for that application? If it were me, I wouldn't want an application capable of shutting down my / filesystem and preventing me from doing anything else (short of reboot and cleanup in Single User mode)
From an efficiency standpoint, IMHO it doesn't make sense anymore given that nearly all new systems have 18+GB or larger drives NOT to consolidate mostly static filesystems/directories that were split out years ago due to the spindle size limitation (remember the 1.05GB disks and smaller that meant you HAD to spread the OS image across a few disks).
When it comes down to it, if YOU want to use /, /usr, /opt, /var, swap, /foo, /whatever_else_you_want, feel free to do so. Obviously if you're planning to use either SDS or Veritas volume management, you're going to be limited to the number of physical slices on a disk.
Just a thought, or two
# 6
Jeffery,
Thanks for your valuable feedback.
More planning would be required if one were to lay file systems across serveral slices. But in the long run, this could be beneficial to the administrator who manages the server.
But if these file systems are spreading across several slices and mirror to another disk, it will be a pain to reinstall the OS and repartition and remirror the file systems again if a particular file system needs a larger partition, assum there's notbudget to upgrade to larger capacity disks.
Everything under one slice except the swap seems an attractive solution if it does not incur overhead to the performance of the server.
