LINUX.ORG.RU

Файловая система для корня при SSD

 , , ,


2

3

Я искал информацию, конечно, просто интересно, вдруг у кого есть новый опыт и впечатление - поделитесь, пожалуйста. А что если на SSD для корня выбрать старенькую EXT2 или JFS? Или какую файловую систему вообще лучше?

На ноуте внезапное отключение питания крайне маловероятно, другие сбои тоже вряд ли случатся. Делать просто раз в сутки-двое бэкап, и скорей всего будет очень быстро и бережно для SSD. Правильно мыслю? Не нужно ведь журналирование для корня в таком случае, правда?

Забудь все те страсти, которые пишут об ssd. Используй его как обычный винчестер, на любых десктопных задачах он прослужит свои 5 лет. Если к вопросу подходить с академической точки зрения , то на ssd лучше всего подходит xfs, по причине агрессивного кэширования, отложенной записи и наличия независимых allocation groups.

King_Diamond
()

ext4 с отключенным журналом или вариант из первого комментария, который «используй как используется».

tazhate ★★★★★
()

Я примерно также думаю, в общем-то (а XFS вообще давно выбрал основной ФС после долгого вдумчивого изучения всех особенностей), но... блин, ПЕРФЕКЦИОНИЗМ! :-)

UnSavant
() автор топика
Ответ на: комментарий от King_Diamond

агрессивного кэширования

Этот миф всё никак не умрёт.

отложенной записи

Это есть и в ext4, а ещё в ней есть жизненно важная для SSD поддержка TRIM.

наличия независимых allocation groups

Ничего не значит в контексте SSD.

По теме: ext4.

GotF ★★★★★
()
Ответ на: комментарий от tazhate

TRIM же. Об этом в каждой теме про SSD жужжат :)

GotF ★★★★★
()
Ответ на: комментарий от GotF

Этот миф всё никак не умрёт.

Этот «миф» легко подтверждается в связке многопоточное чтение/запись.

Это есть и в ext4, а ещё в ней есть жизненно важная для SSD поддержка TRIM.

Уверен, что трим поддерживается FS, а не OS?

Ничего не значит в контексте SSD.

Значит. Журнал не долбится в одно место.

King_Diamond
()
Ответ на: комментарий от GotF

А я ещё сегодня натыкался на инфу о том, что SSD разбивать надо учитывая размеры каких-то страниц памяти в нём, что ли... Так ли это? Кстати, я раньше с винчестерами тоже думал, что по пластинам разбивать было бы логичнее (на каждую же отдельная головка, вроде как), но всегда лень было высчитывать.

UnSavant
() автор топика
Ответ на: комментарий от UnSavant

рекомендуется так. почему - спроси у T'so

anonymous
()
Ответ на: комментарий от King_Diamond

Этот «миф» легко подтверждается в связке многопоточное чтение/запись.\

Ну давай ссылку на бенчмарки и теорию, ладно.

Уверен, что трим поддерживается FS, а не OS?

Абсолютно.

Журнал не долбится в одно место.

Что-то не припоминаю, чтобы журнал развозило по всем группам. Где об этом написано?

GotF ★★★★★
()
Ответ на: комментарий от UnSavant

А я ещё сегодня натыкался на инфу о том, что SSD разбивать надо учитывая размеры каких-то страниц памяти в нём, что ли... Так ли это?

Скорее всего речь про выравнивание. fdisk по умолчанию всё делает как надо.

GotF ★★★★★
()
Ответ на: комментарий от King_Diamond

Журнал не долбится в одно место.

А SSD совершенно случайно не занимается постоянным перемешиванием секторов при записи как это делают все flash-накопители?

belous_k_a
()
Ответ на: комментарий от belous_k_a

А SSD совершенно случайно не занимается постоянным перемешиванием секторов при записи как это делают все flash-накопители?

Совершенно случайно занимается.

GotF ★★★★★
()
Ответ на: комментарий от GotF

Ну давай ссылку на бенчмарки и теорию, ладно.

По xfs крайне мало материалов, тем более на ядрах > 3. Я не использую бенчмарки, я сравнивал xfs и ext4 на задачах виртуализации KVM и победа xfs сокрушительна.

Абсолютно.

Ок.

Что-то не припоминаю, чтобы журнал развозило по всем группам. Где об этом написано?

В xfs свои журнал на каждый ag, в этом её сила на многопоточных задачах.

P.S. Может ты меня из игнора удалишь? а то неудобно, не вижу твоих комментов.

King_Diamond
()

ext4 или btrfs - других вариантов я не вижу.
Для себя выбрал btrfs, т.к. она 1) вполне юзабельна на данный момент и 2) производительность будет значительно улучшена в ближайшем будущем (последние новости с opennet'а).

unikum ★★★★★
()
Ответ на: комментарий от unikum

производительность будет значительно улучшена в ближайшем будущем (последние новости с opennet'а).

Сколько криво спроектированную ФС не пили, лучше не станет :3

Adjkru ★★★★★
()
Ответ на: комментарий от King_Diamond

Я не использую бенчмарки, я сравнивал xfs и ext4 на задачах виртуализации KVM и победа xfs сокрушительна.

Может быть. Видимо, сказываются допиливания, потому что на 32-ом особой разницы на большинстве задач не было.

В xfs свои журнал на каждый ag

Мне всё же хочется увидеть ссылку. Года два назад я интересовался XFS, и много читал о внутреннем устройстве, но почему-то не помню такой детали.

Может ты меня из игнора удалишь?

http://rghost.ru/37446436/image.png

а то неудобно, не вижу твоих комментов.

Если тебя кто-то игнорирует, ты видишь его комментарии.

GotF ★★★★★
()
Ответ на: комментарий от GotF

Может быть. Видимо, сказываются допиливания, потому что на 32-ом особой разницы на большинстве задач не было.

XFS стала невероятно быстра на серверных задачах.

Мне всё же хочется увидеть ссылку. Года два назад я интересовался XFS, и много читал о внутреннем устройстве, но почему-то не помню такой детали.

Вот это:

XFS filesystems are internally partitioned into allocation groups, which are equally sized linear regions within the file system. Files and directories can span allocation groups. Each allocation group manages its own inodes and free space separately, providing scalability and parallelism — multiple threads and processes can perform I/O operations on the same filesystem simultaneously.

означает не что иное, как полную логическую независимоcть allocation group, что, в свою очередь, позволяет хдд не дёргать головкой в начало (конец) диска при работа с ag.

King_Diamond
()
Ответ на: комментарий от King_Diamond

XFS filesystems are internally partitioned into allocation groups, which are equally sized linear regions within the file system. Files and directories can span allocation groups. Each allocation group manages its own inodes and free space separately, providing scalability and parallelism — multiple threads and processes can perform I/O operations on the same filesystem simultaneously.

Но журнал один. http://oss.sgi.com/projects/xfs/papers/xfs_filesystem_structure.pdf

GotF ★★★★★
()
Ответ на: комментарий от GotF

Но журнал один.

Да, почитал, согласен. Но, у xfs при одном журнале нет оверхеда, как на ext4.

King_Diamond
()
Ответ на: комментарий от Adjkru

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

unikum ★★★★★
()
Ответ на: комментарий от UnSavant

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

но головки то двигаются одновременно

teod0r ★★★★★
()
Ответ на: комментарий от Artificial_Thought

Ну это понятно. Раз они все на одной оси - быстрее дать сигнал на головки, чем крутануть их.

UnSavant
() автор топика
Ответ на: комментарий от King_Diamond

Я не использую бенчмарки, я сравнивал xfs и ext4 на задачах виртуализации KVM и победа xfs сокрушительна.

дай угадаю - использовались многогиговые образы виртуалок? ну тогда конечно xfs победит

fragment
()
Ответ на: комментарий от fragment

дай угадаю - использовались многогиговые образы виртуалок?

Да, так и есть.

King_Diamond
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.