Каковы различия между журналированием HFS + и не журналированием HFS +?

41

Я собираюсь отформатировать внешний жесткий диск (HDD).

Каковы основные различия между журналированием HFS + и не журналированием HFS +? Помимо того, что у одного есть журналирование, а у другого нет, как это влияет на производительность диска (с цифрами)?

У меня такое ощущение, что при «нормальном» использовании журналирование может быть правильным, но есть ли ситуации, когда следует рассмотреть возможность не журналирования HFS +? Совместимость с Linux одна, так как кажется, что модуль ядра hfsplus поддерживает чтение и запись для HFS + без журналов, но только для чтения HFS + с журналами.

Что-нибудь еще стоит упомянуть?

Яри ​​Кейнянен
источник

Ответы:

35

У меня нет цифр для подтверждения заявления, но использование HFS + без журналирования - хорошая идея для определенных томов, требующих абсолютной скорости, не беспокоясь (слишком много) о возможной «потере данных» или «повреждении данных» в случае, если сбоя питания или аналогичного.

Когда используется HFS + Non-journeed ПЛОХАЯ идея ?

  • Внешние (USB, FW, ESata) диски, которые часто подключаются и повторно подключаются: это, как правило, плохая идея, поскольку эти накопители, как правило, очень часто случайно отключаются или их источники питания отключаются.

  • Разделы, в которых важна целостность данных и защита от неожиданной потери питания, является обязательным условием. (Документы, музыка, видео, резервные копии и т. Д.).

Когда использование HFS + Non-journeled хорошая идея ?

  • Царапина, Temp, обычное хранилище и аналогичные диски и разделы, где скорость> целостности данных в случае сбоя питания. Вы хотите, чтобы ваш царапинный том Final Cut не регистрировался (у вас все равно есть ИБП, не так ли?). Вы хотите, чтобы ваша температура в Photoshop не была записана в журнал. Диски для копирования материала (например, диск Pen, если вы позаботились о правильном извлечении).

  • Любой другой диск, который требует портативности и совместимости, как вы правильно указали.

Помните, что ведение журнала добавляет небольшие накладные расходы, но выгода в случае неправильного демонтажа тома важна не только для того, чтобы избежать «полного сканирования» диска при запуске или повторном монтировании, но также с точки зрения обеспечения того, что данные не коррумпирован в первую очередь.

Монтирование диска без журналирования, который был неправильно размонтирован, приведет к сканированию fsck , в то время как диск с журналом сможет работать и работать в течение более короткого периода времени (сканирование журнала и применение незафиксированных транзакций).

Что касается скорости и тестов, у меня нет большой информации, чтобы подтвердить вышеупомянутое утверждение, однако, насколько я знаю, разница в скорости не только очень мала и даже трудно заметна, но в некоторых случаях Журналируемая файловая система быстрее, чем не -journaled.

Оказывается, что, несмотря на издержки журнала, некоторые операции могут выполняться асинхронно на диске Journaled, тогда как версия без журнала должна выполнять действия синхронно.

Для справки я немного погуглил, пытаясь найти старое сравнение (цифры, вероятно, действительны, поскольку HFS + практически не изменился со времени их первых итераций в OSX, за исключением добавления записей данных встроенных атрибутов, а также безопасности файла списка контроля доступа и, возможно, что-то другое.

Вот сайт с диаграммами:

Сравнение HFS + с журналированием и HFS + без журналирования

TL; DR:

Последовательность копирования / дублирования / копирования файлов была одинаково быстрой как для журнализированной, так и для журнализированной HFS. Та же самая последовательность с папкой была снова несколько быстрее с журнализированной HFS

(акцент мой)

Заключение

Я несколько удивлен, увидев приведенные выше результаты, так как был несколько уверен в том, что использование Non-Journaled было действительно быстрее для некоторых операций, но, очевидно, небольшие случаи, когда это может иметь значение, перевешивают «безопасность» Journaling.

Мартин Маркончини
источник
@Griffo на самом деле это +1 на вопрос, чтобы заставить меня расследовать и прийти к вышеуказанному выводу ;-) Спасибо.
Мартин Маркончини
@ MartínMarconcini в разделе ответов «небольшие накладные расходы» отсутствуют накладные расходы с точки зрения использования дискового пространства. Например, сколько места на диске будет доступно для хранения файлов, когда ведение журнала не включено?
Pro Backup
@ProBackup Хотя у меня нет «цифр», я искренне верю, что размер журнала будет незначительным в современных дисках.
Мартин Маркончини,
@ MartínMarconcini Мне интересно, какие накладные расходы с точки зрения использования дискового пространства, потому что: (1) Большинство из этих бонусных функций добавляются пропорционально. (2) Все эти дополнительные данные складываются: 209,7 МБ для раздела EFI, еще 1,4 МБ для возможности создания 128 разделов, где требуется только 1. (3) Факт diskutil moveJournal externalсоздаст раздел Apple_Journal объемом 512 МБ. (4) На 2,7 ТБ (старый стиль 3 ТБ) используется 736 МБ ( df -h) при хранении только 1 файла (согласно sudo du /Volumes/Name).
Pro Backup
4

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

Хорошее изложение того, что делает ведение журнала, в устаревшей технической записке TN1150: HFS Plus Volume Format .

Область журнала в файловой системе записана интенсивно и вынуждает ОС регулярно выполнять жесткую синхронизацию данных. Это может помешать крупным операциям чтения и записи, которые происходят одновременно с изменением файловой системы, для которого требуются записи в журнале.

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

Для начинающих пользователей - иметь компьютер, попросить их починить диск - это не весело, что вызывает неуверенность и заставляет их немного узнать о том, как все работает. Да - это скрывает тот факт, что они могут потерять ту фотографию, которую только что загружали или двигали. На практике здравый смысл гарантирует, что даже новые пользователи дважды проверяют файл перед удалением его с камеры, когда «чертов компьютер» перезагружается в середине копирования их фотографий в iPhoto. (Скорее всего, в этот момент они обращаются за помощью в свою систему поддержки, если они даже замечают, что следующая загрузка была медленнее или это происходит чаще, чем два раза в неделю).

Для опытных пользователей, которым нужна максимальная производительность, преимущества ведения журнала начинают больше походить на штрафы за счет снижения производительности. Эти штрафы могут быть существенными, если система уже близка к емкости или требует максимальной производительности для больших устойчивых передач данных, типичных для профессионального видео или некоторых рабочих процессов базы данных.

Такие вещи являются вескими причинами для отключения ведения журнала:

  • файлы хранилища базы данных
  • избыточные машины с процедурами восстановления данных после сбоя
  • RAID-хранилище, обеспечивающее ведение журналов и многое другое
  • просто нужна дополнительная скорость независимо от стоимости
bmike
источник
Похоже, что TN1150 исчез из домена apple.com, затем издание 2004 года снова появилось в виде устаревшего документа на developer.apple.com/legacy/mac/library/#technotes/tn/… затем переместилось на developer.apple.com/legacy/ библиотека / technotes / tn / tn1150.html . Там есть ностальгически стилизованная копия издания 2004 года по адресу dubeiko.com/development/FileSystems/HFSPLUS/tn1150.html
Грэм Перрин,
RAID не заботится о тех ошибках, которые предотвращает ведение журнала. Журналирование предназначено для того, чтобы убедиться, что когда операционная система / файловая система находится в процессе обновления вашего каталога, который представляет собой сложную древовидную структуру в HFS, сбой системы или удаление диска не разрушат все ваше дерево каталогов, потенциально потеряв важные узлы ( ветки), которые даже fsck не может восстановить. RAID не предотвращает это - это только предотвращает потерю данных из-за сбоя диска, который является совершенно другим видом потери данных.
Томас Темпельманн
1

Вы могли бы взглянуть на инструменты разработчика, чтобы сравнить производительность дисков различных файловых систем, если бы вы были так склонны, здесь есть руководство:  http://developer.apple.com/library/mac/DOCUMENTATION/Performance/Conceptual/FileSystem/Articles /MacOSXAndFiles.html

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

Я тоже добавил тег файловой системы

conorgriffin
источник
+1 за ссылку для разработчиков, я склонен забывать, насколько это полезный ресурс. И невидимый +1 для ретейга ;-)
Яри ​​Кейнянен