это после ребута сбрасывается!

это после ребута сбрасывается!

А в каких случаях нужны такие огромные рекордсайзы и что они дают?

юзаю такой рекорд ибо файлы по 2.4мега. миллионы

Не будет ли 128к лучшем выбором? потери на контрольных суммах не значительные, а если файл 2 мега, ещё два в помойку?

Не будет ли 128к лучшем выбором? потери на контрольных суммах не значительные, а если файл 2 мега, ещё два в помойку?

так компрессия туда ж запихает еще файлов

я так понял юзается все на 100%?

Хороший диск 7500RPM дает в худшем случае 100IOPS на случайном доступе, а в лучшем 400IOPS (за один оборот, он может сделать несколько операций), с другой стороны, его линейная скорость в среднем около 100МБ/сек. А значит, что при блоках в от 128К до 1МБ, влияние фрагментации на скорость не значительное. Но зато, при чтении, и записи всегда придется считывать и записывать огромные блоки. Просто я тестировал на больших файлах и пришел к выводу, что больше 128к не имеет смысла. Во и интересуюсь, какие именно плюшки выстрелили в таком сценарии?

не стоит этим механизмом пользоваться просто так. Можно просто special раздел делать в начале диска, потом при надобности сносится slog l2arc, раздел увеличивается руками, делается autoexpand на vdev, профит

Но ручками это же удалить раздел и создать заного. В это время pool не дееспособен ?

Но ручками это же удалить раздел и создать заного. В это время pool не дееспособен ?

"удаление" раздела из таблицы разделов gpt не приводит к обнулению значений непосредственно блоков

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

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

Вот вот. Мне что-то кажется, что не растянется раздел, пока система не удалит связанное с ним блочное устройство. Я тоже не проверял, т.к. использую LVM 😊

У меня глупый вопрос: сделал я разделы под спец и слог. Но ни под какую ФС не форматирую их. Когда добавлю в пул, разделы автоматом станут zfs ? или их обязательно предварительно под что-то надо форматнуть ?

@gmelikov Поставил на ресильвер свой пул 8.92G resilvered, 0.52% done, 14:27:51 to go

кинь плиз результат потом

Соберется или нет?)

Ну и я бы не сказал что черепашья скорость scan: resilver in progress since Wed Sep 23 09:15:00 2020 2.04T scanned at 4.14G/s, 70.4G issued at 143M/s, 7.17T total 16.6G resilvered, 0.96% done, 14:27:01 to go

У меня глупый вопрос: сделал я разделы под спец и слог. Но ни под какую ФС не форматирую их. Когда добавлю в пул, разделы автоматом станут zfs ? или их обязательно предварительно под что-то надо форматнуть ?

Я ожидал худшего от SMR дисков

медленно станет после 50% где-то)

50% ресильвера?

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

Всем доброго, Вопрос. При создании zvol для виртуалки нужно указывать дополнительные параметры или достаточно по умолчания значений? ashift=13 VM - Windows guest Перерыл уже много ресурсов - ответа не нашел (

volblocksize можно по вкусу покрутить, но тут зависит от предполагаемого профиля нагрузки

volblocksize можно по вкусу покрутить, но тут зависит от предполагаемого профиля нагрузки

то есть его ставить или 8к или больше? и там уже в самой системе с этим "подставлять" я правильно понимаю?

ну он по умолчанию 8к, уменьшать точно не стоит, увеличивать без нормальных тестов - тоже

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

но, опять же, надо тестить, у меня такой статистики нет, не держу винду

нагрузка до 20 человек, офис + немного 1С файлового но много файлов и поиск по контексту )

На volblocksize 16k и ntfs unitsize=16k и быстрой SSD, 1С грузится в два раза быстрее, чем радует бухгалтеров. У меня такая разница на optane возникает.

то есть его ставить или 8к или больше? и там уже в самой системе с этим "подставлять" я правильно понимаю?

на NVME должно быть быстрей, в принципе если pool уже 8к то указав при создании zvol 16k он его override-т так?

Забыл добавить, в файловой 1С тоже размер записи 16 нужно сделать, вот так: CNVDBFL.EXE -c -f 8.3.8 -p 16k С:\<путь к файлу>\1Cv8.1CD

просто будет записывать и считывать минимум по 2 8к блоков. Но самое важное, что 1с будет работать с 16к блоками.

у них и 7.7 еще файловая.... ей это уже врядли поможет )))

там же и так всё быстро?

пока работали по сети, не очень.. сейчас перевожу на терминал ZFS + NVME )

вы по копайте в сторону recordsize у семерки. Может быть как-то так-же делается. Если накопаете, мне тоже интересно 😊

Просто ваши тесты смотришь - 300-400 Мб/с 🤔

Ещё бы atop во время теста и конфигурацию пула. Вангую, что на синхронной записи всё уперлось в slog ssd perfomance. Почему бы под эту нагрузку, требующую полностью синхронную запись, не сделать просто ssd-пул? С моей точки зрения, zfs спроектирована не для того, чтобы мерить синхронную запись. Все ухищрения с CoW и журналами, slod, special и т.д., дающие серьёзный оверхед, но позволяют опереться на writeback и безопасно* увеличить длинну очередей к дискам. При этом, случайная запись становится более линейной и многократно возрастает производиьельность. special нужен, чтобы случайная запись стала почти полностью линейной и чтобы разгрузить vdev-ы пула от случайных операций с метаданными, а slog чтобы улучшить латентность и сделать так, чтобы синхронные операции не ухудшали производительность пула для других клиентов. Эти тесты, на мой взгляд, не показывают результаты от реальной нагрузки в реальных ситуациях. По тому, что в реальности у вас будет смесь небольшого количества синхронных операций и остальные будут фактически в режиме writeback CoW, что драматически повышает быстродействие. * - безопасно, значит не разрушится при сбое, но не синхронные операции могут откатится к более раннему, но консистентному состоянию.

zfs очень хорошо подходит для СУБД и хранения образов ВМ. В этих обоих вариантах синхронная запись очень важна.

Добавил slog и special. Получил такие результаты. Мне опять кажется что мало 😄 Хотя синхронная была на уровне 4 Мб/с , а случайная вроде не изменилась. Для hdd пула большего ожидать уже нельзя ?🤔

Ещё бы atop во время теста и конфигурацию пула. Вангую, что на синхронной записи всё уперлось в slog ssd perfomance. Почему бы под эту нагрузку, требующую полностью синхронную запись, не сделать просто ssd-пул? С моей точки зрения, zfs спроектирована не для того, чтобы мерить синхронную запись. Все ухищрения с CoW и журналами, slod, special и т.д., дающие серьёзный оверхед, но позволяют опереться на writeback и безопасно* увеличить длинну очередей к дискам. При этом, случайная запись становится более линейной и многократно возрастает производиьельность. special нужен, чтобы случайная запись стала почти полностью линейной и чтобы разгрузить vdev-ы пула от случайных операций с метаданными, а slog чтобы улучшить латентность и сделать так, чтобы синхронные операции не ухудшали производительность пула для других клиентов. Эти тесты, на мой взгляд, не показывают результаты от реальной нагрузки в реальных ситуациях. По тому, что в реальности у вас будет смесь небольшого количества синхронных операций и остальные будут фактически в режиме writeback CoW, что драматически повышает быстродействие. * - безопасно, значит не разрушится при сбое, но не синхронные операции могут откатится к более раннему, но консистентному состоянию.

Подскажите, пожалуйста, что (как) именно требуется atop запускать, что показать. Я им никогда не пользовался просто.