Машина с двойной загрузкой с Ubuntu 20.04 и Windows 10 на отдельных устройствах хранения m.2 nvme. У меня есть внешний жесткий диск (14 ТБ), настроенный как NTFS. В любой операционной системе я могу записывать на диск. Однако, когда я открываю файлы на жестком диске в Windows 10, если я создал эти файлы с помощью Ubuntu 20.04, они часто повреждаются. Например:
D:\my\path> type myfile.mrc.tlt
The file or directory is corrupted and unreadable.
Я видел такое поведение на двух внешних жестких дисках (один Seagate и другой WD). Я предполагал, что проблема в диске Seagate. Но теперь я воспроизвел ее с диском WD.
Не уверен, с чего начать устранение неполадок.
При монтировании диска во время работы journalctl -fя получаю следующее:
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
Аналогично, если я запускаю ls -lthUbuntu 20.04 в каталоге на жестком диске NTFS, я получаю следующее в поврежденных каталогах:
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
решение1
Итак, обсуждение в комментариях показало, что проблема начинает возникать, как только Windows получает доступ к разделу NTFS. Так это проблема Windows? Похоже, что да, хотя есть вероятность, что драйвер ntfs-3g FUSE интерпретирует что-то не так, как драйвер Windows, что приводит к несовместимости.
Интересно, что эта проблема встречается крайне редко.(Я нашел всего несколько сообщений с точными ошибками из journalctl, одно из них за 2008 год, а другое о каком-то странном взаимодействии с RAID). Это стоит отметить, потому что это может означать, что у вас есть какая-то особая конфигурация, которая вызывает эти проблемы, и было бы очень интересно узнать, что это может быть. Но я оставлю это в качестве упражнения для читателя.
В качестве обходного пути можно попробовать следующее:
Попробуйте новый ntfs3драйвер ядра(в отличие от ntfs-3g, который вы используете),внесен в ядро компанией Paragon Software, начиная с Linux 5.15. Не путать со старым драйвером ядра ntfs только для чтения, который до сих пор не удален. Вам нужно будет обновиться до версии ядра Linux 5.15 или выше. Похоже, что версия 5.15 используется по умолчанию в 22.04(и я рекомендую вам обновиться с 20.04 до 22.04, потому что, имея старое программное обеспечение на 20.04, вы упускаете множество оптимизаций и функций).
Навскидку, я не знаю, как заставить файловые менеджеры использовать ntfs3 по умолчанию, но вы можете, например, добавить
/etc/fstabзапись, которая использует драйвер ntfs3.Это может помочь или не помочь с вашей проблемой. Но если это не поможет, то я на 97% уверен, что это чисто ошибка конкретно вашей системы Windows(см. также мою точку зрения о редкости). Причина моей уверенности в том, что Paragon Software — старая компания, которая долгое время продавала свои драйверы файловых систем, и я почти уверен, что у них было достаточно знаний и практического опыта, чтобы устранить возможные несовместимости с оригинальным драйвером Windows.
Если вы используете NTFS специально для общего доступа к файлам, вы также можете рассмотреть следующие варианты:
- Вместо этого используется файловая система UDF. Поддерживается как Windows, так и Linux.
- Использую exfat.Начиная с версии 5.7 SAMSUNG добавил драйвер для exfat, И онитакже выпущен
exfatprogs, поэтому необходимая поддержка обеспечена.
PS: в идеале, вы также должны попробовать последнюю версию ntfs-3g, затем, если проблема все еще воспроизводится, сообщите об ошибке. Хотя вам, возможно, придется убедить разработчиков, что это действительно проблема ntfs-3g. Если драйвер ntfs3 будет работать у вас нормально, то это может быть неявным доказательством того, что проблема в драйвере ntfs-3g.