Máquina de inicialização dupla com Ubuntu 20.04 e Windows 10 em dispositivos de armazenamento m.2 nvme separados. Tenho um disco rígido externo (14 TB) configurado como NTFS. Em qualquer sistema operacional posso gravar no disco. Porém, quando abro arquivos no HD no Windows 10, se eu gerei esses arquivos usando o Ubuntu 20.04, eles geralmente ficam corrompidos. Por exemplo:
D:\my\path> type myfile.mrc.tlt
The file or directory is corrupted and unreadable.
Já vi esse comportamento em dois discos rígidos externos (um Seagate e outro WD). Eu presumi que o problema era com a unidade Seagate. Mas agora o repliquei com um WD.
Não sei por onde começar a solução de problemas a partir daqui.
Quando monto a unidade durante a execução, journalctl -frecebo o seguinte:
Nov 05 17:12:21 axoneme udisksd[894]: Mounted /dev/sdd1 at /media/jared/Elements on behalf of uid 1000
Nov 05 17:12:21 axoneme dbus-daemon[1641]: [session uid=1000 pid=1641] Activating via systemd: service name='org.freedesktop.Tracker1' unit='tracker-store.service' requested by ':1.1' (uid=1000 pid=1637 comm="/usr/libexec/tracker-miner-fs " label="unconfined")
Nov 05 17:12:21 axoneme systemd[1629]: Starting Tracker metadata database store and lookup manager...
Nov 05 17:12:21 axoneme dbus-daemon[1641]: [session uid=1000 pid=1641] Activating service name='org.gnome.Shell.HotplugSniffer' requested by ':1.37' (uid=1000 pid=1860 comm="/usr/bin/gnome-shell " label="unconfined")
Nov 05 17:12:21 axoneme dbus-daemon[1641]: [session uid=1000 pid=1641] Successfully activated service 'org.gnome.Shell.HotplugSniffer'
Nov 05 17:12:21 axoneme dbus-daemon[1088]: [session uid=125 pid=1088] Successfully activated service 'org.freedesktop.Tracker1'
Nov 05 17:12:21 axoneme systemd[1072]: Started Tracker metadata database store and lookup manager.
Nov 05 17:12:21 axoneme dbus-daemon[1641]: [session uid=1000 pid=1641] Successfully activated service 'org.freedesktop.Tracker1'
Nov 05 17:12:21 axoneme systemd[1629]: Started Tracker metadata database store and lookup manager.
Nov 05 17:12:21 axoneme ntfs-3g[5491]: Trying to read non-allocated mft records (10255 > 9984): Illegal seek
Nov 05 17:12:21 axoneme ntfs-3g[5491]: Trying to read non-allocated mft records (10256 > 9984): Illegal seek
Nov 05 17:12:21 axoneme ntfs-3g[5491]: Trying to read non-allocated mft records (10164 > 9984): Illegal seek
Nov 05 17:12:21 axoneme ntfs-3g[5491]: Trying to read non-allocated mft records (10165 > 9984): Illegal seek
Nov 05 17:12:22 axoneme ntfs-3g[5491]: Trying to read non-allocated mft records (10009 > 9984): Illegal seek
Nov 05 17:12:22 axoneme ntfs-3g[5491]: Trying to read non-allocated mft records (10010 > 9984): Illegal seek
Nov 05 17:12:22 axoneme ntfs-3g[5491]: Trying to read non-allocated mft records (10030 > 9984): Illegal seek
Nov 05 17:12:22 axoneme ntfs-3g[5491]: Trying to read non-allocated mft records (10031 > 9984): Illegal seek
Da mesma forma, se eu executar ls -lthem um diretório no HD NTFS com Ubuntu 20.04, recebo o seguinte nos diretórios corrompidos:
Nov 05 17:16:03 axoneme ntfs-3g[5491]: Trying to read non-allocated mft records (10294 > 9984): Illegal seek
Nov 05 17:16:03 axoneme ntfs-3g[5491]: Trying to read non-allocated mft records (10290 > 9984): Illegal seek
Nov 05 17:16:03 axoneme ntfs-3g[5491]: Trying to read non-allocated mft records (10360 > 9984): Illegal seek
Responder1
Portanto, a discussão nos comentários mostrou que o problema começa a acontecer quando o Windows consegue acessar a partição NTFS. Então, é um problema do Windows? Parece provável, embora haja uma chance de o driver NTFS-3G FUSE interpretar algo de maneira incorreta em comparação com o do Windows, resultando em incompatibilidade.
É interessante que este problema pareça ser extremamente raro(Encontrei apenas alguns posts com os erros exatos do Journalctl, um do ano de 2008 e outro sobre alguma interação estranha com RAID). Isso é algo a se notar, porque pode implicar que você tem alguma configuração especial que causa esses problemas, e seria muito interessante descobrir o que poderia ser. Mas deixarei isso como exercício para o leitor.
Em termos de solução alternativa, o que você pode tentar é:
Experimente o novo NTFS3driver de kernel(ao contrário do NTFS-3G que você está usando),contribuiu para o kernel pela Paragon Software desde Linux 5.15. Não deve ser confundido com o driver de kernel NTFS somente leitura mais antigo, que ainda não foi removido. Você precisará atualizar para a versão 5.15 ou superior do kernel Linux. O 5.15 parece ser usado por padrão no 22.04(e eu recomendo que você atualize 20.04 → 22.04 porque por ter um software mais antigo em seu 20.04 você está perdendo muitas otimizações e recursos).
De imediato, não sei como fazer com que os gerenciadores de arquivos usem o ntfs3 por padrão, mas você pode, por exemplo, adicionar uma
/etc/fstabentrada que faça uso do driver ntfs3.Isso pode ou não ajudar com o seu problema. Mas se isso não acontecer, tenho 97% de certeza de que isso é puramente uma falha específica do seu sistema Windows(veja também meu ponto sobre a raridade). O motivo da minha confiança é que a Paragon Software é uma empresa antiga que vende seus drivers de sistema de arquivos há muito tempo e tenho certeza de que eles tinham conhecimento e experiência prática suficientes para resolver possíveis incompatibilidades com o driver original do Windows.
Se estiver usando NTFS especificamente para compartilhar os arquivos, você também pode considerar:
- Usando o sistema de arquivos UDF. É compatível com Windows e Linux.
- Usando exfat.Desde 5.7, a SAMSUNG adicionou um driver para exfat, e elestambém lançado
exfatprogs, portanto, o suporte adequado está instalado.
PS: idealmente, você também deve tentar o ntfs-3g mais recente e, se o problema ainda for reproduzível, relate um bug. Embora você possa precisar convencer os desenvolvedores de que é realmente um problema do NTFS-3G. Se o driver NTFS3 funcionar bem para você, isso pode ser uma evidência implícita de que o problema está no driver NTFS-3G.