Início / unix / Perguntas / 772364
Accepted
melonfsck
Asked: 2024-03-15 03:51:48 +0800 CST

Por que um sistema de arquivos está desmontado, mas ainda está em uso?

  • 772

Eu uso sistemas de arquivos ext4 há muito tempo e é a primeira vez que vejo um comportamento estranho do sistema de arquivos ext4.
Há um sistema de arquivos ext4 em /dev/dm-2
Um erro de E/S ocorreu no dispositivo subjacente e o sistema de arquivos foi remontado somente leitura.
Está bem e esperado pela configuração.
Mas por alguma razão desconhecida, agora não é possível desmontar completamente o sistema de arquivos.
O comando umount /the/mount/pointretornou com sucesso. Outras execuções desse comando dizem "Não montado".
A entrada de montagem desapareceu da saída do mountcomando. O sistema de arquivos não está montado em nenhum outro lugar.
Mas.
Primeiro: não consigo ver o EXT4-fs: unmounting filesystemtexto normal no dmesg. Na verdade, não há nada no dmesg.
Segunda coisa (fala por si que algo está errado):

root# cat /proc/meminfo | grep dirty
Dirty:           9457728 kB
root# time sync

real    0m0.012s                                                                                
user    0m0.000s                                                                                
sys     0m0.002s
root# cat /proc/meminfo | grep dirty
Dirty:           9453632 kB

Terceira coisa: o diretório de depuração /sys/fs/ext4/dm-2ainda existe. Tentei escrever "1" na /sys/fs/ext4/dm-2/simulate_failesperança de que o sistema de arquivos fosse desativado. Mas não faz nada, não mostra nada no dmesg.
Finalmente, a quarta coisa que torna o dispositivo inutilizável:

root# e2fsck -fy /dev/dm-2
e2fsck 1.46.5 (30-Dec-2021)
/dev/dm-2 is in use.
e2fsck: Cannot continue, aborting.

Eu entendo que é possível reiniciar e etc. Esta questão não é sobre como resolver algum problema simples de novato. Quero que alguém com experiência em sistema de arquivos ext4 me ajude a entender o que pode causar esse comportamento.
O dm-2dispositivo não está montado em nenhum outro lugar, não está montado em bind, nem está sendo usado por mais nada.
Não havia mais nada usando o Dirty Cache no momento de medi-lo com cat /proc/meminfo | grep dirty.
A chamada de desmontagem bem-sucedida não foi MNT_DETACH(nenhum -lsinalizador foi usado). Apesar disso, teve sucesso quase imediatamente (é estranho). O ponto de montagem não está mais montado: mas como descrevi acima, pode ser facilmente visto que o sistema de arquivos NÃO está desmontado.

Atualização: como AB apontou, tentei verificar se o sistema de arquivos ainda está montado em um namespace diferente. Não o montei em um namespace diferente, então não esperava ver nada. Mas, surpreendentemente, ele foi montado em um namespace diferente, surpreendentemente este (nome de usuário alterado):

4026533177 mnt       1 3411291 an-unrelated-nonroot-user       xdg-dbus-proxy --args=43

Tentei entrar nesse namespace e desmontá-lo usando. nsenter -t 3411291 -m -- umount /the/mount/point
Resultou em falha de segmentação (núcleo despejado), e isso no dmesg

[970130.866738] Buffer I/O error on dev dm-2, logical block 0, lost sync page write
[970130.867925] EXT4-fs error (device dm-2): ext4_mb_release_inode_pa:4846: group 9239, free 2048, pa_free 4
[970130.870291] Buffer I/O error on dev dm-2, logical block 0, lost sync page write
[970130.949466] divide error: 0000 [#1] PREEMPT SMP PTI
[970130.950677] CPU: 49 PID: 4118804 Comm: umount Tainted: P        W  OE      6.1.68-missmika #1
[970130.953056] Hardware name: OEM X79G/X79G, BIOS 4.6.5 08/02/2022
[970130.953121] RIP: 0010:mb_update_avg_fragment_size+0x35/0x120
[970130.953121] Code: 41 54 53 4c 8b a7 98 03 00 00 41 f6 44 24 7c 80 0f 84 9a 00 00 00 8b 46 14 48 89 f3 85 c0 0f 84 8c 00 00 00 99 b9 ff ff ff ff <f7> 7e 18 0f bd c8 41 89 cd 41 83 ed 01 0f 88 ce 00 00 00 0f b6 47
[970130.957139] RSP: 0018:ffffb909e3123a28 EFLAGS: 00010202
[970130.957139] RAX: 000000000000082a RBX: ffff91140ac554d8 RCX: 00000000ffffffff
[970130.957139] RDX: 0000000000000000 RSI: ffff91140ac554d8 RDI: ffff910ead74f800
[970130.957139] RBP: ffffb909e3123a40 R08: 0000000000000000 R09: 0000000000004800
[970130.957139] R10: ffff910ead74f800 R11: ffff9114b7126000 R12: ffff910eb31d2000
[970130.957139] R13: 0000000000000007 R14: ffffb909e3123b80 R15: ffff911d732beffc
[970130.957139] FS:  00007f6d94ab4800(0000) GS:ffff911d7fcc0000(0000) knlGS:0000000000000000
[970130.957139] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[970130.957139] CR2: 00003d140602f000 CR3: 0000000365690002 CR4: 00000000001706e0
[970130.957139] Call Trace:
[970130.957139]  <TASK>
[970130.957139]  ? show_regs.cold+0x1a/0x1f
[970130.957139]  ? __die_body+0x24/0x70
[970130.957139]  ? __die+0x2f/0x3b
[970130.957139]  ? die+0x34/0x60
[970130.957139]  ? do_trap+0xdf/0x100
[970130.957139]  ? do_error_trap+0x73/0xa0
[970130.957139]  ? mb_update_avg_fragment_size+0x35/0x120
[970130.957139]  ? exc_divide_error+0x3f/0x60
[970130.957139]  ? mb_update_avg_fragment_size+0x35/0x120
[970130.957139]  ? asm_exc_divide_error+0x1f/0x30
[970130.957139]  ? mb_update_avg_fragment_size+0x35/0x120
[970130.957139]  ? mb_set_largest_free_order+0x11c/0x130
[970130.957139]  mb_free_blocks+0x24d/0x5e0
[970130.957139]  ? ext4_validate_block_bitmap.part.0+0x29/0x3e0
[970130.957139]  ? __getblk_gfp+0x33/0x3b0
[970130.957139]  ext4_mb_release_inode_pa.isra.0+0x12e/0x350
[970130.957139]  ext4_discard_preallocations+0x22e/0x490
[970130.957139]  ext4_clear_inode+0x31/0xb0
[970130.957139]  ext4_evict_inode+0xba/0x750
[970130.989137]  evict+0xd0/0x180
[970130.989137]  dispose_list+0x39/0x60
[970130.989137]  evict_inodes+0x18e/0x1a0
[970130.989137]  generic_shutdown_super+0x46/0x1b0
[970130.989137]  kill_block_super+0x2b/0x60
[970130.989137]  deactivate_locked_super+0x39/0x80
[970130.989137]  deactivate_super+0x46/0x50
[970130.989137]  cleanup_mnt+0x109/0x170
[970130.989137]  __cleanup_mnt+0x16/0x20
[970130.989137]  task_work_run+0x65/0xa0
[970130.989137]  exit_to_user_mode_prepare+0x152/0x170
[970130.989137]  syscall_exit_to_user_mode+0x2a/0x50
[970130.989137]  ? __x64_sys_umount+0x1a/0x30
[970130.989137]  do_syscall_64+0x6d/0x90
[970130.989137]  ? syscall_exit_to_user_mode+0x38/0x50
[970130.989137]  ? __x64_sys_newfstatat+0x22/0x30
[970130.989137]  ? do_syscall_64+0x6d/0x90
[970130.989137]  ? exit_to_user_mode_prepare+0x3d/0x170
[970130.989137]  ? syscall_exit_to_user_mode+0x38/0x50
[970130.989137]  ? __x64_sys_close+0x16/0x50
[970130.989137]  ? do_syscall_64+0x6d/0x90
[970130.989137]  ? exc_page_fault+0x8b/0x180
[970130.989137]  entry_SYSCALL_64_after_hwframe+0x64/0xce
[970130.989137] RIP: 0033:0x7f6d94925a3b
[970130.989137] Code: fb 43 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 90 f3 0f 1e fa 31 f6 e9 05 00 00 00 0f 1f 44 00 00 f3 0f 1e fa b8 a6 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 05 c3 0f 1f 40 00 48 8b 15 c1 43 0f 00 f7 d8
[970130.989137] RSP: 002b:00007ffdd60f7d08 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6
[970130.989137] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00007f6d94925a3b
[970130.989137] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000055ca1c6f7d60
[970130.989137] RBP: 000055ca1c6f7b30 R08: 0000000000000000 R09: 00007ffdd60f6a90
[970130.989137] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
[970130.989137] R13: 000055ca1c6f7d60 R14: 000055ca1c6f7c40 R15: 000055ca1c6f7b30
[970130.989137]  </TASK>
[970130.989137] Modules linked in: 88x2bu(OE) erofs dm_zero zram ext2 hfs hfsplus xfs kvdo(OE) dm_bufio mikasecfs(OE) simplefsplus(OE) melon(OE) mikatest(OE) iloveaki(OE) tls vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) ip6t_REJECT nf_reject_ipv6 ip6t_rt ipt_REJECT nf_reject_ipv4 xt_recent xt_tcpudp nft_limit xt_limit xt_addrtype xt_pkttype nft_chain_nat xt_MASQUERADE xt_nat nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nft_compat nf_tables binfmt_misc nfnetlink nvidia_uvm(POE) nvidia_drm(POE) intel_rapl_msr intel_rapl_common nvidia_modeset(POE) sb_edac nls_iso8859_1 x86_pkg_temp_thermal intel_powerclamp coretemp nvidia(POE) snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi cfg80211 joydev snd_hda_intel input_leds snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec kvm_intel snd_hda_core snd_hwdep kvm snd_pcm snd_seq_midi rapl snd_seq_midi_event snd_rawmidi intel_cstate serio_raw pcspkr snd_seq video wmi snd_seq_device snd_timer drm_kms_helper fb_sys_fops snd syscopyarea sysfillrect sysimgblt soundcore
[970130.989137]  ioatdma dca mac_hid sch_fq_codel dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua msr parport_pc ppdev lp parport drm efi_pstore ip_tables x_tables autofs4 raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid1 raid0 multipath linear crct10dif_pclmul hid_generic crc32_pclmul ghash_clmulni_intel sha512_ssse3 sha256_ssse3 sha1_ssse3 usbhid cdc_ether aesni_intel usbnet uas hid crypto_simd r8152 cryptd usb_storage mii psmouse ahci i2c_i801 r8169 lpc_ich libahci i2c_smbus realtek [last unloaded: 88x2bu(OE)]
[970131.024615] ---[ end trace 0000000000000000 ]---
[970131.203209] RIP: 0010:mb_update_avg_fragment_size+0x35/0x120
[970131.204344] Code: 41 54 53 4c 8b a7 98 03 00 00 41 f6 44 24 7c 80 0f 84 9a 00 00 00 8b 46 14 48 89 f3 85 c0 0f 84 8c 00 00 00 99 b9 ff ff ff ff <f7> 7e 18 0f bd c8 41 89 cd 41 83 ed 01 0f 88 ce 00 00 00 0f b6 47
[970131.207841] RSP: 0018:ffffb909e3123a28 EFLAGS: 00010202
[970131.209048] RAX: 000000000000082a RBX: ffff91140ac554d8 RCX: 00000000ffffffff
[970131.210284] RDX: 0000000000000000 RSI: ffff91140ac554d8 RDI: ffff910ead74f800
[970131.211512] RBP: ffffb909e3123a40 R08: 0000000000000000 R09: 0000000000004800
[970131.212749] R10: ffff910ead74f800 R11: ffff9114b7126000 R12: ffff910eb31d2000
[970131.213977] R13: 0000000000000007 R14: ffffb909e3123b80 R15: ffff911d732beffc
[970131.215181] FS:  00007f6d94ab4800(0000) GS:ffff911d7fcc0000(0000) knlGS:0000000000000000
[970131.216370] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[970131.217553] CR2: 00003d140602f000 CR3: 0000000365690002 CR4: 00000000001706e0
[970131.218740] note: umount[4118804] exited with preempt_count 1

A máquina ainda funciona, é possível sincronizar outros sistemas de arquivos:

root# sync -f /
root#

Mas não a sincronização global:

root# sync
(goes D state forever)

O cache sujo relacionado a esse sistema de arquivos fantasma não desapareceu, o sistema de arquivos ainda está "montado".
Qual pode ser a causa desses problemas?

filesystems

1 respostas

  1. Best Answer

    Isenção de responsabilidade: não posso e não vou explicar nesta resposta por que uma falha parcial do kernel foi acionada. Parece um bug do kernel, possivelmente desencadeado pelas condições de erro de E/S.

    DR

    Ter um sistema de arquivos ainda em uso pode acontecer quando um novo namespace de montagem herda um sistema de arquivos montado do namespace de montagem original, mas as configurações de propagação entre ambos não fizeram com que a desmontagem no namespace original o propagasse no novo namespace. O comando findmnt -A -o +PROPAGATIONtambém exibe o status de propagação de cada ponto de montagem visível em sua saída.

    Normalmente, isso não deveria acontecer em um ambiente systemd , porque o systemd faz /uma montagem compartilhada muito cedo (em vez do padrão do kernel private), permitindo assim que as desmontagens se propaguem dentro de seu grupo compartilhado. Portanto, eu esperaria que isso acontecesse mais facilmente em um ambiente não-systemd, ou de qualquer maneira, se uma ferramenta fosse usada explicitamente --make-privateem algumas montagens. --make-privateainda tem seu uso, especialmente para pseudo-sistemas de arquivos virtuais.

    Uma maneira de evitar que isso aconteça seria antes que um novo namespace de montagem fosse criado para alterar o ponto de montagem compartilhado com mount --make-shared ....

    Fiz um experimento para ilustrar o que acontece com montagens compartilhadas e não compartilhadas. Tentei garantir que o experimento funcionasse da mesma forma em um ambiente systemd ou não systemd.

    Experimentar

    Isso pode ser reproduzido como abaixo (alguns valores precisam /dev/loop0ser adaptados):

    # truncate -s $((2**20)) /tmp/test.raw
# mkfs.ext4 -Elazy_itable_init=0,lazy_journal_init=0 -L test /tmp/test.raw
mke2fs 1.47.0 (5-Feb-2023)

Filesystem too small for a journal
Discarding device blocks: done                            
Creating filesystem with 1024 1k blocks and 128 inodes

Allocating group tables: done                            
Writing inode tables: done                            
Writing superblocks and filesystem accounting information: done

# losetup -f --show /tmp/test.raw 
/dev/loop0
# mkdir -p /mnt/propagation/test

    Isto permitirá alterar posteriormente a propagação do experimento sem ter que alterar todo o sistema, transformando um diretório em um ponto de montagem:

    # mount --bind /mnt/propagation /mnt/propagation

    Agora, experimentos diferentes podem ter resultados diferentes.

    unshare(1)diz:

    unsharejá que o util-linux versão 2.27 define automaticamente a propagação para privateum novo namespace de montagem para garantir que o novo namespace realmente não seja compartilhado. É possível desabilitar esse recurso com a opção --propagation unchanged. Observe que esse privateé o padrão do kernel.

    Outras ferramentas podem fazer o contrário. Aqui, alteraremos o /mnt/propagationponto de montagem subjacente e sempre usaremos --propagation unchanged. Isso evita obter resultados diferentes para este experimento em sistemas não-systemd (padrão do kernel: /é privado) e systemd (padrão do systemd: /é compartilhado).

    1. comshared

      # mount --make-shared /mnt/propagation
# mount /dev/loop0 /mnt/propagation/test
# ls /mnt/propagation/test
lost+found
# cat /proc/self/mountinfo | grep /mnt/propagation/test
862 854 7:0 / /mnt/propagation/test rw,relatime shared:500 - ext4 /dev/loop0 rw

      Tenha um segundo shell (root) e cancele o compartilhamento em um novo namespace de montagem (mudarei o prompt para NMNS# para distingui-lo):

      # unshare -m --propagation unchanged --
NMNS# cat /proc/self/mountinfo | grep /mnt/propagation/test
1454 1453 7:0 / /mnt/propagation/test rw,relatime shared:500 - ext4 /dev/loop0 rw
NMNS# cd /mnt/propagation/test

      O mesmo shared:500vincula a montagem nos dois namespaces: desmontar de um irá desmontá-lo do outro.

      No shell original (no namespace de montagem original), desmonte-o:

      # umount /mnt/propagation/test
umount: /mnt/propagation/test: target is busy.

      Liberar o uso de recursos:

      NMNS# cd /

      # umount /mnt/propagation/test
#

      Desta vez funcionou.

      E observe que ele também desapareceu no novo namespace de montagem.

      NMNS# cat /proc/self/mountinfo | grep /mnt/propagation/test
NMNS#

      O kernel dmesgterá registrado que o sistema de arquivos está desmontado (em qualquer lugar), por exemplo:

      EXT4-fs (loop0): unmounting filesystem e74e0353-ace0-4eff-86ae-30e288db853e.

      Saia do shell no novo namespace de montagem para limpar.

    2. comprivate

      # mount --make-private /mnt/propagation
# mount /dev/loop0 /mnt/propagation/test
# cat /proc/self/mountinfo | grep /mnt/propagation/test
857 854 7:0 / /mnt/propagation/test rw,relatime - ext4 /dev/loop0 rw

      Não é mais compartilhado.

      Em outro lugar:

      # unshare -m --propagation unchanged --
NMNS# cat /proc/self/mountinfo | grep /mnt/propagation/test
1454 1453 7:0 / /mnt/propagation/test rw,relatime - ext4 /dev/loop0 rw
NMNS# echo $$
232529

      # umount /mnt/propagation/test
# e2fsck /dev/loop0
e2fsck 1.47.0 (5-Feb-2023)
/dev/loop0 is in use.
e2fsck: Cannot continue, aborting.



#

      O sistema de arquivos permaneceu montado no novo namespace de montagem.

      Para encontrar esse(s) namespace(s) desonesto(s) do original, pode-se executar algo assim:

      # for pid in $(lsns --noheadings -t mnt -o PID); do nsenter -t "$pid" -m -- findmnt /mnt/propagation/test && echo $pid; done
nsenter: failed to execute findmnt: No such file or directory
TARGET                SOURCE     FSTYPE OPTIONS
/mnt/propagation/test /dev/loop0 ext4   rw,relatime
232529
#

      Nota: nsenter: failed to execute findmnt: No such file or directoryaconteceu onde o namespace de montagem era para um contêiner LXC em execução e findmntnão estava disponível. O loop encontrou o PID do processo no novo namespace com o ponto de montagem (nota: em casos reais, este pode ser outro PID no mesmo namespace de montagem, não importa). Em casos extremos, seria necessário um comando dedicado capaz de alterar o namespace de montagem, verificar montagens e executar (u)montagens tudo-em-um.

      Esta montagem pode ser removida removendo o recurso de retenção restante (PID 232529), que pode ser necessário se o processo usar ativamente o sistema de arquivos montado (evitando umounto sucesso), ou desmontando-o neste namespace:

      # nsenter -t 232529 -m -- umount /mnt/propagation/test
# e2fsck /dev/loop0
e2fsck 1.47.0 (5-Feb-2023)
test: clean, 11/128 files, 58/1024 blocks
    • 3

relate perguntas