系统运维（零）：安装系统时挂载点设置不当导致的麻烦
笔者上一篇博文记录了本地化安装CentOS 7的一些流程心得，但是在笔者首次安装的时候，根目录挂载点只分配了30G，/tmp也只分配了20G，这直接导致服务器在小小安装了GPU相关配置和一些依赖库之后，不仅docker占满/tmp导致无法新建环境或镜像，/usr被占满了导致根本无法做任何更新或配置重写。
。。。
于是，这一篇博文记录了笔者在解决该问题时尝试过的方案与踩过的坑
一、临时清理 /tmp
1 修改自动清理时间并重启
笔者本以为/tmp满的原因可能是在本运行周期内产生的临时文件过多，linux来不及对文件进行清理。毕竟在默认配置中，我们可以去查看清理规则：
vi /usr/lib/tmpfiles.d/tmp.conf
默认的配置内容为：
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
# See tmpfiles.d(5) for details
# Clear tmp directories separately, to make them easier to override
v /tmp 1777 root root 10d
v /var/tmp 1777 root root 30d
# Exclude namespace mountpoints created with PrivateTmp=yes
x /tmp/systemd-private-%b-*
X /tmp/systemd-private-%b-*/tmp
x /var/tmp/systemd-private-%b-*
X /var/tmp/systemd-private-%b-*/tmp
从此处可以看出，/tmp 目录默认是10天清理一次，/var/tmp 目录默认是30天清理一次。笔者的服务器仅仅启动了1天多就写满了/tmp，证明确实是空间分配的过于小了。于是分别设置为1d 3d，重启服务器。
2 清理临时文件
结果重启后不出两天，/tmp再度容量告急。笔者进入/tmp查看文件详情，发现是jupyter-notebook创建的临时文件。并且由于jupyter-notebook的用户长期在jupyter中进行模型训练，图片缓存等始终处于占用状态无法自动删除。笔者因此尝试使用命令来强制释放文件。
注意不要使用rm -rf，除非你想让同事上来打你一顿
推荐使用tmpwatch，tmpwatch 工具从指定的目录中递归地搜索，并删除在指定时间段内没有被访问的文件。
tmpwatch -afvt 1 /tmp # 实验是否能删除/tmp下1小时内未被使用的文件
什么都没有发生。jupyter对临时文件的使用是全时频的，我们无法删除。也给出真实删除文件的命令：
tmpwatch -afv 1 /tmp # 真的删除/tmp下1小时内未被使用的文件
二、更换shell终端的临时文件挂载点
1 通过命令行更换
通过命令行可以暂时更换/tmp的位置，并在关闭该shell后失效
export TMPDIR=$HOME/tmp # 等号后面为自行创建的临时文件目录
2 通过配置文件更换
通过修改配置文件使得新的临时文件目录永久生效，也即设置为用户环境变量。用户环境变量通常存储于user/.bashrc或user/.bash_profile中。
vi user/.bashrc
在文件底部添加export TMPDIR=$HOME/tmp，保存后重新登录用户即可
在新的shell中输入：
echo ${TMPDIR:-/tmp}
若修改无效，去修改~/.bashrc，也即修改全局变量。注意全局变量中修改的目录应为所有用户都具有读写权限
三、清理根目录
暂时解决完tmp之后，尝试解决根目录爆满的问题。使用du -h之后发现/usr很大，占满了根目录分配的30G空间。由于分区时已经将opt等单独挂载，根目录没有垃圾文件可以清理，于是尝试扩容
四、尝试以软链接方式扩容根目录
通过添加物理容量的方式给/usr扩容需要挪动删除/home等排在根目录之后的分区，这是效率低下且不可接受的。如果你想要尝试，可以参考这篇博客。进行此类操作之前应建立还原点并在救援模式下进行，血与泪的教训。
在查找资料过程中，找到了一种通过软连接方式进行扩容的方式。我参考了下面这几篇博文：
Linux运用软链接解决目录空间不足
Linux通过软链接方式对磁盘进行变相扩容
使用软链接实现变相扩容
于是我兴高采烈地重启服务器，进入root用户
mv /usr /new
服务器也十分开心地回了我一个死机。再次重启，登录，哎为什么不让我输密码？
五、给自己擦屁股
于是开启了为期10小时的给自己擦屁股任务。我首先想到，只要复制回去就好
1. 复制回去
单用户模式
Linux有一种单用户模式，是在类似在Linux系统上工作时的一种拥有超级用户权限的模式。通常在开机选单给予1或S参数能进入这个模式。这个模式只在面对主机实体时才有机会透过开机选单进入，也因此确保超级权限授予的对象是能接触到主机的超级用户。此操作通常用于维护硬盘分区或更改超级用户密码等需在磁碟挂载前操作的维护。
首先，在我安装的CentOS 7 界面选择界面
按e键编辑配置，找到 ro 字样，修改为rw
找到 rhgb quiet 字样， 修改为 init=/bin/bash
按下“Ctrl+x”运行单用户模式
挂载磁盘
单用户模式下系统不会加载除系统挂载外的其他挂载点，所以我们需要挂载/new所在的磁盘。如果你将/new放置在/home下，则无需这一步。
cd ~
lsblk # 找不到该命令的情况下，只能盲挂
mount /dev/sdb1 /mnt1
cd /mnt1
ls -l # 查看/new是否位于此处
然后将/new拷贝回/usr
cp -r /mnt1/new/ /usr
服务器再次死机，看来单用户模式也使用了/usr下的文件
2.使用启动盘进行修复
修复方法参考了下面这篇博文：
Linxu Centos系统误删/usr目录，恢复操作（包含制作系统U盘）
进入系统救援模式
插入启动盘并从u盘启动，进到下图界面：
选择Troubleshooting，进入：
选择Rescue installed system，等待直至出现如下提示：
输入 1 并回车
这时系统会进入一个bash，并提示原操作系统就挂载到了 /mnt/sysimage下。
复制旧usr
这时再参照上面直接复制的方法，将复制的usr再度复制回去即可。
但我又遇到了问题。在复制回去的过程中，系统提示我：no space left in device，没错，因为根目录在复制前是满的，而先前使用的单用户模式在/usr下新建了文件，导致此时无法全量复制。
复制新usr
从启动盘的usr目录下复制到/mnt/sysimage/usr
在win下新建虚拟机安装centos7，将usr目录打包压缩，挂载后复制到/mnt/sysimage/usr下
六、重新分配挂载点空间
将各种数据拷出，打包docker，然后重新进行分区