Как исправить «половину извлеченного» состояния неподключенного диска

У меня есть резервный диск, который я настроил, чтобы он не монтировался автоматически (через редактирование /etc/fstab )

Я использую Superduper для монтирования диска, резервного копирования на ночь, а затем размонтирования при выходе

Этим утром я открыл свой ноутбук, чтобы поехать на работу, и обнаружил, что диск находится в неактивном «наполовину извлеченном» состоянии:

Я могу щелкнуть правой кнопкой мыши и выбрать «Извлечь« Резервную копию TB »», но ничего не происходит. Я отключил ноутбук от док-станции дома и пошел на работу. Я не получил ошибок при отключении.

Сейчас я на работе, и значок все еще там в неактивном состоянии, даже если диск больше не подключен. «Изгнание» по-прежнему ничего не делает.

Я предполагаю, что это могло бы исправить себя, если я перезагружаюсь или просто повторно соединяю и устанавливаю диск, когда я возвращаюсь домой.

В данный момент диск не отображается в Дисковой утилите.

Я на Маверикс 10.9.5

Есть идеи как исправить без перезагрузки? Есть ли потенциальные проблемы, когда я перемонтирую диск сегодня вечером?

В журналах SuperDuper нет проблем:

| 03:24:02 AM | Info | PHASE: 4. And Finally...
| 03:24:02 AM | Info | ...ACTION: Scheduling TB Backup to eject when SuperDuper! quits
| 03:24:02 AM | Info | ......COMMAND => Ejecting TB Backup
| 03:24:02 AM | Info | Copy complete.

Помимо перезапуска системы, существует, вероятно, полдюжины простых, надежных и совершенно подходящих способов завершения процесса полной отладки диска, который неожиданно остановился преждевременно в момент размонтирования. У меня было две терминальные команды, которые сразу же приходили на ум, и я знаю их обе достаточно хорошо, чтобы не испытывать необходимости перепроверять страницы руководства перед тем, как печатать. Тем не менее, мой совет - разобраться с ситуацией, перезапустив систему. Позвольте ОС запустить множество проверок целостности при завершении работы и запуске, а также многоэтапных процедурах безопасности при загрузке и функциях восстановления, о которых мы даже не подозреваем. Пока я достаточно предприимчив, чтобы смонтировать образы теневого файла в ядре [ /usr/sbin/hdik ], Я полагаюсь на авторитет структуры локальной файловой системы, когда дело доходит до контроля целостности моих резервных дисков.

Кроме того, я предлагаю перед тем, как приступить к какому-либо прямому действию на диске, проверить журнал SuperDuper. Если бы что-то пошло ужасно, ужасно неправильно, SuperDuper объявил бы об этом в то время, так что это не причина, чтобы взглянуть. Я предлагаю это при странной возможности встретить подсказку об источнике сбоя.

Кроме того, рассмотреть вопрос о проверке /var/log/diskarbitrationd.log для его взятия на недавних событиях и возможности большего просвещения. (Естественно, я не буду упоминать мимолетный взгляд на содержание /etc/fstab.)

редактировать :: дополнительная информация

Две команды, которые произошли со мной, были umount * а также diskutil.

Я просмотрел документацию для umount чтобы моя память о его использовании была достаточно точной. Я столкнулся с откровением, что в течение двадцати лет или около того я пропускал раздел примечаний man-страниц, полностью цитируемый здесь:

Из-за сложного и переплетенного характера Mac OS X размонтирование может часто происходить с ошибками. Рекомендуется, чтобы diskutil (1) (как в `` diskutil unmount)   / mnt '') будет использоваться вместо этого.

Что я могу сказать? Из-за сложной и переплетенной природы моих остаточных когнитивных способностей я часто могу потерпеть неудачу

Что касается diskutil, то конкретная команда, которую я бы дал, оказалась верной: diskutil unmountDisk force [device], Вы можете обратиться к справочным страницам для полного использования вариантов и синтаксиса.

Относительно несуществования /var/log/diskarbitrationd.log: видимо, ты по глупости забыл его создать ... ох ... подожди ...

Иногда я (см. ¶ четыре выше) забываю, что тот или иной фоновый процесс, который я запускаю, не является частью установки ОС по умолчанию. Это имело место здесь с демоном сервера арбитража диска, расположенным в /usr/sbin/diskarbitrationd, Нет смысла в том, чтобы ты сейчас с этим беспокоился.

Если вы хотите и по вашему усмотрению, рассмотрите возможность использования Дисковой утилиты для проверки схемы разделов и файловой системы резервного диска. Если на устройстве существует более одного тома, что, скорее всего, не подходит для резервного диска, удерживайте нажатой клавишу Command-Command, нажимая на имя устройства вместе с именами томов с отступом под ним. Затем используйте Verify Disk на вкладке «Первая помощь», чтобы проверить диск на наличие ошибок.

﹡ Не опечатка.