[讨论]Solaris 文件系统分区[分享]

论坛中很多人问关于分区调整和扩大的问题，再现有的SOLARIS中确实很难做到，或比较麻烦。我发此帖希望给大家帮助。
现在SOLARIS 8应该是最流行的，就以它为例：

首先不要使用系统的默认安装方式！！！！！！
系统安装时硬盘有8个分区（0-7），但是其中2号分区不能用（那是对全盘的描述）

1、在没有特殊要求的情况的时候：
   只分/和SWAP，其中SWAP是内存的2倍，剩下的给/
2、如果有大型应用软件如：数据库、NOTES等
   如果你对应用软件对系统的分区要求不熟悉，也可以只分/和SWAP，其中SWAP是内存的3倍，剩下的给/
3、如果你经常要进行ufsdump的备份操作：
   那么文件系统要分得比较细一点，否则ufsdump做起来会很慢，同时避免备份不需要的内容。
4、如果你要装DISK SUITE，VOLUM MANAGER等软件的RAID管理，建议在4号分区留10M空间来做metaDB或rootdg，

以上只是建议，欢迎大家补充完善。
最好有各种针对应用软件的需求分析，我只给出了最苯的方法，不过也是通用性最强的方法。
再次强调不要用系统默认的安装方式！！！！！！！

wuya 回复于：2002-03-18 14:15:23

举个例子：/1GB_memory/20G_disk ---------------------- 0  / 2.5G 1 swap 2G 2 overlap 20G 3  4 /usr  2G(system/gcc/...) 5 /opt  2G(workshop/..) 6 /oracle 4G (oracle) 7 /export/home spare(user_data) ---------------------------------- 那位同志还有其他的想法

netterm 回复于：2002-03-18 17:45:01

一般还是要将/var单独分出来吧

bear 回复于：2002-03-18 18:53:52

netterm:请讲讲理由.

netterm 回复于：2002-03-18 21:09:52

在/ /usr /opt  /var中，一般情况下/var区是决大部分系统写log的地方，尤其是一些网管系统，都会把map信息放在/var，增长太快，很容易把整个分区弄满，还是分离出来为好。

bear 回复于：2002-03-19 09:22:16

如果单独分离出来的空间较小不是“更”容易“满”？这样对操作系统都会有影响。我认为：只要有合理的备份和清理机制，怎么放都一样。

shirley 回复于：2002-03-19 16:25:20

我认为讨论分区的大小，首先应该搞清楚每个分区的用途，同时一定还要结合具体的应用。这样才能做到分配合理。 系统至少要有/区和swap区。swap区通常设为物理内存的2-2.5倍。但是我的看法是即使没有特殊要求，也不建议只分两个分区。因为/区内的配置文件经常需要修改，而 /usr目录下的东西基本是不动的。将它们放在一个分区没有什么好处。另外一个方面是，如果只有/区，一旦/区受到破坏，那么整个系统都不可用了。如果采用多个分区，即使某一与系统无关的分区受到破坏（如/var/mail分区），Solaris系统仍能正常工作。 因此，如果硬盘足够大，应该划分多个分区。如/usr,/opt,/export/home,分别用于安装系统程序，第三方软件和用户的家目录。需要说明的是，/usr分区在分配空间的时候应该留有一定的空余空间，solaris patch和大多数package形式的软件包都要安装在/usr分区。 如果系统有多块硬盘，应该还要考虑各分区的活动频繁程度，将活动频繁的分区放在不同的硬盘上，尽可能减少硬盘读写的冲突。 另外一个方面是考虑具体的应用。比如系统要用做邮件服务器，应该单独分出一个/var/mail分区，象 sendmail就是使用/var/mail来保存用户的邮箱。而对于Oracle数据库应用，分一个区恐怕都不够。至少日志文件和数据文件就应该放在不同的分区。 以上是个人看法。希望大家继续讨论。

bear 回复于：2002-03-19 19:21:18

shirley分析的很透彻，也很有道理，我的第一个帖子匆忙间未分析全面，在补充几点： 1、在条件允许的情况下，要做到应用系统在硬盘级别完全分离，系统盘不要干别的。 2、对于重要的应用数据的硬盘一定要实行镜像保护，避免单点故障。 3、操作系统不要跨硬盘存放。 我想起来别的再补充。

sohu3370 回复于：2002-03-20 16:25:10

同意以上这些观点！关于/usr /var分区确实注意，这两个出现的错误我都遇到过：加PACKAG时，把/usr分区给塞满了，LOG文件占满了/var分区。 我认为，有的时候确实需要一个自由分区工具，不知现在solaris下有没有类似WIN平台的Magic Partition工具；还有就是，在这种情况下，大家是怎么解决问题的，谁有好的经验能否共享一下。 Oicq:70659312

amadan 回复于：2002-03-21 10:39:59

想问一下对swap大小划分问题：   我看到资料上说“当物理内存不超过256M时，主交换区容量设置为内存的两倍，超过256M时，则选择与物理内存的容量相同”，1G的内存，20G的disk，划2G的SWAP,会不会浪费硬盘资源？   呵呵，我是新手，还请各位多多指教，谢谢！

bear 回复于：2002-03-21 11:00:10

要看你是什么应用了，有些应用非常耗费内存，如果你没有特殊的应用可以在硬盘空间紧张的时候将SWAP的空间分分一部分出来给系统用。

babywang 回复于：2002-03-22 15:37:16

有一个问题是我长时间使用solaris做web服务器用下来的体会，我发现，solaris在运行一些应用程序的时候，并不是将所有的内存都去干一个事情，很明显，当一个服务启动以后，内存的确占用了，但是依然会有许多内存空余，但是我发现swap也同时加大了使用，也就是说内存和swap是一同使用的而不是说当内存不够的时候才使用swap空间，这个问题不知道大家如何看？我在操作freebsd的时候却完全没有遇到这个问题，这个系统都是完全使用内存除非一点都没有的时候才使用swap的。

sunfire 回复于：2002-03-22 15:37:55

楼上的说的都很好啊，我也来说几句吧！ 1、/swap空间的大小纯属财力问题，没必要在这个问题上纠缠。 2、solaris定义的每个分区都是有道理的，但我们没有必要非得按照它的要求（在早期版本中居然还有分区位置限制），定义更多的分区只是为了更好的管理系统。注意把/、/swap、/var分的大一点就可以了。 3、现在大家都很有钱，基本上一台机器上跑一个应用。本着“不坏--不碰”的原则，所以也不应该出现安装什么东东的时候因为分区大小而当机的情况（试验的话另当别论）。 4、在os和应用全部设置完毕但没有任何数据的情况下备份，有钱spare，没钱tape。 5、定制环境，定期检查。最好是每天早上发到你的mail里，这样就全了解了！ 6、定期做系统清理工作。在清理前请备份。 7、关于改变分区大小，没有办法，solaris不是象aix、hp那样是lvm。只能备份-增加-还原了。但是可以使用第三方软件,vritas!

sunfire 回复于：2002-03-22 15:40:24

你的理解有误，建议你看一下solaris internals这本书！

ohwwj 回复于：2002-03-22 16:01:44

我觉得shirley说的很有道理,分区最好还是看应用,如果你装mail服务器,/var/mail当然要分的很大啦.

raysonbest 回复于：2002-04-05 17:48:43

交流：QQ：66070768

cqg 回复于：2002-04-10 15:26:46

solaris的 DiskSuite不是可以给文件系统括容的吗?

bear 回复于：2002-04-11 22:48:53

那样是比较麻烦的，而且也不是万能的。

mmmmn 回复于：2002-05-10 12:33:39

DISK SLICES ----------- One important consideration is the allocation of disk slices.  It's certainly possible to install a system with a single partition mounted on /.  However, this can cause all sorts of problems.  There are good reasons to split up your disk, and I'll mention a few of them here. First, the root partition.  This partition is critical to booting the system.  If the root partition cannot be mounted read-only successfully, the system will simply hang.  I haven't intentionally sabotaged a Solaris 8 machine to find out what the exact behavior, but in 2.6 it would just stop without even issuing any sort of message. To fix this, you need to get physical access to the machine and boot off another disk, cdrom, or the network and fsck the root partition. Because you never want this to happen, you should make sure that nothing which receives frequent updates is on the root partition.  If you do not create an /opt slice, you should probably move /opt to /usr and set up a symbolic link.  When you edit files on /etc, you should sync to help make sure the file system will not be left in an inconsistent state if the machine experiences an abnormal shutdown. I generally make my root slices about 120MB.  That's larger than they need to be, but it never hurts to have a little extra room.  If you're setting up a system that has a lot of disk space, or one that can never be taken down for maintenance, you might want to make it even larger. In order for the root partition to be fscked and remounted read-write, the system needs to be able to run fsck.  Generally this isn't a problem, but because of the way some of the system binaries are installed, it can be. Let's take a look at /sbin/fsck...   ls: /sbin/fsck: cannot open file: No such file or directory GAK!  It's not there.  It's actually in /usr/sbin/fsck, which means that Solaris needs to mount /usr before it can fsck the root partition.  Now, /usr is the sort of partition that's likely to get updated a lot, and therefore is likely to not mount cleanly during boot.  This means that if /usr won't mount, not only can Solaris not fsck the root partition, it can't even fsck /usr to clean it up enough to mount it read-only. <rant> So, what can we do?  My first thought was to put fsck in /sbin and modify the boot scripts to call it from there during boot.  If /usr failed to mount correctly, we could fsck it and try again.  It sounded like a great idea, but take a look at this:   mankind:~ % ldd /usr/sbin/fsck         libdl.so.1 =>    /lib/libdl.so.1         libc.so.1 =>     /lib/libc.so.1         /usr/platform/SUNW,Ultra-2/lib/libc_psr.so.1 fsck, and indeed most of /usr/sbin and /sbin, is not actually a static binary.  We could certainly copy those libraries into the root as well, but fsck just calls /usr/lib/fs/ufs/fsck.   mankind:~ % ldd /usr/lib/fs/ufs/fsck         libc2.so =>      /lib/libc2.so         libadm.so.1 =>   /lib/libadm.so.1         libc.so.1 =>     /lib/libc.so.1         libelf.so.1 =>   /lib/libelf.so.1         libdl.so.1 =>    /lib/libdl.so.1         /usr/platform/SUNW,Ultra-2/lib/libc_psr.so.1 At this point, I gave up.  I swear that at some point I'll work out exactly what I need to do to make the Solaris boot process more reliable.  When I do, I'll include a nice script here to patch the boot scripts and move the necessary files into the root.  Until then, do be careful that you don't leave /usr in a dirty state very often. You might want to make /usr/local a seperate partition if you install things there often. In case someone from Sun is reading this and wants to take up the challenge of fixing this nonsense, I'll include my thoughts on how this SHOULD be done.]  In my mind, the most effective thing for Sun to do would be to set up a /boot partition with the kernel and all the static binaries needed to bring the system up. This partition would only be mounted read-only during normal system operation, and would be mounted read-write only long enough to make changes to software and configuration files installed there.  This can't really be the root partition itself, because /etc needs to be modified frequently. Once the software on /boot has insured that / and /usr are clean, the boot could proceed more or less as it does now.  This actually requires mounting /boot as a dummy root and then mounting the real root once it has finished it's work.  I think the benefit of would be immense, however.  I can't count how many times I've had to drive to a colo facility at 2am to fsck / or /usr and reboot a machine.  The idea that a rather stable system like Solaris can be so easily crippled and rendered unbootable by a simple power failure is frustrating, and a little embarassing. </rant> The risk of instability during the boot process is nearly eliminated if you enable logging on your file systems.  This is discussed in the section on /etc/vfstab below.  This doesn't excuse Sun's poor planning, but it can prevent it from causing problems for you. The /usr partition itself should probably be fairly large.  Solaris itself installs a lot here.  If you do not have a large disk, you may wish to make a very large /usr, let /usr/local live on it, and symlink /home to /usr/home.  This makes the most space available to both /usr/local and /home, though it sacrifices some security and stability. I build all of my new software in /usr/local, which I make a separate partition when possible.  This means that you can reinstall the OS (letting it format /usr) without destroying everything you've built in /usr/local.  It also means that if you're really paranoid you can mount /usr read-only, and possibly mount /usr/local nosuid. I generally symlink /opt to /usr/opt and let /opt-style packages install themselves there.  Trying to guess ahead of time how much of your software will go in /usr and how much in /opt is frustrating and rarely yields good results. Most of you have probably heard the old recommendation that your swap should be at least twice the size of your physical memory.  I'm not going to explain why that rule of thumb made sense, but it's really not that cut and dry.  There are many things to take into consideration, including the type of software running on the system, the number of different programs running on the system, and the physical memory in the system.  Personally, I tend to provide between one and two gigabytes of swap.  For certain applications I might make swap a few times larger than that. A few commonly suggested guidelines are:   0.5 * physical RAM over 1GB   2 * Oracle SGA, if running oracle I also like to make sure that the physical ram + swap is at least 2GB, even for a workstation. The /var partition is quite important.  Your logs go in /var/log, and some temporary files are stored in /var/tmp.  This makes a root mounting failure more likely than not after a power loss or kernel panic.  Also, because your logs go here and you don't want to risk losing log data, you should make this fairly large.  I generally make /var 200-400MB, depending on the log volume the system will generate. If you have sufficient slices available, you may wish to make /var, /var/log, and /var/tmp all separate.  This protects /var/log from being filled by bogus additions to /var/tmp.  /var still needs to be separate from / in this case because it is updated so frequently by running applications.  If you wish to store your mail in /var/mail, you will definitely want to have a dedicated slice for this, or relocate it and replace it with a symlink (see below). The /export/home partition that, by default, consumes the remaining portion of your disk is related to nfs exporting and the automounter. Personally, I don't really care for the automounter unless I'm building a whole NIS+/NFS network with a lot of workstations and users.  If you're installing a standalone server or workstation, you probably want to kill this and make a normal home volume somewhere. Because the automounter lives on /home by default, you'll have to kill it to get access to a partition on /home (see below).

fh008 回复于：2002-05-10 22:39:33

太精彩了，不过理解有点难。e文嘛~~~~~~~~`

bear 回复于：2002-05-11 11:19:49

这正是我们经常忽略的：“安全性”“可用性”。 好！！

mmmmn 回复于：2002-05-11 11:27:31

呵呵，所以我说bear你的分法是有毛病的。国内对安全很稳定虽然老说，其实却很不注意的

bear 回复于：2002-05-11 11:56:44

谢谢指教，其实我的分法是SUN SERVICE的工程师说的当时我觉得有道理，但有想不透，所以才贴出来讨论，你以为我装机真这样装吗？NO！每次我都“逼”用户说怎样分，他不懂我就按我的常规和具体情况分，变化很多。

mmmmn 回复于：2002-05-11 13:15:32

不用客气，把你的qq好给我就好：）

race 回复于：2002-05-11 23:02:02

分区那么麻烦的事不用做了吧，毕竟硬盘很大了，一锅煮去吧，还省事了。 具体怎么分合理，也没看见一个权威的测试报告，实际应用中还是凭经验和感觉。 如果还计较硬盘访问冲突的话，那SWAP必须安装一个单独的盘上了。硬盘的频繁活动程度听起来很好，细想就很难说了，频繁活动的的dameon都进内存了，最频繁的就是用户数据和SWAP了，那么最理想的就是把用户数据也单独放一个盘上，可装完系统还剩那么多空间，谁忍心闲在那里浪费？ 记录文件放在哪里都有撑爆磁盘的可能，哪个系统员敢这样做记录？ 要是真的必须计较分区的话，还得去咨询应用软件的技术支持，一般他们的软件只在乎CPU、内存和硬盘的大小，分区还那么重要？

bear 回复于：2002-05-11 23:50:58

见解也有独到之处。

原文转自：http://www.ltesting.net