bind mounts by systemd não funciona magicamente com systemd-tmpfiles?

3

Eu tenho um desafio estranho na minha caixa Debian 8.

O plano de fundo é que eu quero montar alguns diretórios como tmpfs, para evitar IO físico (wakeup / flash wear).

Provavelmente devo montar um tmpfs separado para cada diretório. No entanto, o que tentei primeiro foi o bind-mounts em /tmp/mnts . (Minha tarefa anterior era mover o ES do disco para um pequeno armazenamento flash, para evitar spinups, então tentei usar o mesmo padrão).

Então eu quero criar diretórios no tmpfs no momento da inicialização. Ou seja systemd-tmpfiles. E então ligue-os em vários lugares em / var.

# /etc/tmpfiles.d/tmpfs-mnts.conf snippet
# Type Path    Mode UID  GID  Age Argument
d /tmp/mnts/var-lib-icinga-spool-checkresults 0750 nagios nagios -

# /etc/fstab snippet
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/tmp/mnts/var-lib-icinga-spool-checkresults /var/lib/icinga/spool/checkresults none bind

systemd-tmpfiles --create + mount -a funciona bem. Mas não funciona no momento da inicialização, então há uma condição de corrida ou algo assim. Mas a falha é um pouco interessante - o findmnt mostra que o diretório de origem foi deletado.

# findmnt|grep /var/lib/icinga/spool/checkresults
└─/var/lib/icinga/spool/checkresults                     tmpfs[/mnts/var-lib-icinga-spool-checkresults//deleted] tmpfs       rw
# cd /var/lib/icinga/spool/checkresults/
# mkdir ./test
mkdir: cannot create directory ‘./test’: No such file or directory
# ls --inode /tmp/mnts
7414 var-lib-icinga-spool-checkresults
# ls --inode /var/lib/icinga/spool/
6254 checkresults

Então parece que

  1. A montagem aconteceu corretamente depois que o systemd-tmpfiles criou o diretório de origem
  2. systemd-tmpfiles, em seguida, excluiu o diretório de origem
  3. Você tem permissão para excluir o diretório de origem de uma montagem de ligação (?!)
  4. systemd-tmpfiles criaram o diretório de origem uma segunda vez

Eu acho que há várias perguntas. Podemos confiar em 1) trabalhando? Poderia 1) ainda funcionar se algo diferente de systemd-tmpfiles criou o diretório de origem? Qual o motivo de 2) e 4) acontecerem? E o que há com 3), sempre foi assim?

    
por sourcejedi 16.07.2015 / 15:46

1 resposta

1

bind não é confiável quando definido em fstab em um sistema com systemd. O Systemd analisa o fstab e tenta descobrir qual a ordem para montar e ligar as coisas. Da minha própria experiência, isso acontece errado 100% do tempo. A melhor opção é mover tudo o que você liga do fstab e fazer com que você possua os arquivos do sistema xxx.mount para o systemd. Isso foi você ganhar controo sobre a ordem, etc.

    
por 23.10.2016 / 16:24