LINUX.ORG.RU

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

 ,


1

3
  1. Ext4 1500 (80%)

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

  2. BtrFS 181 (10%)

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

  3. XFS 125 (7%)

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

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

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

  5. ZFS 69 (4%)

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

  6. Ext3 44 (2%)

    *********

  7. Reiserfs 37 (2%)

    *******

  8. UFS2 23 (1%)

    ****

  9. UFS 17 (1%)

    ***

  10. Reiser4 15 (1%)

    ***

  11. Ext2 15 (1%)

    ***

  12. JFS 10 (1%)

    **

  13. Hammer2 5 (0%)

    *

  14. NILFS 2 (0%)

  15. Hammer 2 (0%)

Всего голосов: 2137, всего проголосовавших: 1865

★★★★★

Проверено: Zhbert ()
Последнее исправление: Pinkbyte (всего исправлений: 2)

XFS как на серверах, так и на десктопе. Достаточно стабильно, присутствует CoW, предлагается моим дистрибутивом (CentOS/Fedora).

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

Всё остальное стоит в контейнерах

А если ему тесно взаимодействовать надо? Как GTK+2-приложение, например, увидит из контейнера GTK+2-тему и плагины для неё?

Ну или в ~

И как его рут оттуда увидит?

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

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

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

А это фича драйвера или ФС?

Это фича контроллера. Но сам контроллер не знает, какие данные можно дропнуть, об этом знает ФС.

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

GTK+2-приложение

Странный юзкейс. Приложения делятся на IDE (которые обычно на жабе, а не gtk) и cli.

И как его рут оттуда увидит?

Зачем руту gtk-приложения?

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

Для меня беда XFS заключается в работе delayed allocation. Я уже пару раз терял так данные. Самый драматический случай случился с заготовкой диссертации, когда ноут решил внезапно сдохнуть а система не завершила работу. Просто получил на выходе файл нулевого размера. При этом файл был сохранён и закрыт. В те времена OO не делал fsync после сейва, а старый файл перезаписывал каждый раз используя вызов trunс, вроде. Вот так вот я потерял пару дней работы.

Было это, конечно, в стародавние времена. Хотя, сейчас немного погуглив, я так и не нашел как выключить delayed allocation совсем. Похоже они так и не допилили этот функционал. А без него часть данных могут находиться в ОЗУ веками, никогда не попадая на диск.

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

Это фича контроллера

Дело контроллера — выполнять. Слать-то команду кто будет? Очевидно не ФС, это просто данные.

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

Приложения делятся на IDE (которые обычно на жабе, а не gtk) и cli.

Ясно, очередной манямирок. @vertexua ещё позовите, у которых приложения делятся на браузеры и CLI ;)

Зачем руту gtk-приложения?

Внезапно, затем, что GTK+-приложениям могут быть нужны права рута. Например, таким штукам, как gparted, или любому файловому менеджеру, чтобы лазить по системным директориям и делать там что-то, равно как и графическим текстовым редакторам, чтобы редактировать что-то в /etc.

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

Тебя в гугле забанили?

Гуглофанатики уже и до ЛОРа добрались?

https://wiki.archlinux.org/index.php/Solid_state_drive_(Русский)#TRIM

Там нет достаточно подробной информации о том, за что отвечают особенности ФС, а за что драйвер.

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

В догонку к

Всеми уважаемый (я надеюсь) дядька Товальдс наотрез отказывается эти патчи включать в vanilla без кучи бумажек подписанных чуть ли не самим Лари, и вообще вроде как не сильно высокого о ней мнения.

Я вот это имел ввиду:

https://www.zdnet.com/article/linus-torvalds-avoid-oracles-zfs-kernel-code-on-linux-until-litigious-larry-signs-off/

В кратце: «Если не хотите чтобы Oracle за вами пришёл и начал вас судить (а за ними такие грешки имеются) - то лучше не используйте. Да и нет там ничего особенного».

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

Для меня беда XFS заключается в работе delayed allocation. [… skipped …] В те времена OO не делал fsync после сейва…

Ну как бы «получите распишитесь», однозначно проблема OO, xfs здесь обвинять трудно (да и delayed allocations тоже - и без них такое могло произойти), хотя и обидно конечно. У меня уже «sync;sync;» в консоли практически рефлекс после любого хоть сколько важного изменения / сэйва. Даже трудно вспомнить с чего началось, но «береженного бог бережет». Ext4 тоже кстати delayed allocations использует.

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

однозначно проблема OO

Я в чём-то согласен. Про это поведение и XFS и EXT4 - уже было множество копий сломано в обсуждениях лет 5 назад. Высказались все кто только мог. Если что - обсуждения ещё гуглятся по запросу ext4 delayed allocation. И ситуация тут всё-таки не совсем однозначная, ИМХО.

С одной стороны, у нас есть стандарт POSIX для ФС, который в плане надежности ничего особо не гарантирует от слова совсем. С другой стороны, есть софт который рассчитывает на то что ФС сохранит файлы которые он генерирует на диск за какое-то разумное время и не потеряет их на ровном месте.

Я считаю, что тут должен быть какой-то баланс - разработчикам софта надо не забывать добавлять fsync при сохранении важных файлов, а в ФС должны быть какие-то опционально включаемые механизмы для «защиты от дурака».

В EXT4 - такие механизмы есть: опция nodelalloc выключающая отложенную аллокацию совсем, опция auto_da_alloc специально отлавливающая перезапись файлов с заменой без последующего fsync’а (она, как я понимаю, как раз и появилась по итогам обсуждений) и опция commit, гарантирующая что через указанный промежуток времени всё флюшнется и даже в самом запущенном случае данные в итоге упадут на диск.

Зато в XFS - без полного sync’а - никто ничего не гарантирует от слова совсем. Не знаю как сейчас, а тогда подобных опций монтирования в XFS не было. Данные могут не касаться диска не то что часами, а целыми днями! Причём, одни файлы он пишет почти сразу (обычно большие и однократно преаллоцированные с помощью соответствующего вызова или утилиты), другие он откладывает чуть-ли не до самого от отмонтирования, пока памяти свободной достаточно.

Кто больше прав в данной ситуации ? Я думаю что разрабы EXT4. Хотя-бы просто потому что на файловой системе ответственность выше. Софт в идеале ничего не должен знать об особенностях ФС и как она отрабатывает синки (и отрабатывает-ли вообще). Его задача высрать на диск файл и забыть о нём. Если файл важный, то сделать fsync (хотя и это не гарантия). На этом его полномочия - всё. Я как пользователь могу быть уставшим, и забыть сделать sync. Пьяный монтёр может оторвать мне в щитке фазу в любой момент времени. Вариантов много, и «крайней» тут всегда будет ФС, поэтому она должна как минимум настраиваться либо в сторону большей надежности или скорости, я так считаю.

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

Зато в XFS - ничего этого нет от слова совсем. Без полного sync’а - никто не гарантирует ничерта от слова совсем.

Они (libc/kernel/fs) должны правильно обрабатывать fsync/fdatasync, больше от них требовать ничего нельзя в этом плане. Существует несколько уровней буферизации (иначе все было бы очень и очень медленно), и до fsync/fdatasync/fclose (если вы работаете на уровне FILE* а не непосредственно на дескрипторе) даже нельзя быть уверенным что ядро вообще увидело ваши данные. Дальше хуже - даже если libc / kernel / fs / driver честно сделали свою работу данные могут сидеть в cache диска сколь угодно долго (хотя так конечно никто не делает). Поэтому и существует низкоуровневая ATA комманда FUA которая приказывает диску сбросить свой cache. Но и с ней не все так просто - если у Вас серьезный дисковый контроллер с собственным cache подпёртым батарейкой он наверняка подтвердит FUA мгновенно в предположении что даже при внезапной потере питания оно вернется в течении максимум 24-72 часов и тогда он завершит все uncommitted writes (сильно ускоряет DB-like workloads). Как то так. В общем делайте ручками sync почаще и будет вам счастье ;)

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

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

И если EXT4 может меня немного подстраховать в критической ситуации и уменьшить вероятность потери данных, то я выберу именно её. XFS, этого, увы, не может. Это не её вина, а просто особенность из-за которой я больше не выберу XFS в качестве ФС «для дома».

А то так можно вообще как Спуфинг - работать в tmpfs. Что-то забыл или не сохранился - сам дурак. Но я не готов тратить на подобное свои силы, внимание, и время. Возраст не тот уже. Хочется больше времени жить не забивая голову всем этим, а за компом просто решать поставленные задачи и париться поменьше.

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

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

;) могу понять ;)

Мы живём не в идеальном мире.

Не в бровь а в глаз, я бы сказал.

Софт, увы, часто не очень хорошо совместим с ОС или даже железом, в нём есть ошибки, и.т.д.

Я могу Вам предоставить unconditional guarantee что в любой программе сложнее «hello world» есть баги, да и «hello world» можно поставить раком (если постараться). О сложных системах / железе - вообще молчу :)

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

Там нет достаточно подробной информации о том, за что отвечают особенности ФС, а за что драйвер.

По-моему, если включить голову, то вполне очевидно, что без участия ФС эту функцию не реализовать.

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

Почему не реализовать?

Надо расчистить последовательность блоков и отдать диску команду, что её можно очистить. Этим может заниматься драйвер: по тому же принципу, по которому драйвер ext4 уменьшает фрагментацию блоков даже на ext3 без экстентов.

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

Хз почему, мб не видят NTFS и просто не голосуют. На лоре же полно виндузятников. Пруфы тут же в опросах.

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

почему sync такой дорогой потому что по нему массово даются команды опорожнить ОЗУ на диск, а это самый плохой режим для флэша

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

Снепшотить хомяка дурная затея, здесь надёжность обеспечивается raid, usp, бэкапы.

не знаю, что такое usp (Hitachi?) в разрезе хомяка, но snapshot’ом backup как раз хорошо «обеспечивается»

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

Так в том и дело, что там список ФС, а не драйверов. Посему и неясно, что и для каких ФС какие драйвера могут. В общем, тут экспериментально надо проверять, по ходу, но у Нас нет SSD ;) Либо ковыряться в исходниках драйвера.

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

При чём тут вещества?

Вы вообще в курсе, что файловыми системами ext2/ext3/ext4 в онтопике давно занимается единый драйвер ext4? Отдельные драйвера выпилены.

mertvoprog
()
Ответ на: комментарий от mertvoprog
Использование флага discard для корневого раздела с файловой системой ext3 приведёт к тому, что он будет смонтирован в режиме только-чтение.
madcore ★★★★★
()
Ответ на: комментарий от mumpster

потому что по нему массово даются команды опорожнить ОЗУ на диск, а это самый плохой режим для флэша

Не, там что то еще. Даже если тест начинается с полностью «clean state» (flush’ать нечего), серия append(~1кб)+sync проседает на sync конкретно. Так однозначно не должно быть. ПыСы: NVMe свеженький, сильно overprovisioned. Чистых блоков у него должно хватать за глаза и за уши (в смысле тереть ничего не надо)… HDD в той же ситуации делает один sync в среднем за 2 оборота, то есть даже на 7200rpm имеем порядка 3k TPS.

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

кстати, что про mdadm -W скажете?

Честно скажу - с софтварными RAID дело не имел (у нас везде железо). Но по описанию звучит как костыль - кто будет ставить в mirror разные диски? В hardware world хороший контроллер будет сабмитить random read requests на разные диски, а long sequential reads на один из.

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

не знаю, что такое usp (Hitachi?)

Я уверен, товарищ имел ввиду UPS ;)

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

Поэтому и существует низкоуровневая ATA команда FUA которая приказывает диску сбросить свой cache.

Вынужден поправиться (хотя сути это не меняет) - команда так и называется FLUSH CACHE (EXT). FUA, как я понимаю, это скорее флаг to bypass disk cache for a given write OP дабы избежать необходимости полного cache flush. Вроде как для SATA дисков в ядре соответствующую поддержку отсушили ввиду наличия регрессий. Наверное придётся таки нырнуть в сорсы дабы выяснить детали…

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

но snapshot’ом backup как раз хорошо «обеспечивается»

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

shpinog ★★★
()

BtrFS. Для всех возможных разделов. Ну, кроме UEFI, мать его за ногу с его FAT32.

Gannet ★★★
()

v

Всегда было ext4, на NixOS десктопе решил попробовать всё на ZFS, чтобы проверить защиту от bitrot. В общем работает, пришлось только ограничить ARC кэш. Ещё не работает swap-on-zfs (для hibernate), при большом memory pressure всё стаёт колом из-за дедлока где-то в драйвере FS. Всё зашифровано, и городить ещё один зашифрованный раздел спецом под swap оказалось совсем лень.

Если бы делал сейчас, наверное б сделал ext4+dm-verity+LVM

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