В той же txg, либо она на 100% успешно записалась, либо нет. Синхронная запись отдельно трекается журналом zil

То есть в конечном счёте поверх старого блока всё же запись идёт в какой-то момент?

А разве смысл RoW не в том, чтобы обеспечить консистентность данных на время записи на случай пропажи питания? И я тогда не совсем понимаю когда именно старый блок помечается как free

Да, смысл в RoW именно в том, что старые блоки никто не трогал и их перетрут ТОЛЬКО в будущих транзакциях. По факту zfs всегда оставляет n транзакций, каждая из которых представляет собой консистентное состояние всего пула

То есть в конечном счёте поверх старого блока всё же запись идёт в какой-то момент?

Да, но сильно в будущем и не того же блока

Т.е. Связь логического блока и физического в 100% случаев меняется на любом изменении

Да, но сильно в будущем и не того же блока

из-за этого такая фрагментация?

из-за этого такая фрагментация?

Cow подход по этой причине более подвержен фрагментации, да

Но обычные фс тоже сильно фрагментированны в обычном случае, мало какое ПО заранее резервирует всё нужное пространство

Но обычные фс тоже сильно фрагментированны в обычном случае, мало какое ПО заранее резервирует всё нужное пространство

Но можно дефрагментироапт

А у CoW это бессмысленно

Но обычные фс тоже сильно фрагментированны в обычном случае, мало какое ПО заранее резервирует всё нужное пространство

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

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

btrfs тоже например вхлам фрагментирует скачанные торрентом файлы, просто в жуткий хлам в тысячи фрагментов — как CoW

ZFS не пробовал, т.к. хз как дефрагментировать и как смотреть фрагментированность, но предполагаю, что если здоровенные блоки по мегабайту использовать, фрагментированность будет, но не смертельная как в btsfs или ext3

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

плюс у xfs в определённый момент много чего допилили, не просто же так RH её как дефолтую с определённого момента ставит

плюс у xfs в определённый момент много чего допилили, не просто же так RH её как дефолтую с определённого момента ставит

ну киллер фич типа упаковки на диске, снапшотов и подобного в ней всё равно нет )

ну киллер фич типа упаковки на диске, снапшотов и подобного в ней всё равно нет )

🙂

дедупликации жеж

дедупликации жеж

для торрентов? :))

а ну если для торрентов..то поф

ну вот опыт показывает что не поф. Я пока что бтрфс держу, немного места она таки экономит. Ну и raid0 умеет

но тогда для торрентов и снапшоты и упаковка тоже собственно нинать

а! и в бтрфс есть дефрагментаторы штатные, как файлов, так и свободного места

в отличие от :)

но тогда для торрентов и снапшоты и упаковка тоже собственно нинать

снапшоты не надо, а вот упаковка спасает — говорю же, процентов 5 экономит

иногда даже некоторые фильмы жмёт немного

ну киллер фич типа упаковки на диске, снапшотов и подобного в ней всё равно нет )

в vdo есть

в vdo есть

что такое вдо?

что такое вдо?

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/storage_administration_guide/vdo-quick-start

иногда даже некоторые фильмы жмёт немного

Э-э-э?

Э-э-э?

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

Пример можно?

плюс у xfs в определённый момент много чего допилили, не просто же так RH её как дефолтую с определённого момента ставит

Одна из киллер фич - ее абсолютная невосстанавливаемость, и хреновая живучесть в прод окружениях. Ext4 практически невозможно убить при живом диске. То что ее RHEL поставил в дефолт - это явно чей-то менеджерский заскок, примерно то же сделал Oracle в своем дистрибутиве с btrfs

но откатил когда его говном закидали

xfs крайне неудобная ФС c в прод окружениях особенно когда иногда приходится шринкать диски.

шринканье мало что любит

да, но наличие этой опции в ext4 делает ее просто незаменяемой в некоторых кейсах

есть такое дело

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/storage_administration_guide/vdo-quick-start

это лвм со сжатием? ну да, у редхаты денег милиарды, можно попилить на ненужное

vdo даже в своей мотивации где-то говорили что "нужен zfs, но хотим другую лицензию, так что вот лепим франкенштейна"

ZFS не пробовал, т.к. хз как дефрагментировать и как смотреть фрагментированность, но предполагаю, что если здоровенные блоки по мегабайту использовать, фрагментированность будет, но не смертельная как в btsfs или ext3

именно так и держу, 1% свободного места постоянно, 1МБ блоки, торренты успешно скачиваются и раздаются на моей полосе в 600мбит/c в полочку с 2 hdd в страйпе на ура

именно так и держу, 1% свободного места постоянно, 1МБ блоки, торренты успешно скачиваются и раздаются на моей полосе в 600мбит/c в полочку с 2 hdd в страйпе на ура

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

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

у меня не особо более шустрые домашние сигейты там

в ZFSине очень много тормозов из-за метаданных, имхо, если их выкинуть на special vdev - то будет очень хорошо... наверное

в ZFSине очень много тормозов из-за метаданных, имхо, если их выкинуть на special vdev - то будет очень хорошо... наверное

и еще ОЧЕНЬ МНОГО тормозов пока кеши холодные. я проводил эксперимент -- типа вычитка всех файлов с типичньго рута линукса с холодными кешами

раз в 10 медленнее ехт4 было

и еще ОЧЕНЬ МНОГО тормозов пока кеши холодные. я проводил эксперимент -- типа вычитка всех файлов с типичньго рута линукса с холодными кешами

Вычитка файлов это... шо такое?🤔

Вычитка файлов это... шо такое?🤔

time rhash -H -r ./* например

Пример можно?

первый попавшийся блюэ-рей $ ls -la 00000.m2ts -rw-r--r-- 1 abc abc 32284545024 апр 15 11:04 00000.m2ts $ zstd -zkc -T32 00000.m2ts | wc -c 31344343581

первый попавшийся блюэ-рей $ ls -la 00000.m2ts -rw-r--r-- 1 abc abc 32284545024 апр 15 11:04 00000.m2ts $ zstd -zkc -T32 00000.m2ts | wc -c 31344343581

Прикольно, сэкономили 3%, а нагрузка проца на сколько возросла? Ну и m2ts - не совсем формат для хранения

Прикольно, сэкономили 3%, а нагрузка проца на сколько возросла? Ну и m2ts - не совсем формат для хранения

Это вроде формат, в который обычно пиратят пишут тв- и спутниковые трансляции? Вряд ли он хорошо пожатым в итоге получается, отсюда zstd может дожать такое видео

time rhash -H -r ./* например

Некислая такая задачка... Блин, и что реально зфс так слил её, аж в 10 раз хужее ext4?(( Условия теста равные были?

Это вроде формат, в который обычно пиратят пишут тв- и спутниковые трансляции? Вряд ли он хорошо пожатым в итоге получается, отсюда zstd может дожать такое видео

Mpeg 2 transport stream - со спутников ловить и возможностью восстановления после потерь, если не путаю

fio \ --name RWRITE \ --rw=randwrite \ --filename=/dev/sd* \ --size=1g \ --blocksize=4k \ --iodepth=1 \ --numjobs=1 \ --direct=1 \ --randrepeat=0 \ --ioengine=libaio \ --group_reporting / Вот так можно блочный девайс затестить на случайную запись, например. Просто меняй букву в имени девайса, но только не попутай❗️ с другими дисками) В плане самого тестирования надо регулировать size, blocksize, iodepth и numjobs - к примеру я когда тестирую SSD-диски, то для начала обычно ставлю 1g, 4к, 32 и 16 соответственно - потому что так КристалДискМарк по умолчанию тестит и можно сравнивать свои результаты с обзорами в инете)

Вот что у меня вышло из тестов zpool через zvol. iostat -yv 10 1 raid-500 1.19T 1.97T 1 7.85K 18.0K 327M mirror-0 295G 165G 0 1.18K 0 35.8M gptid/00c0a656-9b41-11ed-b79d-c45444d2f933 - - 0 323 0 18.0M gptid/101deddb-bcb6-11ed-9f82-c45444d2f933 - - 0 886 0 17.9M mirror-1 266G 194G 0 2.01K 0 74.6M gptid/feb6f20f-9b40-11ed-b79d-c45444d2f933 - - 0 1.51K 0 37.3M gptid/00aa76cf-9b41-11ed-b79d-c45444d2f933 - - 0 520 0 37.3M mirror-2 247G 213G 0 1.19K 4.80K 62.9M gptid/001c4697-9b41-11ed-b79d-c45444d2f933 - - 0 645 0 31.5M gptid/00b618e9-9b41-11ed-b79d-c45444d2f933 - - 0 574 4.80K 31.5M indirect-3 - - 0 0 0 0 mirror-5 390G 538G 0 1.15K 5.60K 59.3M gptid/1d276c82-dacb-11ed-812f-c45444d2f933 - - 0 769 4.80K 29.6M gptid/1d427365-dacb-11ed-812f-c45444d2f933 - - 0 403 818 29.7M mirror-6 22.1G 906G 0 2.32K 7.59K 94.7M gptid/16389aa3-daee-11ed-812f-c45444d2f933 - - 0 1.72K 7.59K 47.3M gptid/16464c81-daee-11ed-812f-c45444d2f933 - - 0 608 0 47.4M ---------------------------------------------- ----- ----- ----- ----- ----- ----- root@truenas[/mnt/raid-500]# fio --name RWRITE --rw=randwrite --filename=/dev/zvol/raid-500/test --size=10g --blocksize=4k --iodepth=1 --numjobs=1 --direct=1 --randrepeat=0 --ioengine=posixaio --group_reporting RWRITE: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=posixaio, iodepth=1 fio-3.28 Starting 1 process Jobs: 1 (f=1): [f(1)][100.0%][eta 00m:00s] RWRITE: (groupid=0, jobs=1): err= 0: pid=9757: Mon Apr 17 09:20:41 2023 write: IOPS=18.0k, BW=70.5MiB/s (73.9MB/s)(10.0GiB/145252msec); 0 zone resets slat (usec): min=9, max=1824, avg=52.08, stdev=152.95 clat (nsec): min=1102, max=287285, avg=1602.26, stdev=1593.49 lat (usec): min=10, max=1828, avg=53.68, stdev=153.41 clat percentiles (nsec): | 1.00th=[ 1176], 5.00th=[ 1208], 10.00th=[ 1240], 20.00th=[ 1304], | 30.00th=[ 1352], 40.00th=[ 1384], 50.00th=[ 1416], 60.00th=[ 1432], | 70.00th=[ 1464], 80.00th=[ 1512], 90.00th=[ 1656], 95.00th=[ 2288], | 99.00th=[ 4128], 99.50th=[14784], 99.90th=[16512], 99.95th=[22144], | 99.99th=[58112] bw ( KiB/s): min=19944, max=161032, per=99.94%, avg=72149.29, stdev=27800.93, samples=289 iops : min= 4986, max=40258, avg=18037.05, stdev=6950.20, samples=289 lat (usec) : 2=93.67%, 4=5.29%, 10=0.36%, 20=0.63%, 50=0.04% lat (usec) : 100=0.01%, 250=0.01%, 500=0.01% cpu : usr=6.07%, sys=48.91%, ctx=206181, majf=0, minf=1 IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0% submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% issued rwts: total=0,2621440,0,0 short=0,0,0,0 dropped=0,0,0,0 latency : target=0, window=0, percentile=100.00%, depth=1 Run status group 0 (all jobs): WRITE: bw=70.5MiB/s (73.9MB/s), 70.5MiB/s-70.5MiB/s (73.9MB/s-73.9MB/s), io=10.0GiB (10.7GB), run=145252-145252msec Убрал все slog/meta кэши. Т.к. пока что их добавление и убирание особо ничего не добавляет. Ну скорость постабильнее вышла. Судя по всему вцелом говнодиски итак неплохо выдают с кэшем в RAM.

Некислая такая задачка... Блин, и что реально зфс так слил её, аж в 10 раз хужее ext4?(( Условия теста равные были?

1. записываем тар с файлами на свежесозданную фс 2. размонтируем-примонтируем (пул для зфс), очищаем кеши ( /proc/sys/vm/drop_caches ) 3. начинаем вычитку

А CoW эту линейную в случайную потом не превращает?

Строго говоря, в zfs используется не cow (copy on write), а redirect on write - ROW получается

имхо, конечно - LOG скидывается (по умолчанию) каждые 5 секунд, по сетке 10 гигабит это не больше 5 гигабайт - ваш ЛОГ на 128 гиговых дисках будет всегда пустой на мой взгляд по ЛОГ идеально подойдуд ОПТАНы по 16 гига - они стоят пять копеек пучек но если некуда воткнуть - то можно с десяток гига откусить от диска/ов на котором лежит l2arc

У оптанов по 16Гб все же скорость и отказоустойчивость так себе. Не уверен. Но нормальные оптаны, порезанные с помощью lvm точно подойдут и под log и даже под dedup, я уже не говорю о special или cache. Под последние два можно даже sata ssd

У оптанов по 16Гб все же скорость и отказоустойчивость так себе. Не уверен. Но нормальные оптаны, порезанные с помощью lvm точно подойдут и под log и даже под dedup, я уже не говорю о special или cache. Под последние два можно даже sata ssd

Почему надёжность низкая? У них же вроде там чуть ли не x10 запас ячеек

У оптанов по 16Гб все же скорость и отказоустойчивость так себе. Не уверен. Но нормальные оптаны, порезанные с помощью lvm точно подойдут и под log и даже под dedup, я уже не говорю о special или cache. Под последние два можно даже sata ssd

16 гиговые по факту видно 12 кажется (точно не помню) - остально похоже про запас.... тут никто не спорит - если есть деньги всегда большой ОПТАН хорошо... все решает соотношение цена/плюшки но 16 гига стоит меньше 10 баксов + переходник PCIEx1 M.2 и того примерно 20 баксов чисто на LOG... а вот спешл надо избыточность не меньше пула (иначе это точка отказа) - и того скажем для RAIDZ2 - получится уже 3 оптана для моего пула (30 тера) - это по расчетам около 100 гига, то есть минимальный оптан 118 гига - стоит 100+ баксов на ебай... их надо 3 штуки, и к нем по хорошему для надо 12 свободных линий PCI-E... и того 300+ баксов и это без l2arc ибо он туда уже толком не влезет.... а оптаны по 480+ гига уже совсем не гуманно стоят, хотя да можно порезать - несколько гига на ЛОГ, сотню в тройное зеркало на СПЕШЛ, и хвосты в страйп для l2arc.... но дорого.... но кучеряво...

16 гиговые по факту видно 12 кажется (точно не помню) - остально похоже про запас.... тут никто не спорит - если есть деньги всегда большой ОПТАН хорошо... все решает соотношение цена/плюшки но 16 гига стоит меньше 10 баксов + переходник PCIEx1 M.2 и того примерно 20 баксов чисто на LOG... а вот спешл надо избыточность не меньше пула (иначе это точка отказа) - и того скажем для RAIDZ2 - получится уже 3 оптана для моего пула (30 тера) - это по расчетам около 100 гига, то есть минимальный оптан 118 гига - стоит 100+ баксов на ебай... их надо 3 штуки, и к нем по хорошему для надо 12 свободных линий PCI-E... и того 300+ баксов и это без l2arc ибо он туда уже толком не влезет.... а оптаны по 480+ гига уже совсем не гуманно стоят, хотя да можно порезать - несколько гига на ЛОГ, сотню в тройное зеркало на СПЕШЛ, и хвосты в страйп для l2arc.... но дорого.... но кучеряво...

Зачем спешл на 30 терах? Что вы на них делаете , храните домашние архивы ?🤷🏻‍♂️

иногда даже некоторые фильмы жмёт немного

Видео почти не жмется (((увы ..

Зачем спешл на 30 терах? Что вы на них делаете , храните домашние архивы ?🤷🏻‍♂️

просто что бы шевилолось быстрее (ну меня что-то типа небольшого облака для VIP-юзеров)

просто что бы шевилолось быстрее (ну меня что-то типа небольшого облака для VIP-юзеров)

Аааа ну тогда наверно да 👋я все еще никак не пойму - насколько прям быстрее может стать 🤔🤷🏻‍♂️

Аааа ну тогда наверно да 👋я все еще никак не пойму - насколько прям быстрее может стать 🤔🤷🏻‍♂️

ну я еще спешл не прицепил, только в планах (всё таки "продакш" не часто обновляется - работает не трогай) у меня последнее обновление системы было думаю в 18м году, стоит 11я сигма)... но я пока собираю инфу, собираю очередной НАС - вот он будет со спешилами и т.п....

счас всякие поиски и т.п. "очень медленно" работают - надеюсь спешл решит вопрос...

ну я еще спешл не прицепил, только в планах (всё таки "продакш" не часто обновляется - работает не трогай) у меня последнее обновление системы было думаю в 18м году, стоит 11я сигма)... но я пока собираю инфу, собираю очередной НАС - вот он будет со спешилами и т.п....

Типа мета на ssd ускорит доступ к данным на hdd ?🤔

Типа мета на ssd ускорит доступ к данным на hdd ?🤔

надеюсь - ведь сама инфа о файлах, это мета... ?

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

Видео почти не жмется (((увы ..

иногда скачанное с торрентов жмётся. А например мрз так и вообще 5-10% всегда ужимаются

иногда скачанное с торрентов жмётся. А например мрз так и вообще 5-10% всегда ужимаются

Насколько жмётся ? ))) на 1 -2 процента ? ))) стоил ли оно того 🤷🏻‍♂️

+ хвосты блоков подрезаются

Насколько жмётся ? ))) на 1 -2 процента ? ))) стоил ли оно того 🤷🏻‍♂️

выше давал пример где почти на 3 процента сжало

Насколько жмётся ? ))) на 1 -2 процента ? ))) стоил ли оно того 🤷🏻‍♂️

lz4 практически бесплатен, он умеет пропускать несжимаемое и в таком режиме по скорости близок к memcpy, если не сжалось - блок запишется как есть, на чтении пенальти не будет

lz4 практически бесплатен, он умеет пропускать несжимаемое и в таком режиме по скорости близок к memcpy, если не сжалось - блок запишется как есть, на чтении пенальти не будет

Еще какое было Могу пригласить продемонстрировать … кровь из глаз …

Еще какое было Могу пригласить продемонстрировать … кровь из глаз …

было что? если про чтение, значит ваши данные жмутся)

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

было что? если про чтение, значит ваши данные жмутся)

Чтение да.. ну что то на полпроцента там было .. не сказал бы что это «жмётся»

главное gzip ни в коем случае не ставить -- или лз4 или zstd

gzip -- мега тормоз

Чтение да.. ну что то на полпроцента там было .. не сказал бы что это «жмётся»

сейчас zfs не жмёт блок если он не сжался хотя бы на 12.5%

интересно где у вас что аффектило, но по коду это так