LINUX.ORG.RU

Изменение размера PAGE_SIZE

 , , ,


0

3

Всем привет! есть ubuntu 18.04 ядро 4.19. возникло несколько вопросов, как можно смонтировать xfs с блоком больше чем 4к, например 64к(сформатировать получается, а смонтировать нет), то что нашел это только то что нужно пересобирать ядро и выставлять больше PAGE_SIZE? из этого вытекает другой вопрос, чем черевато увеличение PAGE_SIZE и есть какие либо подводные камни(где то прочитал что это головная боль, но развернутого ответа не было)?

PAGE_SIZE – это размер страницы виртуальной памяти, а не ФС. Этот размер фиксированный для каждой архитектуры процессора (4096 для x86).

X512 ★★★★★
()

Путаешь размер страниц в памяти, PAGE_SIZE, и размер блока\кластера ФС block или cluster size. Размер кластера вполне может быть больше размера страницы в памяти и это часто имеет практический смысл. Подробнее не скажу, так как XFS не знаю, но в ext4 это вполне себе настраиваемый параметр. А PAGE_SIZE аппаратной архитектурой определяется и унаследован от 8086. Кстати современные камни ещё в HUGEPAGES умеют, но это отдельная тема.

Jameson ★★★★★
()
Последнее исправление: Jameson (всего исправлений: 1)

В мане всё написано по этому поводу:

-b block_size_options
...
Although mkfs.xfs will accept any of these values and create a valid filesystem, XFS on Linux can only mount filesystems with pagesize or smaller blocks.

d ★★★★
()

Вообще советую забить на XFS, она под Линуксом имеет множество ограничений, не умеет сокращаться, плохо переживает «жёсткие перезагрузки». Да, бесперебойник, но всегда могут приключиться проблемы с софтом или железом приводящие к зависону. И вот тут XFS может выдать массу сюрпризов.

Хочешь промышленной мощи — ZFS, хочешь модно бежать с вейпом впереди паровоза по хипстерски подвернув штаны — btrfs, хочешь просто забыть что у тебя там за FS и не париться — ext4+lvm2.

Jameson ★★★★★
()
Ответ на: комментарий от Jameson

я как раз таки хочу использовать xfs+lvm2, так как она производительнее чем ext4 в рандоме в 3.5 раза, а в других профилях не уступает точно. нужна производительность, зфс не очень производителен, но надежен, знаю

lignumq
() автор топика
Ответ на: комментарий от Jameson

Вообще советую забить на XFS, она под Линуксом имеет множество ограничений, не умеет сокращаться, плохо переживает «жёсткие перезагрузки».

Эм… и на чём же ты предлагаешь её использовать? На IRIX?

Vsevolod-linuxoid ★★★★★
()
Ответ на: комментарий от lignumq

Ещё раз, XFS не умеет сокращаться, значит половина функционала lvm2 по управлению томами теряется.

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

Я всё таки настоятельно тебе советую не упарываться в XFS, а изучить альтернативы. Да, когда то их не было, но сейчас они есть. А XFS так и не достиг той фичастости и настраиваемости в Linux которую имел в IRIX, частично потому что на его дальнейшую разработку забили.

Jameson ★★★★★
()
Ответ на: комментарий от Jameson

Подробнее не скажу, так как XFS не знаю

Формат позволяет, но конкретно Линуксовая имплементация не умеет blockSize > PAGE_SIZE (легко гуглится). Поэтому и не монтируется.

Вообще советую забить на XFS

Не очень корректный совет. См сертификацию от RH.

Хочешь промышленной мощи — ZFS

Сильно. Очень сильно.

bugfixer ★★★★
()
Ответ на: комментарий от bugfixer

Не очень корректный совет. См сертификацию от RH.

Сертификация от RH научила её сокращаться? Да, это кажется неважным, пока не возникнет желание томами LVM поуправлять и внезапно это оказывается важным.

Сильно. Очень сильно.

Счас «они» набегут и всё подробно тебе разъяснят :) Я тоже даже не смотрю в её сторону пока она официально не в ядре, но это сугубо моё мнение, те кто набегут объяснят почему я тоже неправ :)

Jameson ★★★★★
()
Ответ на: комментарий от max_lapshin

ну блин, btrfs ещё недавно превращалась в тыкву, когда под нагрузкой на запись она заполнялась больше чем на 50%

Миллионы мух сер, миллионы мух. И им нравится. Судя по ченджлогам ядра там чуть ли не каждый второй минорный релиз что то исправляется, дополняется и улучшается, так что лично я подожду пока.

С одной стороной лично знакомые мне уважаемые люди используют её в проде под серьёзными нагрузками (не скажу какими), несмотря на то что я называл их извращенцами и призывал одуматься, и пока остаются «в бизнесе», значит она работает и надёжна. С другой стороны я всерьёз воспринимаю критику btrfs от Эдуарда Шишкина, так как он «в теме» (жену он не убивал, файловая система тоже её не убивала если что).

Jameson ★★★★★
()
Последнее исправление: Jameson (всего исправлений: 2)
Ответ на: комментарий от Jameson

Сертификация от RH научила её сокращаться?

Кмк, Вы подменяете понятия «feature-rich» и «промышленной мощи». Лично я в последнее вкладываю прежде всего надёжность, производительность и масштабируемость. То что XFS не умеет штатно «шринкаться» недостатком с практической точки зрения вовсе не является - это не тот use-case с которым Вы будете сталкиваться в производстве. Расти она точно умеет (проверяли прежде чем ввязываться).

Вообще советую забить на XFS

Не очень корректный совет. См сертификацию от RH.

Что я имел в виду - последний раз когда проверял, XFS оставалась FS с самыми большими сертифицированными RH volume sizes, и это именно то что действительно важно. На моей практике - довольно надёжна (потерь пока не было, 3 раза «тьфу»). И весьма гибка в плане fine-tuning. По производительности тоже нареканий пока не было. Очевидно мой опыт довольно ограничен, но ведь именно поэтому на сертификацию и приходится полагаться.

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

Очень здравая мысль. Полностью солидарен (даже в масштабах домашнего localhost). Я даже «3х метровой палочкой» трогать пока не собираюсь… Это относительно BTRFS.

bugfixer ★★★★
()
Последнее исправление: bugfixer (всего исправлений: 1)