确定 Unix 上给定文件系统挂载的源

确定 Unix 上给定文件系统挂载的源

背景

最近,我的家用 FreeBSD 服务器遇到了一些问题。我最近将其升级到最新的稳定版本,并且我注意到 /var 分区出现了一些奇怪的行为。最初,我对系统进行了配置,使 /var 有自己的分区,其中 /var/run 和 /var/log 在内存磁盘中(/tmp 也是如此)。

升级后,我注意到有一个新的第四个内存磁盘直接安装到我的 /var不是手动设置,不在我的 fstab 中。它的大小只有 28 兆左右,在尝试更新我的 ports 集合时会导致问题。 ramdisk 在启动时自动安装,并且在多用户模式下无法卸载。如果我切换到单用户模式,我可以毫无问题地卸载它,但是重新启动会导致它立即弹出。

系统规格已包含在帖子末尾。

问题

有没有什么方法可以在安装给定内存磁盘(或任何文件系统)后准确确定安装的是什么?

或者,有人知道什么可能导致新的 /var ramdisk 弹出吗?

系统规格

# uname -a

FreeBSD sarge 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #0: Thu Nov 22 14:02:13 PST 2012     donut@sarge:/usr/obj/usr/src/sys/GENERIC  i386

# df

Filesystem   1K-blocks      Used     Avail Capacity  Mounted on
/dev/da0s1a     515612    410728     63636    87%    /
devfs                1         1         0   100%    /dev
/dev/da0s1d     515612    287616    186748    61%    /var
/dev/da0s1e    6667808   2292824   3841560    37%    /usr
/dev/md0         63004        32     57932     0%    /tmp
/dev/md1          3484         8      3200     0%    /var/run
/dev/md2         31260         8     28752     0%    /var/log
/dev/md3         31260       512     28248     2%    /var       <-- This

# cat /etc/fstab

# Device    Mountpoint  FStype  Options         Dump    Pass#
/dev/da0s1a /       ufs rw,noatime      1   1
/dev/da0s1d /var        ufs rw,noatime      2   2
/dev/da0s1e /usr        ufs rw,noatime      2   2
md      /tmp        mfs rw,-s64M,noatime    0   0
md      /var/run    mfs rw,-s4M,noatime     0   0
md      /var/log    mfs rw,-s32M,noatime    0   0   

预先感谢您提供的任何帮助。

答案1

所以,我似乎已经解决了这个问题。如果有人有任何关于原因/方式的补充,我洗耳恭听。

疑似原因

据我所知,此行为的原因是 /var 目录本身损坏。安装操作系统的主驱动器是拇指驱动器(这是一个旧驱动器,但采取了预防措施以防止闪存滥用)。坏扇区似乎导致 /var 中的某些活动以多种方式失败(最常见的两种是“无法创建符号链接”和 /var/lost+found 中的彻底内核恐慌,但也有其他人也观察到,具体取决于具体的活动)。

修复方法

一旦我通过单用户模式、重复 fsck 执行和手动干预的组合修复了损坏的 inode,神秘的 /var memdisk 就会在启动时停止安装。有关更多信息,请参阅:http://phaq.phunsites.net/2007/07/01/ufs_dirbad-panic-with-mangled-entries-in-ufs/

系统现在可以在没有 /var memdisk 的情况下启动,但毫无疑问,新的拇指驱动器已经准备好了。

猜想 - 如果您有任何见解,请更正或补充

这就是我对坏文件系统的 Unix 行为的了解变得模糊的地方。我猜测 memdisk 弹出的原因是 FreeBSD 能够自行挂载 /var 分区,但对某些项目的访问失败。为了保持系统正常运行,我怀疑操作系统出于需要创建了内存磁盘(因此在 /var 下有两个挂载)。这在以前并不明显,因为大多数损坏都位于非关键目录中。也许更新在物理磁盘本身上移动了文件,从而将另一个更重要的文件放在故障扇区中?

再次强调,如果能进一步了解损坏如何导致神秘的内存盘,我们将不胜感激。再次感谢。

相关内容