LINUX.ORG.RU

Какую файловую систему используете на корневом разделе?

 , ,


1

3
  1. Ext41498 (80%)

    ********************************************************************************************************************************************************************************************************************************************************************************************************************************

  2. BtrFS181 (10%)

    **************************************

  3. XFS125 (7%)

    **************************

  4. Другое92 (5%)

    *******************

  5. ZFS69 (4%)

    **************

  6. Ext344 (2%)

    *********

  7. Reiserfs37 (2%)

    *******

  8. UFS223 (1%)

    ****

  9. UFS17 (1%)

    ***

  10. Reiser415 (1%)

    ***

  11. Ext215 (1%)

    ***

  12. JFS10 (1%)

    **

  13. Hammer25 (0%)

    *

  14. NILFS2 (0%)

  15. Hammer2 (0%)

Всего голосов: 2135, всего проголосовавших: 1863

>>> Проголосовать

★★★★★

Проверено: Zhbert ()

А по теме — btrfs на всех разделах всех устройств:

  • / рабочего ноута (NVMe SSD, 1TB),
  • / домашнего сервера (NVMe SSD, 2TB),
  • /mnt/data домашнего сервера (SATA HDD, было 4x2TB/RAID5, теперь 2x16TB/RAID1).

На тех же ФС — хомяк, PostgreSQL, виртуалки с виндой. Везде поверх LUKS2, везде по одному разделу на диск (только подтома, никаких LVM и жонглирований разделами, уже забыл как страшный сон).

Полёт стабильный, вид из горящего танка отличный. Тормоз, да, а что поделать. Закидываем тормозной софт мощным железом, иопсов пока хватает.

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 3)

думал, свято был уверен, что у менЯ xfs, уже лет 5, а оказался ext4 дефолт, посмотрел. Без проблем, рекомендую

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

Ради снапшотов и RAID с контролем целостности.

Забыл дописать (точнее, не успел) — все эти ФС снапшотятся и бэкапятся borg-ом из снапшотов по расписанию. На каждой ФС единовременно по ~50-100 снапшотов (ежедневно последние 2 недели, ежечасно последние 48 часов, каждые 15 минут последние 8 часов).

Опять же, полёт нормальный.

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

звучит отлично. но реально это пригодилось? я на rsnapshot делал инкрементальный каждый час/день/неделю. так это только время отнимало, как на обслуживание (место заканчивалось, чтение логов, беспокойство перед сном), так и компьютерное. И ни разу не воспользовался. Сейчас nextcloud рабочей директории, плюс бекапы vps средствами хостера. Минимум головняка, хотя до сих пор тоже не пригодилось

И вообще, я считаю за благо избавиться от всякого старья во время какого-нибудь сбоя, накопительство и собирательство это грех. А с краткосрочными внезапными проблемами справляется регулярный ручной git push.

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

звучит отлично. но реально это пригодилось?

Да.

В первую очередь, как защита от собственной криворукости.

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

Раньше я делал бэкапы вручную по большим праздникам, и, увы, в них попало не всё, что хотелось бы сохранить.

И вообще, я считаю за благо избавиться от всякого старья во время какого-нибудь сбоя, накопительство и собирательство это грех.

По вопросам грехов, это в церковь. Комфортная жизнь — это не зазорно.

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от X512

Не приходилось запускать какие-то существенные нагрузки на оффтопике. По поводу реальной производительности NTFS в реальных задачах сказать нечего.

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

ntfs

а msys2 не из-за неё родимой ли тормозит? там все 1000% пенальти набегают

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

По вопросам грехов, это в церковь

не использовать слово грех в обиходе, дабы не получить ярлык ПГМ записал

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

Тормоз, да, а что поделать

А чем это может быть вызвано? Copy-on-write? Да, тут должен быть эффект, особенно на рандомной записи. Сжатие может подтянуть линейные операции, но с рандомом сжатие не поможет. А какие еще могут быть причины?

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

Кажется, MSYS тормозит из-за того что он MSYS. Там проще перечислить, из-за чего он не тормозит.

А как правильно сравнить производительность двух разных ФС в двух разных операционных системах? Не постгрес же на винду накатывать.

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

Хотя, ты же еще шифрование используешь. Может тут не только btrfs виновата?

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

Да чёрт его знает, я же не разработчик btrfs.

Во-первых, copy-on-write. Во-вторых, какие-то внутренние проблемы и неоптимальности именно в реализации btrfs (излишняя фрагментация, хреново написанные блокировки, тормозящие нетривиальные операции с деревом типа обхода обратных ссылок).

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

излишняя фрагментация

Это во многом следствие copy-on-wryte. И там должен быть онлайн-дефрагментатор.

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

шифрование

я dm-crypt использую чуть ли не с 2010, когда он по дефолту появился в инсталляторах - с ним нет проблем. а тогда давно на нормальном железе с аппаратной поддержкой - тоже не было(сейчас об этом не стоит и говорить)

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

А вот кстати да, под LUKS2 TPS в постгресе таки просаживается. С NOCOW практически незаметно, с COW — на ~10%. Почему, так и не понял.

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

Вряд ли это оверхед на процессоре. В современных процессорах есть аппаратное шифрование.

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

реально? никогда с cow фс дела не имел, но сквозное шифрование имел очень давно (lvm на криптованном, сверху ext4/xfs)

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

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

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

LUKS потенциально ломает некоторые оптимизации внутри btrfs, но это не точно: я плохо представляю, как устроен LUKS2. Как LVM ломает btrfs – это понимание есть. Видимо, надо считать общим правилом установку btrfs на голое железо.

По поводу компрессии. В некоторых SSD компрессия реализована внктри диска прозрачным образом. В этом случае включение компрессии на уровне ФС немного просаживает производительность.

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

LUKS потенциально ломает некоторые оптимизации внутри btrfs, но это не точно: я плохо представляю, как устроен LUKS2. Как LVM ломает btrfs – это понимание есть.

С этого места поподробнее.

По поводу компрессии. В некоторых SSD компрессия реализована внктри диска прозрачным образом. В этом случае включение компрессии на уровне ФС немного просаживает производительность.

Мне казалось, или эпоха сандфорсов уже основательно позади нас?

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

С этого места поподробнее.

Знал бы – написал. Я фактически не знаю, что есть LUKS. Это предположение.

Мне казалось, или эпоха сандфорсов уже основательно позади нас?

Мне тоже так казалось. Но разница скорости записи (в разы) сжатых и несжатых данных на некоторых SSD видеть приходилось. Никакого другого разумного объяснения я придумать не могу.

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

Знал бы – написал. Я фактически не знаю, что есть LUKS. Это предположение.

А что с LVM?

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

Тут довольно очевидно все. Выше кто-то правильно писал о проблемах с фрагментацией, они есть. При наличии жирного кэша фрагмнетацию можно свести к минимуму, увеличивая долю sequential write, и это делается. Над этим много работают. Если же под ФС есть прослойка, меняющая местами блоки на одном и том же устройстве (еще хуже – между разными физическими устройствами), то ФС фрагментацию на физическом устройстве никак не контролирует.

Если есть только одно устройство, на нем один pv, на котором, в свою очередь, один lv – проблем быть не должно. Если собран какой-нибудь lvm raid0 – то совсем худо.

i586 ()
Последнее исправление: i586 (всего исправлений: 1)
Ответ на: комментарий от intelfx

Ну, как бы напрашивается, что у них общая линия партии. На самом деле - хорошо, коль не так.

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

Мне казалось, или эпоха сандфорсов уже основательно позади нас?

Эра, не эра, но тут как бэ ЛОР.

Зентиров с Intel Pentium 4 никто не отменял. А так был у меня Intel 530 — ох же и лютый тормоз для SSD, по записи чуть ли не ноутбучный HDD напоминал. Если бы не стал глючить под линуксами, то может до сих пор бы использовал, а так отдал знакомым – у них под Windows всё отлично работает до сих пор.

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

Ты всё же преувеличиваешь. Это 1% предусмотрительности и 99% фетишизма.

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

Ты всё же преувеличиваешь. Это 1% предусмотрительности и 99% фетишизма.

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

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

Ну, продолжай отрицать очевидное, чо. Я не особенно и сомневался, что ты фанатик поехавший.

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

Я не особенно и сомневался, что ты фанатик поехавший.

Взаимно.

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

Вряд ли это оверхед на процессоре. В современных процессорах есть аппаратное шифрование.

Ну здрасьте. У тебя GPU декодирование видео в Firefox было до его реализации и отлично работало — в железе же есть, а софт там как-то сам всё сделает «вжух!».

ЗЫ: у того же Гугла с Андроид целая эпопея была по внедрению аппаратного шифрования. Этак с 4-го по 8-ой не могли нормально сделать.

fornlr ★★★★★ ()
Последнее исправление: fornlr (всего исправлений: 1)
Ответ на: комментарий от WitcherGeralt

если то не стим и медиаконтент

Стим и медиаконтент неплохо отжирают, ещё несколько софтин без установки в систему. На отдельной помойке причёсанный медиаконтент. Ну а так то QtCreator с Qt-шной шляпой и то 10 гигов кушает. Ну и для скриптов некоторые данные валяются, вроде расковыренных данных от OpenStreetMap по всему глобусу или разобранного на json-ы дампа википедии (свою службу он сослужил уже для обогащения нейронки информацией о языковых конструкциях).

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

Ты бы не говорил о чём не знаешь. AESNI в ядерный crypto фреймворк завезли примерно с самого начала.

ЗЫ: у того же Гугла с Андроид целая эпопея была по внедрению аппаратного шифрования. Этак с 4-го по 8-ой не могли нормально сделать.

Сравнил жопу с пальцем. Где AESNI, а где костыльные проприетарные крипто-движки в эмбеддеде.

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

Да, не знаю. Не утверждал что-то — просто сомнения выразил.

Сравнил жопу с пальцем

Какая есть.

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

Так в связке OpenSSL — оно и понятно. Везде же используется.

А по поводу файловой системы — это уже больше в возильную сферу.

Тут вон в линуксах дубовый FAT сколько лет медленно и неоптимально писали, и ладно…

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

у того же Гугла с Андроид целая эпопея была по внедрению аппаратного шифрования

Это очень интересно. Только при чем здесь ARM процессоры для смартфонов к десктопному рынку x86?

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

И проблемы мобильного софта мы так же не рассматриваем в данном случае.

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

шифрование. так-то btrfs раза в два медленее из-за сжатия, но вся файловая система места столько же занимает сколько бекап с нею. стоит того.

tz4678 ()

NTFS же. почему в списке нет самой популярной файловой системы?

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

В некоторых SSD компрессия реализована внктри диска прозрачным образом

То другое, там данные не жмуться, просто в одну ячейку записывается ббольшее напряжение, позволяя записывать не только 0 или 1, а так же 2 и 3. Сжатие на уровне ФС позволит запихнуть в такой SSD еще больше данных, плюс потеря скорости записи будет чуть позже за счет того, что будет чуть больше свободных ячеек.

SR_team ★★★★ ()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)