Ещё раз, ядро в Линуксе на SBC от Андороида используется
"We are currently using a hacked-to-bits Android kernel created by Rockchip, mainline Linux does not fully support RK3588."
Vladislav
Konstantin
А безопасность от чего ? От повреждения или кражи ?
Ivan
От космического излучения
без ecc и хотяб двух дисков можно только узнать что данные побиты, но возможности это исправить не будет.
Konstantin
без ecc и хотяб двух дисков можно только узнать что данные побиты, но возможности это исправить не будет.
Люди путают защиту от повреждения с защитой от случайного обнаружения что файлы побиты
akri
без ecc и хотяб двух дисков можно только узнать что данные побиты, но возможности это исправить не будет.
Если мы рассматриваем что данные кораптятся на 1 диске
akri
Люди путают защиту от повреждения с защитой от случайного обнаружения что файлы побиты
Это в идеале
Как минимум нужно обнаружить что данные побиты
Konstantin
сделайте на примере еепром
Khajiit
От космического излучения
Ого. Это вы так куда разрабатываете: реакторы, самолеты, космос?
Для работы в условиях высокой радиации SBC в принципе подходят очень плохо, в них нет ECC-памяти, стагнирующие ядра, блобы во все поля, и никакой возможности что-то модифицировать.
Если под "защитой" вы имели ввиду чексуммы, то лучше использовать или btrfs или обычную удобную и знакомую ФС поверх dm-integrity — но такое я не эксплуатировал, только слышал
Konstantin
Язвит
Khajiit
Космос
Сурово.
На пример Ingenuity не стоит смотреть: у него условия по радиации были в разы лучше, а программа каждый раз заливалась новая перед полетом, и работала ограниченное время (десятки минут). К тому же самые радиационные места, да и вообще всю дорогу до Марса, он вообще пролетел выключенным
Тут даже сложно дать рекомендации… я бы поинтересовался у строителей кубсатов, что они использовали — если орбиты похожи
Aleksandr
Это твой вопрос в аналогичной форме
Вопрос был простой: ChatGPT говорит primarycache=metadata хорошо под виртуализацию.
В большинстве кейсов с виртуарлизацией нагрузка на ФС разная, мне стало интересно почему ИИ сделал такой вывод. Для этого я и пришел с вопросм “в профессиональное сообщество”. Единственное что я полезного отсюда подчерпнул, это то, что хоть ИИ и галюционирует иногода, но не страдает снобизмом.
akri
Сурово.
На пример Ingenuity не стоит смотреть: у него условия по радиации были в разы лучше, а программа каждый раз заливалась новая перед полетом, и работала ограниченное время (десятки минут). К тому же самые радиационные места, да и вообще всю дорогу до Марса, он вообще пролетел выключенным
Тут даже сложно дать рекомендации… я бы поинтересовался у строителей кубсатов, что они использовали — если орбиты похожи
Тяжело
Спасибо за помощь
И спасибо что отговорили от ZFS
Vladislav
Вопрос был простой: ChatGPT говорит primarycache=metadata хорошо под виртуализацию.
В большинстве кейсов с виртуарлизацией нагрузка на ФС разная, мне стало интересно почему ИИ сделал такой вывод. Для этого я и пришел с вопросм “в профессиональное сообщество”. Единственное что я полезного отсюда подчерпнул, это то, что хоть ИИ и галюционирует иногода, но не страдает снобизмом.
И сообщество вместо того, чтобы вести себя как chatgpt решило узнать "а какие условия у задачи"
Vladislav
Раз это теперь считается снобизмом, то ок
Konstantin
талон предъявил?
Konstantin
Нет.
Aleksandr
И сообщество вместо того, чтобы вести себя как chatgpt решило узнать "а какие условия у задачи"
я уже раз 7 отметил виртуализация, нагрузка смешанная
Konstantin
Но даже если виртуализация, не думаю что читаете только метаданные
Aleksandr
Но даже если виртуализация, не думаю что читаете только метаданные
так и есть, primarycache=metadata ничего хорошего не даст, ужее более менее разобрался
Aleksandr
а вот в Proxmox Backup Server надо поэксперементировать, возможно получим прирост производительности
Hennadii
Добрый день!
ChatGPT говорит primarycache=metadata хорошо под виртуализацию. Верить? нет?
primarycache=metadata хорошо под виртуализацию
сначала надо понять, что в данном случае означает слово "хорошо".
если "хорошо" - это уменьшение использования RAM под ARC - то да.
если "хорошо" - это ускорение работы с дисковой подсистемой - то нет.
для zvol в документации рекомендуется volblocksize устанавливать равным 16K, при этом внутри виртуальных машин использующих этот виртуальный диск для своих целей размер блока при работе с диском, как правило, равен 4K.
Следовательно, если виртуальная машина работает с диcком блоками размером 4K, а zvol пишет блоки размером 16К, то при частичной модификации только 4К необходимо будет прочитать весь блок 16К, изменить в нем 4К и обратно записать 16К на диск, так что при включенной компрессии эти "виртуальные" 16К на диске могут физически занимать 0К, 4К, 8К, 12К, 16К.
и если primarycache=metadata то в таком случае в ARC не будет данных и в 100% случаев их придется читать с диска.
если же primarycache=all то в таком случае в ARC могут оказаться данные и тогда read-modify-write при volblocksize=16K пройдет быстрее, потому что в некоторых случаях недостающие фрагменты данных можно будет взять прямо из ARC, без необходимости повторно читать их с диска. Если выставить volblocksize=4K тогда не будет write amplification и работы в режиме read-modify-write, но тогда и компрессия работать не будет.
исходя из этих соображений - я на серверах всегда оставляю настройку primarycache=all по умолчанию и не меняю ее на primarycache=metadata никогда, потому что не вижу разумных причин этого делать - потому что мне лучше чтобы дисковая подсистема виртуальных серверов работала быстрее, и я готов за это отдать под ARC от 8 до 64 GiB памяти сервера. А если фактически выключу использование ARC через primarycache=metadata то получу экономию памяти на гипервизоре, но ценой некоторого замедления работы виртуальных дисков виртуальных машин. А зачем мне нужна свободная память на гипервизоре, если она будет просто простаивать и не будет приносить никакой пользы? Лучше уж ее отдать под ARC и получить ускорение работы дисковой подсистемы у всех виртуальных машин.
и всегда ставлю volblocksize=16K потому что это наиболее разумный баланс, чтобы и компрессия работала и overhead от write amplification не был бы очень большим. Если надо убрать до нуля write amplification - то можно поставить volblocksize=4K, но тогда и компрессии вообще не будет и для RAIDZ2/RAIDZ3 overhead будет [очень(?)] большим.
если же данные меняются очень редко и нужна максимальный уровень компрессии - то тогда и volblocksize поставить можно побольше и алгоритм компрессии изменить с lz4 на что-то с лучшим уровнем сжатия, zstd, например, или gzip.
рекомендация Limit ZFS Memory Usage выглядит разумной в плане того, меньше какого размера ARC не следует устанавливать: As a general rule of thumb, allocate at least 2 GiB Base + 1 GiB/TiB-Storage. For example, if you have a pool with 8 TiB of available storage space then you should use 10 GiB of memory for the ARC. Но если в сервере есть больше оперативной памяти и она не используется виртуальными машинами - то лучше ее всю будет отдать под ARC, тогда производительность файловой системы будет еще выше. При этом - смотреть чтобы на bare metal server / гипервизоре не вытеснялось очень много страниц в swap из RAM, чтобы не было интенсивного swap in / swap out. И разумеется, у каждой виртуальной машины должен быть свой собственный личный swap на отдельном виртуальном диске, для которого не надо делать снапшоты и не надо его бекапить. Тогда виртуальная машина будет знать, где у нее RAM, где у нее swap, и ситуации Out Of Memory будут просто невозможными, если swap у виртуальной машины делать на виртуальном диске который размещен на thin provisioned zvol - тогда swap partition может быть и 256 GiB, все равно физически на диске сервера такой виртуальный своп будет занимать очень мало места.
Hennadii
Добрый день!
ChatGPT говорит primarycache=metadata хорошо под виртуализацию. Верить? нет?
но самый точный ответ на вопрос о том, какой вариант настройки будет лучше можно получить проверив все варианты и проведя тестирование производительности, например, через fio внутри виртуальной машины/машин, так чтобы pattern нагрузки при тесте был бы максимально похож на pattern нагрузки при работе на проде.
я когда-то обнаружил, что для виртуальных машин лучше сообщать, что physical_block_size='4096' - тогда более высокая производительность при включенном ARC, чем когда physical_block_size='16384' при включенном ARC на bare metal server и файловой системой XFS внутри виртуальной машины поверх thin provisioned zvol с volblocksize=16K.
поэтому - сейчас всегда указываю для zvol виртуальных машин <blockio logical_block_size='512' physical_block_size='4096'/> и это - по результатам тестов дает наибольшую производительность при использовании файловой системы XFS внутри виртуальной машины когда ее виртуальный диск - это thin provisioned zvol, - виртуальной машине сообщается <driver name='qemu' type='raw' cache='none' io='native' discard='unmap'/> и zvol создается в режиме "sparse volume with no reservation". тогда и современные виндовсы и современные linux из виртуальных машин будут на диске bare metal сервера занимать ровно столько места, сколько данных внутри виртуальной машины, или даже меньше - благодаря включенной и работающей компрессии.
и если внутри виртуальных машин поменять ext4 на xfs, это тоже должно дать прирост производительности по причине наличия 64 allocation groups у файловой системы xfs с размером виртуального диска 64 TiB. А кроме того, как дополнительный бонус - отсутствие каталога lost+found, отсутствие лимита по inodes, и нормально работающие reflink внутри виртуальной машины. Потому что xfs умеет reflink, а ext4 не умеет. Так что не удивительно, что XFS является файловой системой по умолчанию во многих современных дистрибутивах Linux.
Станислав
ЧатГПТ вошёл в чат :)
Станислав
Вопрос был простой: ChatGPT говорит primarycache=metadata хорошо под виртуализацию.
В большинстве кейсов с виртуарлизацией нагрузка на ФС разная, мне стало интересно почему ИИ сделал такой вывод. Для этого я и пришел с вопросм “в профессиональное сообщество”. Единственное что я полезного отсюда подчерпнул, это то, что хоть ИИ и галюционирует иногода, но не страдает снобизмом.
Потому, что в администрировании, а уж тем более в использовании ZFS, ИИ всё время пургу несёт. Это же не человек, там нет логики, только копи паст с сети
Hennadii
но самый точный ответ на вопрос о том, какой вариант настройки будет лучше можно получить проверив все варианты и проведя тестирование производительности, например, через fio внутри виртуальной машины/машин, так чтобы pattern нагрузки при тесте был бы максимально похож на pattern нагрузки при работе на проде.
я когда-то обнаружил, что для виртуальных машин лучше сообщать, что physical_block_size='4096' - тогда более высокая производительность при включенном ARC, чем когда physical_block_size='16384' при включенном ARC на bare metal server и файловой системой XFS внутри виртуальной машины поверх thin provisioned zvol с volblocksize=16K.
поэтому - сейчас всегда указываю для zvol виртуальных машин <blockio logical_block_size='512' physical_block_size='4096'/> и это - по результатам тестов дает наибольшую производительность при использовании файловой системы XFS внутри виртуальной машины когда ее виртуальный диск - это thin provisioned zvol, - виртуальной машине сообщается <driver name='qemu' type='raw' cache='none' io='native' discard='unmap'/> и zvol создается в режиме "sparse volume with no reservation". тогда и современные виндовсы и современные linux из виртуальных машин будут на диске bare metal сервера занимать ровно столько места, сколько данных внутри виртуальной машины, или даже меньше - благодаря включенной и работающей компрессии.
и если внутри виртуальных машин поменять ext4 на xfs, это тоже должно дать прирост производительности по причине наличия 64 allocation groups у файловой системы xfs с размером виртуального диска 64 TiB. А кроме того, как дополнительный бонус - отсутствие каталога lost+found, отсутствие лимита по inodes, и нормально работающие reflink внутри виртуальной машины. Потому что xfs умеет reflink, а ext4 не умеет. Так что не удивительно, что XFS является файловой системой по умолчанию во многих современных дистрибутивах Linux.
...но только чтобы такой эффект экономии свободного места на диске был - надо и в xml конфиге libvirt вручную указать discard='unmap' или сразу при создании виртуальных машин передавать аргументами в /usr/bin/virt-install
--disk path={self.main_disk.zvol},format=raw,cache=none,driver.discard=unmap,blockio.logical_block_size=512,blockio.physical_block_size=4096
--disk path={self.dump_disk.zvol},format=raw,cache=none,driver.discard=unmap,blockio.logical_block_size=512,blockio.physical_block_size=4096
--disk path={self.swap_disk.zvol},format=raw,cache=none,driver.discard=unmap,blockio.logical_block_size=512,blockio.physical_block_size=4096
--disk path={self.data_disk.zvol},format=raw,cache=none,driver.discard=unmap,blockio.logical_block_size=512,blockio.physical_block_size=4096
без этого параметра discard='unmap' для QEMU работать не будет thin provisioning.
и внутри виртуальной машины - или монтировать все файловые системы xfs сразу с параметром discard в /etc/fstab, или запускать по крону время от времени fstrim -a
а лучше всего будет оба эти режима комбинировать между собой.
у меня снапшоты всех zfs датасетов делаются на bare metal сервере раз в час по крону, ровно в 00 минут.
и когда внутри виртуальной машины настроил принудительный fstrim -a по крону за пять минут до этого:
# cat /etc/cron.d/fstrim
55 * * * * root (cat /etc/cron.d/fstrim ; time fstrim -a ; echo ) 2>&1 | expand | logger -p cron.info
то заметил, что hourly снапшоты zvol и сами zvol после этого стали немного меньше по размеру в выводе zfs list
поэтому - одной только опции discard в /etc/fstab мало для файловых систем xfs / ext4 - то ли это какая ошибка в реализации discard mount option, то ли так и должно быть и только fstrim -a может освободить все неиспользуемые файловой системой блоки, в том числе и те, которых по какой-то причине не видит и не может освободить discard mount option.
и кстати, в man xfs почему-то не рекомендуют использовать discard mount option:
discard|nodiscard
Enable/disable the issuing of commands to let the block device reclaim space freed by the filesystem. This is useful for SSD devices, thinly provisioned LUNs and virtual machine images, but may have a performance impact.
Note: It is currently recommended that you use the fstrim application to discard unused blocks rather than the discard mount option because the performance impact of this option is quite severe. For this reason, nodiscard is the default.
но я все равно включаю discard для xfs / ext4 для виртуальных дисков поверх zvol, потому что "may have a performance impact" не означает, что обязательно будет место снижение производительности, но детально этот аспект не тестировал, потому что мне лучше небольшое снижение производительности виртуальной файловой системы, чем более быстрое занятие свободного места в zpool неиспользуемыми блоками виртуальных дисков.
и, кстати, аналогично и когда zpool размещается на SSD/NVMe - там тоже на выбор есть два варианта - или включить autotrim=on для zpool, или не включать и в момент наименьшей нагрузки на сервер запускать по крону задачу
/usr/sbin/zpool trim -w tank
на одном из серверов заметил, что autotrim=on вызывает очень сильную деградацию производительности, как и предупреждают об этом в man zpoolprops - что будет "significant stress on the underlying storage devices", zpool на том сервере - это mirror из двух nvme-KIOXIA_KCD81RUG7T68 - то ли от типа нагрузки это зависело, то ли в этой модели trim реализован не быстрым способом - уже не стал разбираться, просто отключил autotrim для всех zpool и включил zpool trim по крону в момент когда нагрузка на дисковую подсистему наименьшая.
И тогда стало лучше понятно, почему для свойства autotrim значение по умолчанию равно off
Hennadii
но самый точный ответ на вопрос о том, какой вариант настройки будет лучше можно получить проверив все варианты и проведя тестирование производительности, например, через fio внутри виртуальной машины/машин, так чтобы pattern нагрузки при тесте был бы максимально похож на pattern нагрузки при работе на проде.
я когда-то обнаружил, что для виртуальных машин лучше сообщать, что physical_block_size='4096' - тогда более высокая производительность при включенном ARC, чем когда physical_block_size='16384' при включенном ARC на bare metal server и файловой системой XFS внутри виртуальной машины поверх thin provisioned zvol с volblocksize=16K.
поэтому - сейчас всегда указываю для zvol виртуальных машин <blockio logical_block_size='512' physical_block_size='4096'/> и это - по результатам тестов дает наибольшую производительность при использовании файловой системы XFS внутри виртуальной машины когда ее виртуальный диск - это thin provisioned zvol, - виртуальной машине сообщается <driver name='qemu' type='raw' cache='none' io='native' discard='unmap'/> и zvol создается в режиме "sparse volume with no reservation". тогда и современные виндовсы и современные linux из виртуальных машин будут на диске bare metal сервера занимать ровно столько места, сколько данных внутри виртуальной машины, или даже меньше - благодаря включенной и работающей компрессии.
и если внутри виртуальных машин поменять ext4 на xfs, это тоже должно дать прирост производительности по причине наличия 64 allocation groups у файловой системы xfs с размером виртуального диска 64 TiB. А кроме того, как дополнительный бонус - отсутствие каталога lost+found, отсутствие лимита по inodes, и нормально работающие reflink внутри виртуальной машины. Потому что xfs умеет reflink, а ext4 не умеет. Так что не удивительно, что XFS является файловой системой по умолчанию во многих современных дистрибутивах Linux.
autotrim=on|off
When set to on space which has been recently freed, and is no longer allocated by the pool, will be periodically trimmed. This allows block device vdevs which support BLKDISCARD, such as SSDs, or file vdevs on which the underlying file system supports hole-punching, to reclaim unused blocks. The default value for this property is off.
Automatic TRIM does not immediately reclaim blocks after a free. Instead, it will optimistically delay allowing smaller ranges to be aggregated into a few larger ones. These can then be issued more efficiently to the storage. TRIM on L2ARC devices is enabled by setting l2arc_trim_ahead > 0.
Be aware that automatic trimming of recently freed data blocks can put significant stress on the underlying storage devices. This will vary depending of how well the specific device handles these commands. For lower-end devices it is often possible to achieve most of the benefits of automatic trimming by running an on-demand (manual) TRIM periodically using the zpool trim command.
и почему в man xfs не рекомендуют включать discard mount option - они это пишут, подразумевая, что в xfs форматируются физическое блочные устройства, непосредственно размещенные на NVMe/SSD, а не виртуальные диски созданные поверх zfs zvol. Не тестировал, но проседание производительности для zfs zvol должно быть небольшим, а может быть и вообще будет прирост производительности, потому что там же не сложный NVMe/SSD - в случае zvol нет причин сильно тормозить.
Хотя может быть кто-то уже проводил такие тесты - как меняется производительность при включенном и выключенном режиме discard mount option для файловой системы xfs / ext4 внутри виртуальной машины с виртуальным диском реализованным через zfs zvol?
Artem
Слушайте, а это реально не бот?
Ivan
Слушайте, а это реально не бот?
Если поискать имя-фамилию по интернетам, то можно найти сообщения в таком же стиле в догпт эпоху.
Artem
Hennadii
сообщение выглядит как оффтоп, не приветствуется.
Хамство с какой целью и по какой причине?
Хамство имеет в основе психологические причины: хамы пытаются ощутить собственную важность, уничтожая достоинство жертвы. При помощи хамства люди стараются манипулировать другими или оказывать на них давление, чтобы прийти к личной выгоде.
«Нередко такое поведение представляет собой механизм защиты, хамство бывает от страха или неуверенности, таким образом человек переносит акценты с имеющихся у него недостатков либо, наоборот, привлекает к себе внимание, пусть и неблагочестивым поведением. Хамы сами страдают от своих действий, вредя своему эмоциональному и психологическому благополучию», — говорят психологи.
Хамство может иметь открытую форму — проявляясь в грубости и насмешках, или скрытую — являясь пассивно-агрессивным поведением.
Психологическая причина хамства бывает в:
• низкой самооценке — хамство является компенсацией негативных ощущений, создает иллюзорные контроль и власть;
• эмоциональной реакции — при помощи хамства человек может снизить отрицательную энергию от какого-то события или действия, вызвавшего гнев или стресс;
• желании властвовать и контролировать — через хамское поведение демонстрируется доминирующая позиция, сила и важность;
• зависти и ревности — агрессивное поведение к жертве может проявиться, если хам ревнует или завидует, его цель — в подрыве достижений и качеств оппонента;
• недостатке эмпатии — если человеку сложно понять переживания и эмоции другого человека, он может проявить бесчувственность либо хамство;
• социокультурных факторах — среда, где пришлось расти человеку, соприкосновение его с теми или иными культурными и социальными нормами формируют поведенческие паттерны, то есть человек может хамить по привычке, он просто не знает, что взаимодействовать можно иначе.
https://t.me/ru_zfs/83104
сообщение выглядит как оффтоп, не приветствуется.
у этого чата есть FAQ ? что-то вроде такого:
https://github.com/freeseacher/metrics_ru_faq
где можно было бы почитать ответы на часто задаваемые вопросы?
Askhalion
Konstantin
Слишком заморочен для бота, скорее педант
Fedor
Выбрать, как подтвердить
Fedor
Шутки шутками, но видел в чатах ботов, которые прикидываются людьми
Sergio
Вот вам и тест Тьюринга, кожаные мешки)
Ivan
несколько фото терминала с пулом достаточно 😁
Алина был(а) забанен(а)! Причина: CAS-бан.
Mitya
Привет. Может ли дедупликация в zfs помочь в хранении трафика?
Vladislav
Привет. Может ли дедупликация в zfs помочь в хранении трафика?
zdb -S <poolname>
https://habr.com/ru/companies/vk/articles/863904/
Sergei
Всем привет!
Как определить, какой размер раздела сделать на диске бОльшего объёма, чтобы он без проблем в зеркало встал с диском, который я zfs отдал целиком?
Vladislav
Просто отдай его таким
Sergei
там 14Тб и 18Тб, жалко 4 терять
Vladislav
А что ты планируешь делать с 4тб без отказоустойчивости?
Sergei
А что ты планируешь делать с 4тб без отказоустойчивости?
не могу придумать, хотя что-то было в мыслях...
Vladislav
О том и речь, если особенно хочется можешь через fdisk -l глянуть размеры партиции
Sergei
перекину киношки, у меня 11 сейчас занято
Sergei
О том и речь, если особенно хочется можешь через fdisk -l глянуть размеры партиции
а диск + раздел, это плохие прецеденты были, или влияет на что-то?
Sergei
я понял, сам себя перемудрил...
а второй раздел под резерв на 8Мб приплюсовать в партицию?
Устр-во начало Конец Секторы Размер Тип
/dev/sda1 2048 27344746495 27344744448 12,7T Solaris /usr & Apple ZFS
/dev/sda9 27344746496 27344762879 16384 8M Solaris reserved 1
Vladislav
dd if=/dev/zero of=/path/disk1.img count=1000 bs=1M
dd if=/dev/zero of=/path/disk2.img count=2000 bs=1M
losetup /dev/loop1 /path/disk1.img
losetup /dev/loop2 /path/disk2.img
zpool create test /dev/loop1
zpool attach test /dev/loop2
Заодно проверишь заберёт ли он весь диск
LordMerlin
Кстати, в тему вопрос.
Вот есть 2шт среднего качества nvme ssd. Чтобы продлить им жизнь и поиметь хорошую скорость, размечаем их оставив в конце 20% ёмкости.
А на партициях делаем zfs raid1.
На сколько это хуже применительно к zfs чем отдать целиком диск?
Vladislav
Vladislav
Прикольней делать конечно nvme namespace
Vladislav
Ибо по логике linux тогда над этим nvme будет работать больше одного ядра
LordMerlin
Вообще без разницы
Ну, обычно когда заходит разговор про zfs откуда-то сразу появляются сакральные знания про "диск целиком" и прочее.
Vladislav
Vladislav
Для slog девайса обычно делают partition
Vladislav
Первый раз слышу)
Спасибо, пойду дакдачить))
https://habr.com/ru/companies/selectel/articles/545078/
неплохая статья для начала
Vladislav
Дефолтные консумерские диски не поддерживают больше одного namespace
LordMerlin
Так просто проще
Тут согласен.
Но вот так, автоматом, маловато сама zfs оставляет места в конце.
Я уже рассказывал, как sas Хитачи и сигейт на несколько Гб различались, а zfs что-то около 8Мб всего оставляет.
Vladislav
Vladislav
Сам по себе ZFS позволяет менять размер в рамках 2^(от 24 до 32) степени байтов