К тому же, ты говоришь о том, в чем не разбираешься.

Подскажите такой вопрос: Допустим есть пул raidz2 из 12 дисков 1tb sas 10k rpm. Скорость чтения будет x10 или x1 ?

Подскажите такой вопрос: Допустим есть пул raidz2 из 12 дисков 1tb sas 10k rpm. Скорость чтения будет x10 или x1 ?

от х1 до х10. как повезет

Подскажите такой вопрос: Допустим есть пул raidz2 из 12 дисков 1tb sas 10k rpm. Скорость чтения будет x10 или x1 ?

Случайный доступ - х1, последовательный - до х10

Случайный доступ - х1, последовательный - до х10

+ L2ARC еще ускорит.

Smith Fisher has been banned! Reason: CAS ban.

https://wintelguy.com/zfs-calc.pl

потому что остальные тоже будут быстрее на этом железе

Покажи мне аналог slog и l2arc в других файловых системах

Покажи мне аналог slog и l2arc в других файловых системах

Disk Page Cache и отложенная запись в любом из никсов. :)

правда, там не совсем слог и требуется журналируемая ФС, но всё же.

Но про отложенную запись - лучше так не делать.

http://sylab-srv.cs.fiu.edu/lib/exe/fetch.php?media=paperclub:lkd3ch16.pdf

Disk Page Cache и отложенная запись в любом из никсов. :)

Это не тоже самое page cache работает по-другому, отложенная запись здесь ни при чём, так как slog - это всё-таки синхронная запись

а тут и синхронная, и асинхронная - и в раме, а не на диске. так что лучше так не делать. страничный кеш можешь сравнить с арком. аналога л2арка там действительно нету.

а так же FRU вроде как нету тоже.

Disk Page Cache и отложенная запись в любом из никсов. :)

Slog не равно отложенная запись в озу же

а тут и синхронная, и асинхронная - и в раме, а не на диске. так что лучше так не делать. страничный кеш можешь сравнить с арком. аналога л2арка там действительно нету.

В том и дело. Аналогов l2arc нет, аналогов slog тоже нет. Ну, есть writeback кеш на SSD в LVM, но это не то.

В том и дело. Аналогов l2arc нет, аналогов slog тоже нет. Ну, есть writeback кеш на SSD в LVM, но это не то.

+1

Slog не равно отложенная запись в озу же

естественно. :)

Bcachefs что-то пытается кешоподобное сделать но по другому и там так дёшево не обойдётся

Я тут кстати освежил changelog в памяти для 2.0, те кто жалуется на фрагментацию не бенчили ещё на своих кейсах log_spacemap?

В том и дело. Аналогов l2arc нет, аналогов slog тоже нет. Ну, есть writeback кеш на SSD в LVM, но это не то.

Хотя вру, в том же LVM есть writethrough кеш, который, думаю, можно в какой-то степени аналогом l2arc

Я имел ввиду всего лишь, что при какой-то острой необходимости ВИДИМОСТЬ, а не функционал можно сэмулировать за пределами ЗФС. Так что извините, если совсем уж чушь спорол. :D

Хотя вру, в том же LVM есть writethrough кеш, который, думаю, можно в какой-то степени аналогом l2arc

И он наверняка lru?

фру вроде никто кроме зфс и не умеет

фру вроде никто кроме зфс и не умеет

К тому и спрашиваю, ага)

И он наверняка lru?

Хуже, он просто пишет параллельно и в кеш и на основной носитель

Хуже, он просто пишет параллельно и в кеш и на основной носитель

То есть, данные туда попадают не во время чтения, а во время записи

хорошие стикеры

Это не тоже самое page cache работает по-другому, отложенная запись здесь ни при чём, так как slog - это всё-таки синхронная запись

VSAN :)

VSAN :)

Ничего про это не знаю

Ничего про это не знаю

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

но это не чисто фс конечно, это целая хранилка у вмвари

котрольные суммы есть, снапшоты есть, восстановление есть. диски можно добавлять и вынимать... но есть одно но: минимум 3 компа :)

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

Если алгоритм такой, то это получается аналог writeback кеша на SSD в LVM.

За исключением отказоустойчивости конечно

Покажи мне аналог slog и l2arc в других файловых системах

фигня в том, что через небольшое время, зфс даже с sync disabled начинает работать медленее чем ext4, при большой нагрузке. у меня дома 3 ссд по 60гб. в качестве l2arc особой погоды не делают :(

За исключением отказоустойчивости конечно

ну тут оно пишется минимум на два узла, поэтому по идее должно быть надежно. в ближайшее время, попробую собрать zfs с 1Tb ссд кеша (на чтение, на запись поставлю синк = дисаблед) посмотрим, насколько успешно оно в кеш все сложит. просто, судя по "лампочкам" на дисках, ВСАН почти не елозит по жестким дискам

Покажи мне аналог slog и l2arc в других файловых системах

Third, the ZIL, in and of itself, does not improve performance. The ZIL sits in your existing data pool by default, usually comprised of spinning disks, to log synchronous writes before being periodically flushed to their final location in storage. This means that your synchronous writes are not only operating at the speed of your storage pool, but have to be written to pool twice, sometimes more depending on your level of disk redundancy

Third, the ZIL, in and of itself, does not improve performance. The ZIL sits in your existing data pool by default, usually comprised of spinning disks, to log synchronous writes before being periodically flushed to their final location in storage. This means that your synchronous writes are not only operating at the speed of your storage pool, but have to be written to pool twice, sometimes more depending on your level of disk redundancy

Я в курсе, что такое ZIL

так к чему в споре про скорость было про него?

так к чему в споре про скорость было про него?

Потому что slog ускоряет синхронную запись

Потому что slog ускоряет синхронную запись

пока не забъется

пока не забъется

Да. Но ускоряет же

Да. Но ускоряет же

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

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

Это позволяет сгладить кратковременные пики высокой нагрузки.

Это позволяет сгладить кратковременные пики высокой нагрузки.

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

ну тут оно пишется минимум на два узла, поэтому по идее должно быть надежно. в ближайшее время, попробую собрать zfs с 1Tb ссд кеша (на чтение, на запись поставлю синк = дисаблед) посмотрим, насколько успешно оно в кеш все сложит. просто, судя по "лампочкам" на дисках, ВСАН почти не елозит по жестким дискам

И не жалко больше 100 Гб ОЗУ отдавать только на l2arc, надо же что то и arc оставить

И не жалко больше 100 Гб ОЗУ отдавать только на l2arc, надо же что то и arc оставить

Откуда такая цифра? Я посчитал, у меня получился расход ОЗУ на 1Tb l2arc около 4Gb

Откуда такая цифра? Я посчитал, у меня получился расход ОЗУ на 1Tb l2arc около 4Gb

По байту на один блок ну а дальше простая математика

Не нашел сходу точную цифру

По байту на один блок ну а дальше простая математика

70 байт на один блок. При размере блока в 16kb, расход 4Gb

1 000 000 000 000 / 16384 * 70 = 4272460937.5

Это если размер блока 16Kb, конечно. При меньшем размере, оперативки нужно будет больше, но не на столько. При размере блока 4Kb, для l2arc размером 1Тб израсходуется 16Gb RAM.

Вот данные с реальной системы # arc_summary -s l2arc ------------------------------------------------------------------------ ZFS Subsystem Report Mon Jul 12 04:23:13 2021 Linux 5.4.124-1-pve 2.0.4-pve1 Machine: fvms (x86_64) 2.0.4-pve1 L2ARC status: HEALTHY Low memory aborts: 0 Free on write: 1.8k R/W clashes: 0 Bad checksums: 0 I/O errors: 0 L2ARC size (adaptive): 2.5 TiB Compressed: 64.2 % 1.6 TiB Header size: 0.7 % 19.0 GiB L2ARC breakdown: 50.1M Hit ratio: 85.9 % 43.1M Miss ratio: 14.1 % 7.1M Feeds: 862.2k L2ARC writes: Writes sent: 100 % 657.5k L2ARC evicts: Lock retries: 88 Upon reading: 0

кстати, куда делись люди, у которых зфс самая быстра....

Я приведу пример. RAID10 из 8-ми НЖМД + LVM - машины вставали колом. Перевели эти же машины на zfs и стали работать нормально. Но по тестам LVM намного быстрее. Как же так? Отвечаю, вопрос переупорядочивании записи. Запись множества мелких блоков съедала пропускную способность по iops, а zfs старается писать большими кусками. Чтение, и так было фрагментировано, даже если бы фрагментации не было, машины то разные. По этому zfs за счет упреждающего чтения и кэширования и чтение ускорило. Ну а если в эту связку подключить SSD для выноса метаданных и кэширования, была бы вообще песня, но тогда zfs только появилась на linux

Я приведу пример. RAID10 из 8-ми НЖМД + LVM - машины вставали колом. Перевели эти же машины на zfs и стали работать нормально. Но по тестам LVM намного быстрее. Как же так? Отвечаю, вопрос переупорядочивании записи. Запись множества мелких блоков съедала пропускную способность по iops, а zfs старается писать большими кусками. Чтение, и так было фрагментировано, даже если бы фрагментации не было, машины то разные. По этому zfs за счет упреждающего чтения и кэширования и чтение ускорило. Ну а если в эту связку подключить SSD для выноса метаданных и кэширования, была бы вообще песня, но тогда zfs только появилась на linux

подитожу: на зфс отключили синк (иначе как он может решать какиеми блоками писать), и да, с лвм не работал, или зфс или нормальный рейд с батарейкой

Я приведу пример. RAID10 из 8-ми НЖМД + LVM - машины вставали колом. Перевели эти же машины на zfs и стали работать нормально. Но по тестам LVM намного быстрее. Как же так? Отвечаю, вопрос переупорядочивании записи. Запись множества мелких блоков съедала пропускную способность по iops, а zfs старается писать большими кусками. Чтение, и так было фрагментировано, даже если бы фрагментации не было, машины то разные. По этому zfs за счет упреждающего чтения и кэширования и чтение ускорило. Ну а если в эту связку подключить SSD для выноса метаданных и кэширования, была бы вообще песня, но тогда zfs только появилась на linux

только зфс, на бд уфрагментирует диск в хлам за месяц, а другие фс его вообще не будут фрагментировать

внутри бд итак со временем неплохая фрагментация происходит

внутри бд итак со временем неплохая фрагментация происходит

ну для этого у нее планы обслуживания есть. у зфс их нет :(

подитожу: на зфс отключили синк (иначе как он может решать какиеми блоками писать), и да, с лвм не работал, или зфс или нормальный рейд с батарейкой

не увидел в сообщении @Riv1329 что-то про отключение синка

ну для этого у нее планы обслуживания есть. у зфс их нет :(

но фрагментация всё равно будет, не передёргивайте. Плюс LVM вам тут не поможет, а только хуже сделает

не увидел в сообщении @Riv1329 что-то про отключение синка

а как тогда она может "писать большими блоками" если она должна писать теми блоками которыми ее sync зовут? (ну да, или большими, если рекогсайз большо. толкьо пред этим прочитать то что "лишнее")

но фрагментация всё равно будет, не передёргивайте. Плюс LVM вам тут не поможет, а только хуже сделает

почему? я создал непрерывный файл 5тб, база в него пишет постоянно. как этот файл фрагментируется не на COW?

а как тогда она может "писать большими блоками" если она должна писать теми блоками которыми ее sync зовут? (ну да, или большими, если рекогсайз большо. толкьо пред этим прочитать то что "лишнее")

sync происходит в zil сначала, а потом только с txg приезжает, там нет с этим проблем

почему? я создал непрерывный файл 5тб, база в него пишет постоянно. как этот файл фрагментируется не на COW?

имхо вырожденный случай, когда сразу отдали весь диск для БД, там и ФС не особо нужна тогда

(отдали с преаллокацией файла)

обычно сразу всё пространство не отдают, тот же mysql наращивает размер файла в процессе = фрагментация самого файла на любой ФС

имхо вырожденный случай, когда сразу отдали весь диск для БД, там и ФС не особо нужна тогда

почему? то что я наблюдал, нагруженные базы обычно лежат на отдельных разделах. рост задан - 20гб за раз. т.е. да, фрагментация будет, по 20гб. сам же понимаешь, что это не фрагментация

в винде пейджфайл фиксировать рекомендовали, а чем нагруженная БД хуже?

почему? то что я наблюдал, нагруженные базы обычно лежат на отдельных разделах. рост задан - 20гб за раз. т.е. да, фрагментация будет, по 20гб. сам же понимаешь, что это не фрагментация

зависит от кейса и БД

я привёл пример выше с mysql обратный

зависит от кейса и БД

ну у нас же спор про нагруженные БД

ну у нас же спор про нагруженные БД

реализация БД критична в данном вопросе

я привёл пример выше с mysql обратный

ну с мусклем, у меня 100 мб было прописано "расти", но да, он валялся на диске с другм файлом и там фрагментился.

ну с мусклем, у меня 100 мб было прописано "расти", но да, он валялся на диске с другм файлом и там фрагментился.

да, я про общие случаи именно

реализация БД критична в данном вопросе

если отдельный диск под бд, то из тех что я знаю, они все умеют расти порциями

затюнить под БД всегда можно, упоровшись и дав ей сырой nvme к примеру)

но опять же: фрагментация не на ков будет попсовая