☰

Unix에서 특정 파일 시스템 마운트의 소스 확인

tag-icon • tag-icon freebsd mount
Unix에서 특정 파일 시스템 마운트의 소스 확인

배경

최근에 나는 내 집 FreeBSD 서버에 몇 가지 문제를 겪고 있습니다. 최근에 최신 안정 버전으로 업그레이드했는데 /var 파티션에서 이상한 동작을 발견했습니다. 처음에는 /var가 메모리 디스크에 /var/run 및 /var/log를 포함하는 자체 파티션을 갖도록 시스템을 구성했습니다(/tmp와 마찬가지로).

업그레이드 후 내 /var에 직접 마운트된 새로운 4번째 메모리 디스크가 있음을 발견했습니다.아니요내 fstab이 아닌 수동으로 설정하십시오. 크기는 약 28MB에 불과하며 포트 컬렉션을 업데이트하려고 할 때 문제를 일으킵니다. 램디스크는 부팅 시 자동으로 설치되며 다중 사용자 모드에서는 제거할 수 없습니다. 단일 사용자 모드로 전환하면 문제 없이 제거할 수 있지만 재부팅하면 즉시 팝업이 나타납니다.

포스팅 마지막 부분에 시스템 사양이 포함되어 있습니다.

질문

특정 메모리 디스크(또는 파일 시스템)가 마운트된 후 정확히 무엇이 설치되었는지 확인할 수 있는 방법이 있습니까?

또는 새로운 /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 디렉토리 자체가 손상되었기 때문입니다. OS가 설치된 메인 드라이브는 썸드라이브(오래된 드라이브이지만 플래시 메모리 남용 방지를 위한 예방조치가 되어있습니다)입니다. 불량 섹터로 인해 /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 파티션을 마운트할 수 있지만 특정 항목에 액세스하지 못하기 때문인 것 같습니다. 시스템을 계속 가동하고 실행하기 위해 OS가 필요에 따라 메모리 디스크를 생성한 것으로 의심됩니다(따라서 두 개의 마운트는 /var 아래에 있음). 대부분의 손상이 중요하지 않은 디렉터리에서 발생했기 때문에 이전에는 이것이 명확하지 않았습니다. 업데이트로 인해 파일이 실제 디스크 자체로 이동되어 실패한 섹터에 또 다른 중요한 파일이 배치되었을 수 있습니까?

다시 한번 말씀드리지만, 손상이 어떻게 신비한 메모리 디스크로 이어질 수 있는지에 대한 추가 통찰력을 주시면 대단히 감사하겠습니다. 다시 한 번 감사드립니다.

관련 정보