У меня двойная загрузка Ubuntu 16.04 / MacOS El Capitan и общий раздел в формате Mac по умолчанию (HFS+). Моя двойная загрузка и разделение разделов работают хорошо, и я могу получить к нему доступ с обеих сторон.

Когда я работаю в Ubuntu и работаю над этим общим разделом (HFS+), удаленные файлы передаются в папку Ubuntu, и система теряется:

  • Я вижу файлы в папке корзины, но не могу удалить или восстановить их.
  • Когда я удаляю огромные объемы данных (я работаю с тысячами картинок), раздел автоматически отключается из моей системы Ubuntu во время процесса удаления. Чтобы получить к нему доступ, мне нужно выполнить ручной монтаж после перезапуска или переключиться на MacOS и вернуться.

Я старался:

  • удаление файлов из командной строки
  • Очистить / восстановить корзину с дисплея
  • Убить мусорный процесс в запущенных процессах

Кто-нибудь имеет представление о том, что является причиной проблемы и что я могу сделать, чтобы ее исправить?

1 ответ1

0

Во-первых, HFS+ - это не нативная файловая система с точки зрения Linux, поэтому ожидается некоторая странность. Тем не менее, полное размонтирование файловой системы при удалении файлов выходит за рамки того, что я ожидал, но может случиться так, что это, по крайней мере, часть того, что происходит. Если это так, и если ни одно из приведенных ниже предложений не поможет, переключение на FAT может помочь. Хотя FAT также не является нативным, его драйверы (как в Linux, так и в macOS) достаточно развиты, что вряд ли вызовет такие проблемы. OTOH, FAT также очень ограничен по сравнению с HFS+, поэтому он может быть неадекватным (например, если вам нужно хранить большие файлы).

В любом случае, здесь могут возникнуть некоторые конкретные проблемы:

  • Журналирование - По умолчанию, MacOS создает HFS+ томов с журнальной активными. Фактически, это значение по умолчанию нельзя отключить в последних версиях macOS при использовании Дисковой утилиты GUI. Журналирование, однако, плохо поддерживается в драйверах Linux HFS+. Таким образом, для общего раздела данных лучше отключить ведение журнала. К сожалению, я не знаю, как это сделать на существующем томе; но, может быть, поиск в Интернете что-то даст. Если нет, или если вы не против сделать жонглирование backup-reformat-restore, вы можете сделать это. Когда вы это сделаете, я бы предложил использовать mkfs.hfsplus в Linux для создания новой файловой системы. Чтобы создать файловую систему без журналирования, вы должны опустить опцию -J . (Введите man mkfs.hfsplus чтобы узнать больше об этой команде.) Если команда не установлена, вам может потребоваться установить пакет hfsprogs . Есть способ командной строки сделать это и в macOS; Я считаю, что команда newfs или что-то подобное. Я не помню детали, хотя.
  • Скоординированные идентификаторы пользователей. По умолчанию первый идентификатор пользователя (UID) в Ubuntu равен 1000, а в macOS - 501. Таким образом, когда вы пытаетесь обмениваться файлами в разделе HFS+ между этими ОС, файлы будут принадлежать разным пользователям в каждой ОС. Хотя можно свободно устанавливать разрешения или активно использовать sudo чтобы обеспечить общий доступ к файлам, лучшим решением будет согласование значений UID между двумя установками. Мой ответ на этот вопрос в AskUbuntu описывает, как это сделать в Ubuntu, и предоставляет ссылки на другие сайты, которые описывают, как это сделать в macOS. (Внесение изменений в macOS предпочтительнее, но в macOS этот процесс более утомителен.) Предлагая внести это изменение, я предполагаю, что вы можете столкнуться с проблемами разрешений и что эти проблемы взаимодействуют с ошибками файловой системы, которые приводят к отключению файловой системы.
  • Ошибки файловой системы - если файловая система была повреждена, возможно, она внезапно отключила ядро. Вы можете запустить fsck в разделе HFS+ в Linux, и это должно решить проблему, если установлен пакет hfsprogs . Apple открыла большую часть своего кода HFS+, поэтому теоретически это должно быть почти идентично выполнению проверки в macOS; тем не менее, Apple в последнее время вносит некоторые изменения в свои файловые системы, и я не знаю, попали ли эти изменения в пакеты дистрибутивов Linux, поэтому может быть безопаснее выполнять работу в macOS с помощью Disk Utility. Если Дисковая утилита дает вам возможность сделать это, не включайте журнал в разделе по причинам, указанным ранее.

Вы можете получить некоторые подсказки о том, что является причиной проблемы, посмотрев на кольцевой буфер ядра сразу после возникновения проблемы. Вы можете сделать это, набрав dmesg чтобы увидеть все, или dmesg | tail чтобы увидеть последние несколько строк. (Вы можете расширить число строк, показанных с помощью опции -n до tail , как в dmesg | tail -n 20 ; или вы можете использовать less , чем tail чтобы иметь возможность прокручивать все это.) Кольцевой буфер ядра должен записывать информацию о сбоях ядра, что является незапрошенным размонтированием файловой системы. OTOH, возможно, что то, что вызывает размонтирование, на самом деле не является отказом ядра, или сообщение об ошибке по какой-то причине не происходит. Если вы попробуете приведенные выше предложения, но они не помогут, но если кольцевой буфер ядра показывает что-то подозрительное, вы можете попробовать опубликовать детали.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .