Determinando a origem de um determinado sistema de arquivos montado no Unix

Question

Plano de fundo

Recentemente eu me deparo com um obstáculo no meu servidor FreeBSD. Eu recentemente atualizei para a última versão estável, e notei um comportamento estranho com a partição / var. Originalmente, eu tinha o sistema configurado de tal forma que o / var tinha sua própria partição com / var / run e / var / log nos discos de memória (/ tmp também).

Após a atualização, percebo que há um novo disco de memória de quarta montagem diretamente em / var que eu tive não configurado manualmente e não está no meu fstab. É apenas 28 megas ou mais em tamanho e está causando problemas ao tentar atualizar minha coleção de portas. O ramdisk é montado atuomagicamente na inicialização e não pode ser desmontado no modo multiusuário. Se eu for para o modo de usuário único, poderei desmontá-lo sem problemas, no entanto, a reinicialização fará com que ele seja retomado.

As especificações do sistema foram incluídas no final do post.

Pergunta

Existe alguma maneira de determinar exatamente o que está montando um determinado disco de memória (ou qualquer outro sistema de arquivos) após a montagem?

Como alternativa, alguém tem alguma idéia do que poderia ter causado o surgimento do novo / var ramdisk?

Especificação do sistema

# 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   

Agradeço antecipadamente por qualquer assistência.

    

Answer 1

Então, parece que consertei o problema. Se alguém tem alguma coisa a acrescentar sobre o porquê / como, eu sou todo ouvidos.

Suspeita de causa

Pelo que eu posso dizer, a causa desse comportamento foi corrupção no próprio diretório / var. A unidade principal em que o sistema operacional está instalado é um pen drive (antigo, mas com precauções para evitar o uso indevido de flash). Parece que um setor (es) ruim estava causando certas atividades dentro de / var a falhar de várias maneiras (as duas mais comuns foram 'falha ao criar symlink' e pânico absoluto do kernel em / var / lost + encontrado mas havia outros observaram também, dependendo da atividade exata).

A correção

Depois de corrigir os inodes corrompidos por meio de uma combinação de modo de usuário único, repetidas execuções fsck e intervenção manual, o mistério / var memdisk parou de ser montado na inicialização. Para mais informações, consulte: link

O sistema pode inicializar sem o / var memdisk agora, mas um novo pen drive está em ordem, sem dúvida.

Conjectura - Por favor, corrija ou acrescente a isto se você possui algum insight

É aqui que meu conhecimento sobre o comportamento do Unix com sistemas de arquivos ruins fica confuso. Meu palpite sobre por que o memdisk apareceu é que o FreeBSD foi capaz de montar a própria partição / var, mas o acesso a certos itens falhou. Para manter o sistema funcionando, minha suspeita é que o sistema operacional criou o memdisk por necessidade (daí as duas montagens em / var). Isso não ficou aparente antes, porque a maior parte da corrupção estava em um diretório não crítico. Talvez a atualização tenha mudado os arquivos no próprio disco físico, colocando outro arquivo, mais importante, no setor (s) com falha (s)?

Mais uma vez, qualquer outra visão sobre como a corrupção leva a um memdisk de mistério é muito apreciada. Obrigado novamente.