以下基本上是我看到的问题.有些人可能会建议用几个问题来询问这些问题,但是,如果这些信息属于一个标题,我认为管理员可能会更容易.我相信这会提供丰富的信息.
特别针对/ tmp：
>应该是ln -s / var / tmp / tmp吗？
>在重新启动之间是否应保留/ tmp？
> / tmp应该在真正的磁盘区域还是允许基本上在SWAP区域(或tmpfs)上实现？
> / tmp应该与/(根)磁盘位于不同的磁盘上吗？
>您是否将/ tmp放在/(根)磁盘的不同磁盘控制器上？
> / tmp大小的任何经验法则？
>如何在系统启动时管理/ tmp空间？删除所有文件>一定的年龄？单独留下区域直到达到最大％年龄？
>是否应该制定任何程序性项目来管理这一领域？
解决方法
>应该是ln -s / var / tmp / tmp吗？
在完整的内存中磁盘映像(想想“实时启动CD”)的情况下,这可能是可以接受的,因为RAM的每个字节都需要被挤压.否则,除非你很难获得磁盘空间,否则没有. / var有自己的特点,在执行系统维护时,/ var / tmp混合/ tmp可能会产生意想不到的后果.它还增加了一个额外的依赖,因为/ tmp必须安装/ var / tmp才能正常工作;并非一切都需要/ tmp,您可能会遇到要将其迁移到其他分区或驱动器的情况,但不能,因为您不想卸载/ var.
>在重新启动之间是否应保留/ tmp？
不.如果您依赖此作为一致行为,那么您迟早会遇到问题.
> / tmp应该在真正的磁盘区域还是允许基本上在SWAP区域(或tmpfs)上实现？
当它被大量使用时,这是一个诱惑 – “我们将/ tmp放入RAM磁盘,它将加快访问速度,当系统重新启动/关闭时,没有什么可以清理”.但是,如果您正在考虑将临时空间实现为将要交换的RAM磁盘,那么我会考虑其他程序对系统交换空间使用的影响.如果交换存在作为“紧急溢出”的形式,当系统处于直线并且需要它时,你需要的最后一件事就是让失控过程消耗交换空间填充/ tmp,消耗内存,导致压力VM子系统交换到磁盘.在交换活动和附加I / O流进入RAM磁盘之间(这反过来可能导致额外的页面输入以满足seek()),您的系统将很快变为I / O绑定.
> / tmp应该与/(根)磁盘位于不同的磁盘上吗？
最好是,虽然没有必要.如果你大量使用它,或者有一个需要它的恒定工作量,那么肯定是的.假设示例：通过将/ tmp引入单独的主轴(即驱动器),将临时文件转储到/ tmp的数据库将获得轻微的加速.
>您是否将/ tmp放在/(根)磁盘的不同磁盘控制器上？
如果您对可恢复性或速度有要求,则应予以考虑.
> / tmp大小的任何经验法则？
它应该适应您预期工作量的2倍.通过这个,我的意思是,如果你有本地用户经常使用这个空间,迟早有人会做一些愚蠢的事情,并试图填补它.稍微过量将允许您避免程序停止的奇怪“问题”,因为他们的临时文件已经填满了剩余的空间.
如果这是一个“公共服务”安装,服务器提供一个或多个网络服务,但不托管用户,那么这可能是偏低的.如果这是一个多用户安装,这将是偏高的(是的,there are still places that host actual users而不仅仅是他们的网络服务).
>如何在系统启动时管理/ tmp空间？删除所有文件>一定的年龄？单独留下区域直到达到最大％年龄？
看看tmpwatch命令,我想你会发现它很适合你的这部分问题.该命令只删除超过特定年龄的任何文件,以小时为单位.根据填满的速度,你可以做30天,45天,90天等.
>是否应该制定任何程序性项目来管理这一领域？
我会推荐以下内容：
>所有文件都是暂时的,并且无法保证在重新启动后继续存在.
>过去％age的过时文件将在当地时间午夜通过运行tmpwatch命令的cron作业每晚删除.
剩下的就是您的具体需求.
