Ext4 и прозрачное сжатие директорий

Зачем БД фс

Хм, а как вы файлики без фс читать/писать планируете? Своего демона ещё запилить?

PostgreSQL на HDD в 2024 году – это для очень сильных духом, которые ну вообще никуда не торопятся.

Почему?

Если номер прыгнул назад или чексумма не совпала — значит, запись невалидна и чтение журнала прекращается.

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

А ещё журнал конечно хорошо, но есть ещё метаданные файла в инодах и они важнее. И получается главная польза журнала в дублировании метаданных как раз для проверки целостности если есть сбой. При желании точно так же можно дублировать метаданные вне журнала, писать одну копию до, вторую после операции, проверить их по контрольным суммам и это вряд ли можно назвать атомарностью записи, но будет достигнут тот же результат. И это не КоВ и не журнал, но иллюзия атомарности будет создана.

Хм, а как вы файлики без фс читать/писать планируете?

Размещению БД на RAW-устройствах , без ФС, сто лет в обед.

А я тебе о чём говорю?

А ты говоришь что данные будут полностью нечитаемы. Но если метаданные впорядке, то читаем старый набор блоков, новый отбрасываем.

Что такое «атомизировать операцию через запись метаданных»

Выбираем какой набор блоков надо перезаписать. Из индекса ФС выбираем место размещения новой версии. Пишем новые данные туда и запоминаем в оперативку новые метаданные. Когда данные записаны физически одной короткой комадой записываем новые метаданные, ссылающиеся на новые блоки. Т.к. записть данных на порядок дольше чем перезапись метаданных - на столько же падает шанс повреждений при внезапном крахе.

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

Описанный тобой способ называется CoW

КоВ это когда ты пишешь все операции логом на непрерывную ленту, а потом читаешь всё и по этим данным собираешь итоговый результат. Ну, с той разницей что лента не непрерывная, а пачка ленточек. А у меня предыдущая копия физически исчезает по окончании операции после записи метаданных.

Вы на спичках тоже экономите?

Может быть у его оператора VPS кусачие цены на дисковое пространство? Да и спички и кошельки быват разной степени жирности, кому то и пара БелАЗов - спички.

PostgreSQL на HDD в 2024 году – это для очень сильных духом, которые ну вообще никуда не торопятся.

Почему?

ахахахахахахахахахах

Размещению БД на RAW-устройствах , без ФС, сто лет в обед.

Примеры в студию.

Вроде речь не про vps.

Размещению БД на RAW-устройствах , без ФС, сто лет в обед.

Примеры в студию.

Ну, оракел так умеет. Но мне кажется, это из времён когда FAT32 была новой прогрессивной ФС (оракловой базе скоро 50 лет стукнет!), и я сильно сомневаюсь, что в наши дни подобное даёт большой выигрыш.

PostgreSQL, к слову, без ФС не работает.

ахахахахахахахахахах

Я о вас был лучшего мнения.

ахахахахахахахахахах

Я о вас был лучшего мнения.

Очень рад за тебя.

Тем не менее, вопрос «почему PostgreSQL на HDD для тех кто не торопится» довольно странен, учитывая скорости HDD. У меня тут ынтерпрайзный WD еле-еле 250 мегабайт/с из себя выжимает на чтение и это только по праздникам и только если его погладить по головке.

оракел
PostgreSQL

Это СУБД, а не БД.

Тем не менее, вопрос «почему PostgreSQL на HDD для тех кто не торопится» довольно странен, учитывая скорости HDD. У меня тут ынтерпрайзный WD еле-еле 250 мегабайт/с из себя выжимает.

И что? Вам мало 250 метров в секунду для работы СУБД?

И что? Вам мало 250 метров в секунду для работы СУБД?

Да. Я тороплюсь.

Да. Я тороплюсь.

Или говнокодите в виде select * from … outer join … outer join…

А там не мой код крутится. Я его только запускаю.

Но это всё не важно, потому что нет смысла долбиться в HDD, когда можно поставить диск в 20 раз быстрее.

И что? Вам мало 250 метров в секунду для работы СУБД?

Ты не то меряешь, лол. Тебе важно сколько случайных операций может сделать HDD. HDD может ~200 IOPS, паршивенький SSD ~20k IOPS. HDD это как кривозубая шлюха на героине – сосет классно, но ты этому рад не будешь.

О кривозубой шлюхе он вспомнит, когда гламурное ССДисо в лучшем случае умотает к любовнику-звиздецу со всеми данными, а вхудшем будет срать некорректными данными при чистом смарте и понторезных скоростях.

у меня пока что только hdd сдыхали, ssd ещё не один, хотя первый завёлся ещё в 2012 году

О кривозубой шлюхе он вспомнит, когда гламурное ССДисо в лучшем случае умотает к любовнику-звиздецу со всеми данными, а вхудшем будет срать некорректными данными при чистом смарте и понторезных скоростях.

В лужу, статистика говорит совершенно об обратном.

Даже если нет, серверные диски всё равно в разы дороже а контора не обязательно богатая и/или крупная. Можно найти тысячи причин экономить деньги и нет ни одной чтобы покупать более дорогое железо если есть более дешёвое решение.

А ещё там вроде бы упоминался прирост скорости работы...

и я сильно сомневаюсь, что в наши дни подобное даёт большой выигрыш.

ФС в принципе не может дать выигрыша для работы БД - это лишний слой абстракции с дублированием одного и того же функционала и у разных ФС разное поведение. Но её используют для простоты, универсальности и надёжности.

ФС в принципе не может дать выигрыша для работы БД

Шта? Прикинь я собрал ZPOOL из 16 дисков – у меня БД в 16 раз быстрее работает.

Серверные ССД сейчас весьма надёжны и не просто так стоят в 5 раз дороже бюджетных китайских tlc/qlc.

Я тебе сейчас открою тайну, только тссс: tlc или qlc – это софтварная абстракция, которая настраивается контроллером. Флеш там один и тот же.

А я собирал lvm-массив с черепичнм чередованием блоков по 1М из 2 древних дисков по 80Гб и получил прирост в 2 раза на ext2 и что? Это не заслуга ФС, это заслуга массива и железа.

А я собирал lvm-массив с черепичнм чередованием блоков по 1М из 2 древних дисков по 80Гб и получил прирост в 2 раза на ext2 и что? Это не заслуга ФС, это заслуга массива и железа.

Какого массива? В ZFS все это внутри её делается. То что в лялексе у тебя есть возможность собирать софтварный рейд не означает, что эту же возможность нельзя принести в ФС (что и сделали в btrfs и bcachefs).

Там требования точности в 4 раза выше. И это не софтвенный, это железный вопрос когда из за износа одна и та же ячейка получает одну и ту же абсолютную погрешность измерения или утечку заряда.

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

Там требования точности в 4 раза выше. И это не софтвенный, это железный вопрос когда из за износа одна и та же ячейка получает одну и ту же абсолютную погрешность измерения или утечку заряда.

Не, не железный. Это тупо настройка контроллера :D

В ZFS все это внутри её делается.

А в lvm снаружи. Что это меняет? Массивы с чередованием кстати не рекомендованы для важных данных - там шанс отказа с потерей растёт по экспоненте, а без чередования при сбое одного диска файл с высокой вероятностью окажется целиком на одном устройстве и будет подлежать восстановлению.

А в lvm снаружи. Что это меняет? Массивы с чередованием кстати не рекомендованы для важных данных - там шанс отказа с потерей растёт по экспоненте, а без чередования при сбое одного диска файл с высокой вероятностью окажется целиком на одном устройстве и будет подлежать восстановлению.

RAID6 не рекомендован для важных данных? Да ты же поехал!

открою тебе еще более страшную тайну !!
у TLC и QLC еще количество записей в ячейку отличается на ~ порядок :)
физику в школе не надо было прогуливать…

у TLC и QLC еще количество записей в ячейку отличается на ~ порядок :)

А ты понимаешь почему оно различается? :)

конечно же :) я ж физику в школе хотя б не прогуливал…

конечно же :) я ж физику в школе хотя б не прогуливал…

Молодец!

Ты определись, тебе х16 скорости или надёжность? райд6 это про надёжность и он самый медленный из райдов.

Ты определись, тебе х16 скорости или надёжность? райд6 это про надёжность и он самый медленный из райдов.

В mdraid? Да. В любой адекватной кешированной реализации? Нет.

Зато нзинос ячейки - железный. И если ты прошил чип под qlc, то немного попользовавшись и словив ошибку ты не сможешь перешить его под mlc чтобы продолжить работу.

Зато нзинос ячейки - железный. И если ты прошил чип под qlc, то немного попользовавшись и словив ошибку ты не сможешь перешить его под mlc чтобы продолжить работу.

Никто этого и не утверждал.

Т.е. дело не в крутом массиве zfs, а в том, что ты прикрутил туда bcache? Одначе...

Т.е. дело не в крутом массиве zfs, а в том, что ты прикрутил туда bcache? Одначе…

Ты просто мыслишь категориями блочного лялекса.

Ну так а какой к чёрту софт, если железка сдохла и реанимации не подлежит?

А неблочного лялекса как бы не существует.

Ну так а какой к чёрту софт, если железка сдохла и реанимации не подлежит?

Речь про то, что TLC/QLC/MLC это все один и то же флеш, никакого «китайского флеша» специально для QLC нет.

А неблочного лялекса как бы не существует.

zfs, btrfs, bcachefs. Они все реализуют рейды сами, без device mapper.

Есть. Это то, что было отбракованно корейцами и тайваньцами и не пошло в серверные mlc, потом не пошло на mlc-кеш хороших десктопных ссд, а потом было забракованно в роли tlc/qlc массива в приличных дисках. Затем оно выкупается китайским подвалом, паяется к уценённому контроллеру и продаётся как топ рынка по соотношению цена/объём.

Есть. Это то, что было отбракованно корейцами и тайваньцами и не пошло в серверные mlc, потом не пошло на mlc-кеш хороших десктопных ссд, а потом было забракованно в роли tlc/qlc массива в приличных дисках. Затем оно выкупается китайским подвалом, паяется к уценённому контроллеру и продаётся как топ рынка по соотношению цена/объём.

О господи…

Они все как бы блочные ФС для блочных устройств...

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