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

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

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

Ну или в ~

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

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

Вообще, SSD сами по себе ненадёжны, так что для них и ext4 сойдёт ;)

Не употребляем.

Да в том и беда, что это — немного…

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тебя в гугле забанили?
https://wiki.archlinux.org/index.php/Solid_state_drive_(Русский)#TRIM

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

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

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

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

В догонку к

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

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

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

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

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

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

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

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

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

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

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

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

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

Зато в 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 почаще и будет вам счастье ;)

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

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

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

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

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

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

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

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

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

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

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

Попробуй не сам и узнаешь.

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

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

Пункт «Другое» есть; что-то там не пахнет «не меньше».

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

Драйвер чего?

Файловой системы, очевидно же.

Вроде бы я тебе про это и талдычил.

Ну так и в чём конкретно препятствие?

Драйвер ФС это должен уметь, список ФС я тебе привёл, что неясного?

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

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

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

Поэтому и существует низкоуровневая ATA комманда FUA

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

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

https://cs.pikabu.ru/images/big_size_comm/2011-06_5/13086411411694.jpg

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

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

Окей, так и запишем: стабильных ФС для SSD с поддержкой Unix-прав нет.

Чиво?

Ну в NTFS их нет.

Остальное с поддержкой TRIM, стало быть — либо сырое, либо ущербное.

ну ставь линукс на NTFS. Либо вообще не ставь, но тогда не пиши сюда херни.

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

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

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

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

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

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

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

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

Так у Нас-то не SSD ;)

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

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

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

Ты забыл указать, что это ТЕБЕ не нужно.

да он даже не понимает ДЛЯ ЧЕГО нужен снимок (snapshot) при создании РК

v

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

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