我目前负责运行 Red Hat 的服务器和处理大型文件的生物信息学 Web 应用程序，其中一些文件在解压后超过 100GB。解压这些文件的操作由几个不同的程序完成，所有这些程序都使用系统临时目录 /tmp。当解压大型文件时，/tmp 会填满并停止正在进行的操作，从而导致 Web 应用程序中出现下游错误。我必须进入并从 /tmp 中删除问题文件。
服务器的文件系统设置如下：
/*output of df-h follows*/
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_root-LogVol01 83G 34G 45G 43% /
tmpfs 95G 0 95G 0% /dev/shm
/dev/sda1 485M 81M 379M 18% /boot
/dev/sdb1 8.0T 6.2T 1.5T 82% /data
/*output of blkid follows*/
/dev/sda1: UUID="5f489589-0678-46c1-9f0f-e4e66c6a9e04" TYPE="ext4"
/dev/sda2: UUID="k2rP0k-1YhK-72D9-fRrQ-BxUW-3gaC-6KF0nh" TYPE="LVM2_member"
/dev/sdb1: UUID="4e54bee3-6450-446f-af80-70ca6268e12f" TYPE="ext4"
/dev/mapper/vg_root-LogVol01: UUID="b6f228dc-fa6c-43c1-b88e-3b43a75e980b" TYPE="ext4"
/dev/mapper/vg_root-LogVol00: UUID="80c6863d-c9f8-4abe-a353-a6a6818dc82d" TYPE="swap"
/*output of fstab*/
/dev/mapper/vg_root-LogVol01 / ext4 defaults 1 1
UUID=5f489589-0678-46c1-9f0f-e4e66c6a9e04 /boot ext4 defaults 1 2
/dev/mapper/vg_root-LogVol00 swap swap defaults 0 0
/dev/sdb1 /data ext4 defaults 1 1
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
sysfs /sys sysfs defaults 0 0
proc /proc proc defaults 0 0
我了解 Linux 的基础知识，但对文件系统了解不多。我想要做的是制定一个永久解决方案，为临时目录分配更多空间。我愿意将 TMPDIR 环境变量设置为指向另一个具有更多空间的文件系统。或者，如果可能的话，我同样愿意为 LogVol-01 分配更多现有空间。
我的问题是，根据我当前的文件系统详细信息，如何永久地为临时目录分配更多空间。正如您在 df 输出中看到的那样，我有多余的磁盘空间。我没有设置服务器，但无论好坏，我现在都负责它并拥有 root 访问权限！
答案1
更新：
既然您现在已经确认 /tmp 不是符号链接，并且 /tmp 上没有挂载。这基本上说明 / 已填满。您如何解决这个问题？2 个选项。
- 我将插入另一块硬盘并通过在 /etc/fstab 中插入适当的条目将其安装在 /tmp 上。
- 或者作为临时措施，将 /tmp 移至另一个驱动器（如 /dev/sdb1），该驱动器目前有数百 GB 的可用空间。只需在 /dev/sdb1 上创建一个 tmp 目录即可
IE
sudo mkdir /data/tmp
sudo chmod 1777 /data/tmp
sudo rm /tmp
sudo ln -s /data/tmp /tmp
如果您希望添加更多存储空间（这是一个更好的长期解决方案），网络上有很多关于如何向 Linux 添加额外驱动器的教程。
原始答案...
tmpfs 可能是罪魁祸首。它基于 RAM，在需要时也会使用交换。这意味着它会不断增长，直到没有更多的 RAM 可用于 tmpfs。最终导致解压缩不完整。
然后您需要做的是编辑 /etc/fstab 并注释掉（以“#”开头）以“/tmp”开头的行，然后重新启动或卸载 /tmp（使用“sudo umount /tmp”）
看起来您已经使用 LVM 获得了整个驱动器，因此不需要安装 /tmp 的替代文件是安全的。
编辑：
希望我能看到 redhat 或您的默认 fstab 文件。无论如何... /tmp 可能不存在于 fstab 中，因为它可能是符号链接。
要查找，请运行“ls -ld /tmp”。如果是符号链接，您会看到它以 /tmp -> /dev/shm 或其他方式列出。
如果它实际上是 /dev/shm 的链接或作为 tmpfs 挂载的目录，请使用以下命令修复它：
sudo rm /tmp
sudo mkdir /tmp
sudo chmod 1777 /tmp
编辑2： 转念一想，也可能是其他原因。
- /tmp 已满，或者
- 解压工具无法很好地处理大型档案。100GB 未压缩数据可能是一个大型档案！您使用什么工具来提取档案。它的格式是什么？我知道某些版本的 tar 有问题，或者
- 文件系统类型不允许提取某些文件，因为它们超出了文件系统限制。目标文件系统是什么类型？是 ext3 还是 4 还是其他类型？
- 或者文件系统确实已满。
答案2
我非常确定 /tmp 和 tmpfs 是基于 RAM 的，因此解压它们并将它们存储在 RAM 中可能是导致系统停止运行的原因。操作系统开始疯狂地交换，因此您开始真正注意到性能下降。
此操作必须在 /tmp 中进行吗？
添加实际答案：