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

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

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

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

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

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

ради контрольных сумм на данные сие решение?

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

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

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

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

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

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

Да.

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

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

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

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

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

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

Быстрее NTFS?

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

ntfs

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

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

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

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

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

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

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

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

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

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

Ну а для остальных оффтопиков??

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

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

шифрование

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А что с LVM?

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

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

APFS

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

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

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

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

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

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

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

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

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

Взаимно.

Без NTFS картина неполная.

На винфак!

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

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

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

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

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

cat /proc/crypto

https://openwrt.org/docs/techref/hardware/cryptographic.hardware.accelerators

https://en.wikipedia.org/wiki/AES_instruction_set

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

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

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

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

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

Какая есть.

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

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

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

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

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

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

Ext2 2 (0%)

Выходите, ретрограды!

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

Сурово.

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

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

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