Короткая заметка, написать которую меня натолкнуло появление этой статьи: "Неожиданная находка, которая освобождает 20 GB". Ха! Всего 20GB ? Есть универсальный способ освободить больше.
Linux утилита mkfs.ext4 (ext2/ext3/ext4) имеет параметр -m, о котором мало кто знает. Я не знал. И никто из моих знакомых-линуксоидов не знал.
Этот параметр резервирует место, в процентах, доступное только суперпользователю. Чтобы, когда обычные юзеры выжрут весь диск, демоны продолжали оголтело писать свои логи, не падая. Значение по-умолчанию: 5. ПЯТЬ ПРОЦЕНТОВ! Что на диске в 10Тб даёт сумасшедшую цифру в 500 гигабайт. На логи, да! Наверное в начале-середине 90х такая процентовка имела смысл, но явно не сейчас.
Мало того что производители дисков жонглируют гига- гиги- байтами, неизменно продавая обьём меньше интуитивно ожидаемого. Так ещё и "налог" сверху, в 5%, от утилиты форматирования! Особенно для дисков с данными, где никаких логов нет и не предвидится.
Переформатировав свои 100тб дисков, я получил дополнительные 5Тб дискового пространства, просто так, на ровном месте.
Всем хороших выходных!
Комментарии (194)
randomsimplenumber
17.06.2022 23:26+110Linux утилита mkfs.ext4 (ext2/ext3/ext4) имеет параметр -m, о котором мало кто знает.
Выросло поколение, man не читающее. (Бурчит себе под нос).
screwer Автор
17.06.2022 23:36+6Как показал 1,5 года назад мой беглый опрос - нас таких, не читающих, много (((
Причём некоторые с Линуксом больше 25 лет. Так что - вдруг кому-то пригодится, уже польза.
jsirex
18.06.2022 12:09+12Часто на проверку оказывается, что это не 25 лет опыта в линукса, а 1 год опыта работы с линуксом 25 раз. Да и в цифре 25 сильно сомневаюсь. Скорее не больше 20
screwer Автор
18.06.2022 15:17+10Часто на проверку оказывается, что это не 25 лет опыта в линукса, а 1 год опыта работы с линуксом 25 раз.
Вы не правы. ИМХО можно хоть всю жизнь быть с линуксом, и прекрасно обходиться без обсуждаемой опции.
Скорее не больше 20
Ну давайте посчитаем... С тем человеком я работал в 2003-2005 годах, он уже тогда пришёл на должность главного админа большого предприятия. >2000 человек, ~200 компьютеров, полсотни сетевых принтеров, ИП телефония, 2 оракловых сервера, файловый сервер на FC, 30 терминальных серверов, куча цисок, распределённая сеть между офисом (город) и производством (область). Это было почти 20 лет назад. По его словам его путь с линуксом начался ещё с 1.0, выкачиваемом в 90е по диалапу, и ручной сборкой. ЕМНИП тогда сам линукс ещё был в младенческом состоянии, версия ядра 2.2 или 2.4, однозадачного как ДОС (я имею в виду, что внутри ядра preemting не работало). Точно помню, что мы тестировали разные версии ext файловых систем. Тупым тестом на СИ, который я написал, создающем в многопотоке файлы/каталоги, читающем, пишущем и удаляющем их. В итоге попсовые ФС тогда тупо разваливались уже после нескольких часов такой нагрузки. По-моему это была ext2, но за давностью лет уже зуб не дам. Что выбрали в качестве стабильной ФС тоже не вспомню. Просто зарисовка, в каком состоянии тогда было Linux окружение.
levkib
20.06.2022 06:42Странно, что он не знал. Может он не знал именно про опцию '-m' ?
У меня примерно такой же опыт общения с linux, с 90-х. Опция резервирования места регулярно спасала при тогдашних объемах дисков.
foxweb
20.06.2022 14:27+1ой, чуваки, не спорьте, в жизни и не такое бывает. в 2010 я встретил сисадмина-эникейщика туристической фирмы уже в годах, который не знал, что такое Ubuntu (линукс-дистрибутив). можно работать всю жизнь без знаний, без которых кто-то другой не представляет себе жизни.
demitel
20.06.2022 10:03+2Двадцать пять лет назад, если система не досталась волшебным образом в дар вместе с обслуживающим её человеком, установка, настройки и использование линукса предполагали изучение огромного количества документации, в том числе tune2fs. По крайней мере двадцать лет назад мне не удалось этого избежать. В те годы многие, воспринимаемые сейчас как само собой разумеющиеся, вещи были удивительны в настройке, например монтирование или проверка дисков, что заставляло RTFM. В те времена каждый мегабайт был на учёте, и, например, потеря целых 200 мегов на моём 4,3 гигабайтном фуджике не могла пройти незамеченной уж никак. Да и восемь лет назад коллега при переходе с винды довольно быстро заметил эту особенность с резервом, что характерно, сам.
falcon4fun
19.06.2022 16:11+1Соглашусь с ТС скорее. ДевОпс тому прекрасный пример: специализированный набор утилит, который нигде, кроме девопса, не используется. В большинстве своем отсутствие базовых знаний (ведь зачем знать, как работает акпп, чтобы ездить на машине.
Зато потом огромный процент людей спрашивает: а что будет, если ревер тыркнуть на ходу?)
SlimShaggy
20.06.2022 10:47А на МКПП что будет? Вчера случайно попробовал: хрустит и не втыкается (усилий не прилагал).
A1EF
18.06.2022 22:18+5Чо уж, я сам-то узнал про факт, описываемый в посте, так: мой тогдашний руководитель отдела обратил внимание, что на серверах сразу после установки операционки свободное и занятое место не согласуются с суммарным объемом. Я отмахнулся, мол это приколы перевода объемов в степенях двойки и десятки скорее всего. Он полез разбираться и нашел про это самое резервирование и как через
tune2fsподвинуть. Я добавил себе в копилку знаний и на будущее взял на заметку впредь быть повъедливей:)
KSCF
19.06.2022 13:28Если какая-то вещь создана таким образом, что о ней нужно читать, значит о прочитанном будет обязательно забыто. Слишком уж много в мире теперь писатели пишут. Печально, что в линуксе нужно читать и про логи, и про форматирование. Базовые вещи, которые должны быть хорошими "искаропки"
janvarev
17.06.2022 23:44+13Знаете, мне тут пришел шедевральный баг-репорт по кроссплатформенному проекту:
Юзер:
У меня ошибка:
FileNotFoundError: [Errno 2] Нет такого файла или каталога: 'C:\\Program Files (x86)\\K-Lite Codec Pack\\MPC-HC64\\mpc-hc64_nvo.exe'
Тут скрипт требует K-Lite Codec Pack, но его нету на linux по этому пути
А вы говорите — man читать… Я после такого вообще в шоке был.
DrinkFromTheCup
18.06.2022 12:08+6Тут скрипт требует K-Lite Codec Pack, но его нету на linux по этому пути
Т. е. как минимум с:\\ у него в линуксе - ЕСТЬ?!
DrPass
20.06.2022 15:12+1Ну смотря что это был за юзер. Если это разработчик — то да, перебор. Если обычный юзер приложения, то с ним-то всё ок, проблема в софте, который на линуксе такое может выдать.
sunnybear
17.06.2022 23:27+2Вы ещё журнал не пробовали отключать. И резерв самих контроллеров диска :)
screwer Автор
17.06.2022 23:33+1Эти оба-два чреваты потерей данных. В отличие от ненужного (для дисков с данными) резерва под логи.
AlexGluck
18.06.2022 01:14+7tune2fs -r "$((300*1024*1024/$(tune2fs -l /dev/sda1 |grep "^Block size:" | cut -f2 -d ':' | xargs)))" /dev/sda1АВТОР ЭТОГО WISYWIG УМРИ!
Отключать резервирование не надо, иначе даже от рута не залогинитесь. Третий раз писать почему, не буду, редактор отстой. Я ставлю резерв 300МБ.
screwer Автор
18.06.2022 01:24+3Напомню, что речь идёт о дисках с данными. Не о рутфс. Причем тут "залогиниться" ?
AlexGluck
18.06.2022 01:27+3Всё равно пространство для манёвра оставлять надо, если надо будет провести архивацию старых данных (например логи в текстовом режиме писали), то хоть на пол шишечки место не повредит, а жадничать 300 метров это уже ту мач в современном мире.
aml
19.06.2022 00:21При том, что когда системные демоны запускаются, им иногда надо создавать файлы - pid-файлы, локальные unix domain sockets. Если места ноль, может не получиться, и система уже не поднимется. При нынешних объемах дисков конечно 5% это до фига. Можно и меньше поставить.
ALiEN175
18.06.2022 05:58+9кто вам наплёл сказки про мифические логи? Резерв root для раздела ext3/4 с ОС существует, чтобы вы не получили чёрный экранчик с мигающим курсором, если у вас всё место забито на 100%.
SlimShaggy
20.06.2022 10:54Какие нежные эти ваши линуха. Винда с 0 байт на системном разделе спокойно стартует.
vadimr
17.06.2022 23:34+1Более интересный вопрос – зачем вообще использовать ext в сегодняшних реалиях.
superconductor
17.06.2022 23:37+4А какой фс сейчас пользоваться более модно, если не ext4?
vadimr
17.06.2022 23:39+1SUSE, например, рекомендует btrfs для корневого раздела и xfs для данных. Никогда особо над этим не задумывался и просто так и делал.
sim2q
18.06.2022 07:24+1уже точно можно?
я просто немного консервативен, btrfs стоит на backup потому чтоне жалкожмёт не плохо - вроде нормальноvadimr
18.06.2022 09:41+1Лет 10 пользуюсь везде, проблем не было.
Журналирование - полезная вещь. Опять-таки, можно будет написать статью, как пропуржить журнал :)
13werwolf13
20.06.2022 09:19btrfs однозначно ДА
10 лет назад в случае мигнувшего питания или проблем с hba она превращалась в тыкву без возможности восстановить данные, сейчас это стабильная и очень фичастая фса вот xfs я бы не советовал тем кто не уверен на 100500 процентов в том что его сервер/компьютер/ноут будет ВСЕГДА graceful shutdown. так что если не нужна фичастость btrfs то лучше ext4
ну а из фич btrfs лично я юзаю:
1) подтома
2) сжатие (после перехода на zstd оно перестало оказывать влияние на скорость чтения/записи)
3) массивы (да, да.. как в zfs, только аналогов zvol нету пока)
4) снапшоты (накосячил кривыми ручками что-то, бах и откатился в рабочую систему, нраися..)
CoW конечно дико фрагментирует данные на диски, но в отличии от винды в линуксе это как-то незаметно влияет на скорость работы даже на медленных блинах 5400rpm, ну а на ssd всё это вообще не играет роли. Ну а если прям хочется то CoW можно и отключить
maratkoRuEkb
20.06.2022 17:10Полгода назад статья же выходила что btrfs высаживает диски быстро, потому что постоянно чтото пишет и переписывает в гораздо большем объеме чем надо.
DerRotBaron
18.06.2022 19:12+6Btrfs у меня невостановимо умирала еще в конце прошлого года (а до этого в 2019 на другой машине побила данные), нормальных утилит для восстановления нет (официальные не сильно пытаются читать побитое дерево, testdisk и подобные не признают, а платить сотни долларов за данные, которые забэкаплены, жаба задушила).
Akon32
20.06.2022 12:15А что именно произошло? Это были описанные в документации проблемы с raid5/6 или что-то другое?
isden
18.06.2022 01:58+10zfs
ivanrt
18.06.2022 03:07+2Пользую zfs. Прозрачная быстрое сжатие (lz4) сжимает диски моих виртуальных машин в два раза не учитывая thin provisioning, но безполезно для видео и музыки. С другой стороны zfs плохо работает без 20% пустого места. Btrfs тоже сжимает и вообще прогрессивна, но крэшила мне виртуальные машины и вообще сожрала мои тестовые данные два года назад. Пользуюсь zfs из-за удобного управления местом, снэпшотов, умного рейда и репликации.
Pavel1114
18.06.2022 07:50+1Прозрачная быстрое сжатие
Вот и тема для следующей статьи. На этом, в зависимости от данных, можно поболее жалких 5% выиграть. Но вроде современные дистрибутивы по умолчанию включают эту опцию в zfs и btrfs.
entze
18.06.2022 12:59Не только сжатие, но и дедупликация. В некоторых сценариях может оказаться, что дублей достаточно для солидной экономии.
Хотел использовать OpenZFS на Mac, ноленивая жопане стал разбираться с CLI, а GUI не работал. Выбрал дедупликацию сторонними средствами для APFS и для свалки обнаружил ощутимый прирост свободного места.isden
18.06.2022 17:47Хотел использовать OpenZFS на Mac
Я пробовал. Вроде работает, но как-то страшно ему доверять что-то, в интернетах встречал отзывы что может все сломать на ровном месте.
screwer Автор
18.06.2022 15:21+2выиграть можно, но какой ценой ?
Я поставил один 6тб диск "поиграться", разметив его в ZFS. Сжатие и дедупликация дают великолепную экономию места. Но как же это всё тормозит! Даже удаление сотни гигабайт файлов занимает несколько часов. А заливка пары террабайт длилась почти сутки. И это на виртуалке с 48 процессорами и 128гб озу! Вообщем пользоваться этим "по-дефолту" невозможно, надо как-то тюнить производительность.
Ещё был сюрприз, при переносе диска из Ubuntu18 в Ubuntu22. Пул стал, внезапно, degraded. При переносе обратно - всё отлично, online. scrub не помог.
edo1h
18.06.2022 15:36+1Сжатие и дедупликация дают великолепную экономию места. Но как же это всё тормозит! Даже удаление сотни гигабайт файлов занимает несколько часов. А заливка пары террабайт длилась почти сутки. И это на виртуалке с 48 процессорами и 128гб озу!
странно, использую zfs на бекапном сервере.
каждую ночь на него заливается около 10 терабайт, никаких проблем.другое дело, что дедупликацией пользоваться можно только очень осторожно, но про это, вроде бы, на каждом углу написано.
isden
18.06.2022 17:51+1Но как же это всё тормозит! Даже удаление сотни гигабайт файлов занимает несколько часов. А заливка пары террабайт длилась почти сутки.
Я уже много лет использую zfs (в том числе и как rootfs).
Описанных проблем не встречал, хотя доводилось и удалять и заливать сотнями гигабайт.
aik
18.06.2022 09:07Простая, дубовая, совместимая.
Решение по умолчанию, в общем. Все эти зфс и бтрфс — только если нужны их фишки.
A1EF
18.06.2022 11:51+3Встречный вопрос: а чем плох ext4? Если не рассматривать какие-то очень специфичные сценарии, конечно.
vadimr
18.06.2022 11:58+1нет снапшотов
нет управления томами и ресайза в онлайне
нет сжатия
нет сopy-on-write
-
не оптимизирована для SSD
Для меня уже и первого пункта достаточно. Второй тоже важен при смене оборудования. В btrfs можно в пределе даже переехать с одного физического диска на другой, не останавливая работу системы.
В btrfs новая версия файла не затирает старую, что может оказаться важным в случае неприятностей.
DonAgosto
18.06.2022 13:46-1нет снапшотов
для системного диска на десктопе вполне заменяется timeshift
на SSD снимок делается за некритичное времяvadimr
18.06.2022 14:14Ну всё можно так или иначе делать костылями. Снапшот-то вообще не занимает времени и не требует дополнительного диска.
Одно дело, когда у вас отметка снапшота выполняется мгновенно, а другое – когда будет шерстить весь диск и сбрасывать изменения, пусть даже это и SSD.
DonAgosto
18.06.2022 14:27Снапшот-то вообще не занимает времени
я про время специально указал — для типичного десктопа вобще нет разницы сколько там оно копируется в фоне — 0.1с или 100си не требует дополнительного диска.
timeshift тоже не требует. Но если сохранять снимки на другой диск/раздел, то это уже преимущество перед снимками ФС — получим фактически инкрементный бэкап, стойкий к повреждению ФС на исходном разделе.vadimr
18.06.2022 14:36+1Не понял, как нет разницы? Вот я хочу, например, отредактировать какую-нибудь настройку в /etc. Так я даю команду сделать снапшот и редактирую. А так буду ждать 100 секунд.
DonAgosto
18.06.2022 14:48да, безусловно, если ваша работа/досуг состоят в основном из подобных задач, встроенные снапшоты в ФС будут более удобны
но мне кажется, наиболее частый сценарий для десктопа — быстро откатить, если что-нито сломалось при очередном обновлении — а это конечно довольно редкое событиеvadimr
18.06.2022 15:10+1Сломалось - редкое событие, а обновить что-нибудь - частое. Поэтому задача как раз в том, чтобы мгновенно сохранить, а не в том, чтобы быстро откатить.
edo1h
18.06.2022 15:28+3не оптимизирована для SSD
можно пример фс, эффективно оптимизированной под ssd?
vadimr
18.06.2022 15:37+1APFS, например
А, возвращаясь к теме, та же btrfs по-разному строит структуры данных на HDD и SSD.
edo1h
18.06.2022 15:40+1А, возвращаясь к теме, та же btrfs по-разному строит структуры данных на HDD и SSD.
и даёт ли это какой-либо измеримый эффект?
vadimr
18.06.2022 17:27Я не мерял. Теоретически ресурс должен быть больше.
edo1h
18.06.2022 22:01погуглил, основное (единственное?) отличие в режиме ssd был другой аллокатор, который признали негодным:
Using the ssd mount option with older kernels than 4.14 has a negative impact on usability and lifetime of modern SSDs.откатили на версию для hdd:
https://github.com/torvalds/linux/commit/583b723151794e2ff1691f1510b4e43710293875
https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg66210.htmlvadimr
18.06.2022 22:12Не, там другое дело. Речь идёт о дублировании служебных блоков, и определяется это не по устаревшей опции монтирования ssd, а непосредственно по запросу типа диска (cat /sys/block/sda/queue/rotational)
edo1h
18.06.2022 22:36вы про это:
Up to version 5.14 there was a detection of a SSD device (more precisely if it’s a rotational device, determined by the contents of file /sys/block/DEV/queue/rotational) that used to select single. This has changed in version 5.15 to be always dup.
https://btrfs.readthedocs.io/en/latest/mkfs.btrfs.htmlопять же пришли к выводу, что поторопились с отдельной логикой для ssd.
d2d8
18.06.2022 16:26+1Если учесть, что SSD в принципе пофигу как там что расположено, то зачем делать разные структуры?
edo1h
18.06.2022 17:24ну не совсем пофиг.
ssd всё так же «предпочитают» последовательный доступ случайному, особенно на записи. просто разница не столь фатальна, как на hdd.
десктопные ssd, так же как и hdd, «не любят» мелкоблочной синхронной записи.
притом тут речь идёт не только о производительности, но и о снижении wa (другими словами, повышении ресурса).итого:
- пишем по возможности последовательно, как можно бо́льшими кусками;
- опять же по возможности организуем структуры данных так, чтобы и чтение было максимально линейным (тут мы можем заодно получить профит и от упреждающего чтения ос);
- fsync вызываем как можно реже (если не предполагаем datacenter-grade хранилище).
но так все эти оптимизации будут актульны и для hdd.
для hdd есть ещё рекомендации:
- стараемся запросы размещать максимально «кучно». сик между первой и десятой дорожкой происходит быстрее, чем между первой и тысячной;
- стараемся не повышать глубину очереди, это хоть и повышает производительность за счёт переупорядочивания команд, но ведёт к фатальному росту задержек, что для многих применений неприемлемо;
- (как важный случай предущего) стараемся не «смешивать» линейную нагрузку со случайной, если мы пишем, скажем, данные, приходящие из какого-то источника с плавающей скоростью, например 50-100 мегабайт в секунду, то hdd с ней прекрасно справится, но стоит добавить буквально пару десятков iops от других задач — и он должен будет постоянно дёргать головками, его производительность упадёт вдвое (считаем средний сик 12 мс, на каждую «левую» операцию ему нужно будет перевести головки в новую позицию и вернуть обратно в область линейной записи, умножаем два сика на 20 iops, получается, что диск будет занят перемещениями головок ≈480 мс на каждую секунду).
получается, для hdd есть дополнительные оптимизации, которые никак не повлияют на ssd.
примеров же оптимизаций, которые работают для ssd, но навредят hdd, я не знаю.
разве что вызов trim? ну так он полезен не только на ssd, но и в виртуальных средах с thin-хранилищами, например.
vadimr
18.06.2022 17:25+1Для SDD - беречь ресурс записи.
Для HDD - уменьшать задержки на позиционирование.
Также, например, дублирование управляющих структур на SSD не имеет смысла, так как контроллер выполняет дедупликацию.
edo1h
18.06.2022 17:36так как контроллер выполняет дедупликацию.
нет. во всяком случае мне такое не встречалось.
можете сами взять и проверить, уfioесть специальный флагrefill_buffersvadimr
18.06.2022 19:20Не очень понял Вашу мысль. С refill_buffers fio ожидаемо выдаёт более плохой результат.
edo1h
18.06.2022 19:40какой накопитель и какие точные параметры тестирования? можеть быть у вас в процессор упирается? (если вы не указываете
numjobs, то всё крутится на одном ядре)fio --name=test --ioengine=libaio --iodepth=1 --numjobs=28 --cpus_allowed_policy=split --rw=randwrite --bs=4M --direct=1 --filename=/dev/nvme1n1 --time_based=1 --timeout=20s --randrepeat=0 --group_reporting=1 --refill_buffers=0на pm9a3 выдаёт плюс-минус одинаковые цифры (как ни смешно, с
refill_buffers=1стабильно результат на 1-2% выше)update: прочитал внимательнее ман:
scramble_buffers=bool
If refill_buffers is too costly and the target is using data deduplication, then setting this option will slightly modify the IO buffer contents to defeat normal de-dupe attempts. This is not enough to defeat more clever block compression attempts, but it will stop naive dedupe of blocks. Default: true.то есть по дефолту
fioвключает защиту от дедупликации. чтобы проверить, что накопитель дедуплицирует, надо проверить ещё и сscramble_buffers=0vadimr
18.06.2022 19:48Mac mini
Apple SSD Controller:
APPLE SSD AP0512M:
Емкость: 500,28 ГБ (500 277 792 768 Б)
Поддержка TRIM: Да
Модель: APPLE SSD AP0512M
Редакция: 1 274,100
Серийный номер: C0700840001KXQWA4
Ширина ссылки: x4
Скорость связи: 8.0 GT/s
Это без refill_buffers:
bw ( KiB/s): min=56128, max=76496, per=100.00%, avg=72123.28, stdev=3513.07, samples=29
это с refill_buffers:
bw ( KiB/s): min=50131, max=71744, per=99.97%, avg=68785.07, stdev=4446.72, samples=30
cpu : usr=2.18%, sys=13.79%, ctx=132118, majf=5, minf=25
[global]
name=fiotest
direct=1
iodepth=32
group_reporting
runtime=60
startdelay=60
[random-rw-test1]
rw=randread
bs=8k
size=1Gb
numjobs=1
edo1h
18.06.2022 21:06так я говорю, вы измерили накладные расходы на генерацию 8к рандома в одном потоке. при этом вероятную дедупликацию вы не протестировали, так как с дефолтными настройками fio меняет несколько байт в каждом запросе чтобы помешать дедпуликации.
vadimr
18.06.2022 21:31На самом деле я ещё в прошлый раз по ошибке всадил randread вместо randwrite :(
Вот правильные результаты:fio--scramble_buffers=1jobfile.fiorandom-rw-test1: (g=0): rw=randwrite, bs=(R) 8192B-8192B, (W) 8192B-8192B, (T) 8192B-8192B, ioengine=psync, iodepth=32WRITE: bw=64.5MiB/sfio--scramble_buffers=0jobfile.fiorandom-rw-test1: (g=0): rw=randwrite, bs=(R) 8192B-8192B, (W) 8192B-8192B, (T) 8192B-8192B, ioengine=psync, iodepth=32WRITE: bw=298MiB/sРазница от дедупликации почти в пять раз!Upd: Всё, я не могу поставить методически корректный эксперимент. Поскольку блоки, записанные ранее, физически остаются на SSD, то при каждом новом запуске fio результаты всё улучшаются, независимо от параметров. Уже до 432MiB/s дошло.
Возможно, помогло бы после каждого запуска обесточивать компьютер, но на такой геморрой идти не хочется.
Во всяком случае, качественно можно оценить, что производительность записи на SSD крайне зависима от предыстории.
edo1h
18.06.2022 22:00Поскольку блоки, записанные ранее, физически остаются на SSD, то при каждом новом запуске fio результаты всё улучшаются, независимо от параметров
честно говоря не понял, что значит «блоки остаются на ssd».
vadimr
18.06.2022 22:08Ну я же создал тестовый файл при помощи fio. Его содержимое никуда не делось с ssd, когда я этот файл стёр перед следующим запуском программы. Когда я второй раз запускаю программу, она генерит такие же блоки с теми же контрольными суммами (хотя они и разные от блока к блоку, но всего их ограниченное число), это ловит алгоритм дедупликации в контроллере SSD и просто использует блоки, записанные при прошлом запуске программы, вместо того чтобы писать ещё раз.
edo1h
18.06.2022 22:21+1Его содержимое никуда не делось с ssd, когда я этот файл стёр перед следующим запуском программы
а как же trim? или он в apfs сильно отложенный?
это ловит алгоритм дедупликации в контроллере SSD
не верю.
- алгоритм дедупликации требует кучу памяти (а на накопителях обычно впритык ftl разместить);
- дедупликация требует чтения найденного дубля для верификации совпадения (может же оказаться, что обнаружилась коллизия). так что стоит ожидать скорее падения скорости, чем прироста.
меня смущает, что вы работаете с файлом, а не с устройством, возможно, вы столкнулись с какой-то особенностью apfs
vadimr
18.06.2022 22:36Trim просто говорит о том, что данные в блоке не нужны компьютеру. Он не приводит к их стиранию.
Работа 2010 года. Сейчас это уже общее место.
На HDD c APFS такого эффекта нет, там более-менее ровные времена доступа с производительностью около 10 MiB/s. Чуть быстрее с разными блоками, как и у Вас (думаю, это связано с тем, что файл из одинаковых блоков организуется как sparse и тратится время на алгоритм компрессии).
entze
19.06.2022 20:29Тогда не оно, copy-on-write на HDD работает. Дедуплицировал свалку копий с SD карты.
13werwolf13
20.06.2022 09:23f2fs, btrfs, zfs - изначально имели оптимизации для ssd, остальные фс тоже уже подтянулись
A1EF
18.06.2022 19:23+2Про тома и снапшоты: lvm2+ext4. Понимаю, что это вряд ли прозвучит убедительно плюс тащит лишнюю сущность, но на моей практике это частая комбинация. XFS вообще умеет только расширяться. К btrfs же я просто предвзят. Огрёб как-то проблем несколько лет назад, желание продолжать отпало.
vadimr
18.06.2022 19:26lvm2 никак не поможет исключить том из файловой системы ext4 (не потеряв её содержимое).
С btrfs как-то у меня была одна проблема много лет назад, с тех пор тьфу-тьфу-тьфу. По сравнению с тем, сколько раз слетали ext'ы, это фигня.
13werwolf13
20.06.2022 09:22не оптимизирована для SSD
давно уже оптимизирована, почти все существующие ФС получили оптимизации для работы с ssd. в какой фс эти оптимизации оптимизированней вопрос конечно открытый, но говорить что фс не оптимизирована для ssd это крайне неверно.
edo1h
20.06.2022 11:00вы сначала приведите пример оптимизации для ssd, которая не применима к hdd.
пока все «оптимизации», что я видел, заключались в отключении некоторых оптимизаций, изначально придуманных для hdd, и только.
vitaly_il1
20.06.2022 14:49ИМХО нужно использовать ту filesystem, которая по умолчанию в дистрибутиве.
akakoychenko
17.06.2022 23:48+10Вспомнилось, как на заре Гугла там писали данные только на внешние дорожки дисков (дальние от центра), ибо, скорость чтения там выше так, как, физически, область под головкой там движется быстрее при одинаковой скорости вращения шпинделя. Что позволяло им иметь SLA по скорости линейного чтения/записи выше, чем без таких приколов.
А это было критично (тут уже не знаю, а предполагаю), видимо, потому, что они практиковали массивно-параллельные архитектуры до того, как это стало мейнстримом, и, соответственно, все воркеры ждали самый медленный диск (тот, на котором данные лежат ближе к центру), что приводило к простоям
Schokn-Itrch
18.06.2022 02:02Вспоминается Crash Bandicoot и "мусор" на диске.
akakoychenko
18.06.2022 12:07Так подобное и сейчас практикуется. К примеру, когда файлы игры содержат много раз продублированные структуры, чтобы при загрузке уровня поднимать все необходимое линейным чтением, а не случайным
4umak
18.06.2022 00:04+6Переформатировав свои 100тб дисков
просто так, на ровном месте.tune2fs -m 0 /dev/sda1
AlexGluck
18.06.2022 01:18+10Ага, а потом чтобы без простоя вернуть систему в строй надо... А ничего не надо, вы просто не залогинитесь даже рутом. Ведь при логине создаются дескрипторы, временные файлы, другая обязательная фигня и аля улю, ребут сервера в rescue режим. Выше описал альтернативное решение.
Sergey_datex
18.06.2022 00:05Ext файловые системы вообще очень жадны к резервируемому пространству под файловые структуры. Таких проглодитов в мире айти я больше не видел. 20 гиг под файловые структуры на терабайтном диске? а пжалста
hogstaberg
18.06.2022 01:53+2А другие файловые системы служебную информацию в ноосфере хранят, ага.
Sergey_datex
18.06.2022 02:00+6Нет, ее сильно меньше. Только в ext идиотская разбивка на блоки, в каждом из которых зарезервировано место под битмапы и прочую служебку. Разбивка очень "густая", блоки мелкие. Минусаторы могут детально изучить структуру файловой и глянуть ее с помощью какого-нибудь средства визуализации/подсчета занимаемого места. А, еще минус Ext - он равномерно "размазан" по всему носителю. При восстановлении данных нам это доставляет мнооого проблем. NTFS - вся мета (почти) в одном метафайле, обычно компактно лежащем в одном месте. FAT|exFAT - мета размазана по носителю, но там где она нужна, а не как в Ext.
PS: все то идиотство в Ext тянется исторически с дремучих времен с цилиндрами и другими архаизмами...
Schokn-Itrch
18.06.2022 02:08+3Contig v1.8 - Contig
Copyright (C) 2001-2016 Mark Russinovich
Sysinternalsc:$Mft is in 403 fragments
c:$Mft::$BITMAP is in 318 fragmentsSSD. Диску около года. Только w10 и больше ничего. Свопа нет, гибернация отключена, все времянки в другом месте, оперативки 32 гига с первого дня. Так что "компактно в одном месте" это что-то не про нашу реальность.
Busla
18.06.2022 12:40+2По дэфолту MFT начинает фрагментироваться при заполнении диска более 87,5%. Похоже, вы перестарались с оптимизаторами и уменьшили в реестре резерв непрерывного пространства за MFT.
Крутить NtfsMFTZoneReservation особого смысла нет, т.к. это не жёсткий резерв пространства в целом, а лишь задание зоны, которая будет использоваться в последнюю очередь.
Schokn-Itrch
18.06.2022 23:28Я ничего не делал вообще. Вы вообще прочитали условия? 32 гига оперативки. Даже будь я конченным извратом, который в принцие способен применять какие-то-там оптимизаторы, за год нельзя засрать систему так, что бы они потребовались.
Фактически на этом компе установлены только SoftMaker Office, Vivaldi и WACUP. Причем все они установлены на второй раздел и все данные которые они используют находятся на втором разделе.
P.S. Почему на офисной читалко-писалке 32Гб? "Патамушта" Осень прошлого года, переизбыток комплектухи у конкретной фирмы, низкие цены. По этой же причине там и 5750G.
Busla
19.06.2022 12:25+2Вот именно, что я прочитал условия:
Свопа нет, гибернация отключена, все времянки в другом месте
И пришёл к выводу, что кое-какими оптимизациями занимались.
При чём в этом обсуждении объём RAM и модель CPU мне решительно непонятно, но если вам так хочется похвастаться конфигурацией, то пожалуйста.
Nbx
18.06.2022 00:10+2Есть много интересных флагов, я например в своё время noatime всегда ставил.
Сейчас с приходом SSD опять может быть полезно, уменьшать циклы записи.
dyadyaSerezha
18.06.2022 01:32+4Переформатировать 100 ТБ... Это ж сколько времени ушло на копирование данных с каждого диска и обратно на диск? Прямо жалко автора)
screwer Автор
18.06.2022 01:40+3Было чуть легче - обратно уже не копировал. Переносил данные на свеже-отформатированный, затем форматировал источник.
hogstaberg
18.06.2022 01:52+10Вообще то эти 5% нужны не для того чтобы логи писать. Они нужны для того, чтобы даже при почти полностью забитом разделе файловая система не начинала фрагментировать записываемые данные как сумасшедшая. И что-то мне подсказывает: у тех, кто уменьшает процент зарезервированного пространства, всё остальное место как раз таки занято. Ну или не занято, но тогда и крутилку трогать по сути незачем раньше времени.
Строго говоря, я бы вообще не рекомендовал бездумно менять дефолтные параметры файловых систем без чёткого понимания того что, как и зачем меняется и чем это чревато.
ilmarin77
18.06.2022 02:04Ещё это нужно потому-что если на /tmp занято 100% (или /var), то даже root в эту систему не пробьётся через SSH.
hogstaberg
18.06.2022 07:02+1Ну это уже приятный бонус, реально ноги у этого растут именно из задачи уменьшения фрагментации данных, а конкретный процент от объема раздела из каких-то там соображений и расчётов, сделанных, ЕМНИП, ещё в 80-х годах в университете Беркли.
vadimr
18.06.2022 13:14+1Тут можно отметить, что для SSD вопрос фрагментации совершенно неактуален.
screwer Автор
18.06.2022 15:24для SSD вопрос с резервированием гораздо более актуален.
Потому что надо обеспечить равномерный износ блоков. Если свободного запаса нет - придётся эти блоки сначала освободить, что удвоит нагрузку по записи, и удвоит износ ССД.
vadimr
18.06.2022 15:39+1Освобождение блоков не требует операции записи в случае наличия у фс понятия о TRIM.
А равномерностью износа занимается контроллер SSD.
screwer Автор
18.06.2022 16:56Причем тут trim ? Вот есть у нас диск, занят на 99%. Чтобы равномерно изнашивать блоки - придется постоянно перемещать уже записанные данные, иначе ресурс записи у оставшегося 1% блоков исчерпается очень быстро.
Если же свободно 50% можно особо не париться (до некоторого момента) и размазывать записи по ним.
Трим же для понимания контроллеру, какие записи свободны, а какие нет.
vadimr
18.06.2022 17:22Блоки перемещает при записи сам контроллер, компьютер про это не должен думать.
screwer Автор
18.06.2022 18:57Речь не о том, кто перемещает. А о влиянии свободного места на ресурс.
vadimr
18.06.2022 19:08Так именно поэтому свободное место не влияет на ресурс.
screwer Автор
19.06.2022 00:41Ну как же не влияет. В изначальном примере - если записывать-стирать данные, когда свободного места почти нет - что должен делать контроллер ? Жонглировать только пустыми блоками ? Тогда их ресурс исчерпается очень быстро.
vadimr
19.06.2022 11:33Их ресурс исчерпается, но ресурс других за их счёт сохранится. Сумма не изменится.
Ndochp
19.06.2022 12:03Так на сумму плевать, если мы сожгем 1% свободного и весь резерв при однократно записанных 99% остальных областях диск все равно уйдет в помойку.
vadimr
19.06.2022 12:09Надо уж очень сильно постараться, чтобы реализовался такой сценарий. Годами не трогать 99% содержимого диска.
Речь-то изначально шла о совсем другом – что само по себе высокое заполнение диска якобы вредно, и поэтому его не допускает файловая система. А не о том, чтобы отлёживать на SSD однократно записанные данные, используя его в режиме CD-R.
И кстати, если уж на то пошло, описанные в статье 5% резерва не спасут отца русской демократии от такого сценария.
edo1h
19.06.2022 12:26Так именно поэтому свободное место не влияет на ресурс.
неправда.
посмотрите, чем различаются одноплатформенные накопители с ресурсом dwpd=1 и с dwpd=3samsung pm1733 3.84 TB: 1 dwpd
samsung pm1735 3.2 TB: 3 dwpdmicron 7400 pro 3.84 TB: 1 dwpd
micron 7400 max 3.2 TB: 3 dwpdintel d7-p5520 3.84 TB: 1 dwpd
intel d7-p5620 3.2 TB 3 dwpd
edo1h
19.06.2022 12:51а в чём разница-то?
у нас естьNГБ nand, и естьDГБ данных.
чем ниже отношениеD/N, тем ниже waf, или, другими словами, выше ресурс.
vadimr
19.06.2022 13:07Не так. Ресурс относится ко всему пользовательскому объёму диска, а не только к занятому данными. Поэтому число D тут не причём.
Есть N ГБ nand, M ГБ пользовательской памяти и (N-M) ГБ резерва блоков на подмену. Чем выше M/N, тем выше ресурс. А сколько у нас в моменте будет занято данными – вообще ни на что не влияет. Блоку пофиг, занят он или нет. И если диск практически пустой, а подменные блоки кончились, он так же выйдет из строя.
edo1h
19.06.2022 13:58Есть N ГБ nand, M ГБ пользовательской памяти и (N-M) ГБ резерва блоков на подмену
вы считаете, что «лишние» блоки используется просто как резервный фонд на случай выхода из строя основных?
нет, они являются частью общего пула блоков, с которым работает контроллер.почитайте сигейтовоскую статью про overprovisioning
вот вам картинка оттуда
освобождённое файловой системой пространство используется наравне с заводским OP.
P. S. статьи про overprovisioning есть и у интел, и у самсунга, и у кингстона, во всех написано примерно одно и то же.
vadimr
19.06.2022 14:00Какая разница? Речь идёт о том, что пользователю доступно M блоков, а изначально имеется N, которое постепенно расходуется вплоть до M. Понятно, что все блоки внутри устроены одинаково, и когда я говорю о резерве, то имеется в виду резерв количества, а не конкретные физические блоки.
Ниже, чем граница Real OP на картинке, количество исправных блоков опуститься не может. Хоть называй то, что ниже, "Dynamic OP", хоть "Presumed Valid Data", хоть "Free Space".
edo1h
19.06.2022 14:58Ниже, чем граница Real OP на картинке, количество исправных блоков опуститься не может
причём тут вообще исправность? заметное количество неисправных блоков — это не штатная ситуация.
речь про то, что «лишние» блоки используются при штатной работе.
из-за особенностей nand-памяти мы не можем просто взять и перезаписать какой-то сектор новыми данными, мы можем только записать новые данные в новое место, а старые пометить неиспользуемыми.
в результате данные просто «размазываются» по доступным блокам, соотношениеD/Mкак раз показывает на сколько в среднем будет заполнен каждый блок.
в какой-то момент запускается сборщик мусора, читает блоки с неиспользуемыми данными и переписывает полезную информацию из них в свободные блоки.так вот, пусть в блоке 1024 сектора.
- если занято было 256 секторов (¼), то мы записали в новый блок 256 секторов, 768 стало свободными — то есть записью 256 секторов мы освободили 768 сектора;
- если наоборот занято было 768 (¾), то мы записали 768, освободили 256.
предположим, нам надо записать на накопитель 3072 сектора, а резерва нет. значит сборщику мусора нужно сначала освободить эти 3072 сектора.
чтобы освободить 3072 сектора в первом случае сборщику мусора придётся обработать 3072/768=4 блока, при этом записать 4⋅256=1024 секторов.
во втором случае ему придётся обработать 3072/256=16 блоков, при этом записать 16⋅768=12288 секторов.итого, в первом случае чтобы записать 3072 сектора нам пришлось реально записать 1024+3072=4096 секторов. waf=4096/3072≈1.33.
во втором случае нам пришлось записать 12288+3072=15360 секторов. waf=15360/3072=5.то есть уменьшение совокупного свободного места (заводской OP + освобождённое с помощью trim место) с 75% до 25% вызвало увеличение износа накопителя в 3.75 раз.
разумеется, это очень грубые прикидки, мы предполагали, что все блоки заполнены одинаково, при реальной работе это не так.
но общее представление о влиянии свободного места на ресурс можно получить.Так именно поэтому свободное место
невлияет на ресурс.надеюсь, что этот вопрос мы закрыли
vadimr
19.06.2022 15:08Вот только эти все расчёты не имеют никакого отношения к занятым и свободным блокам с точки зрения файловой системы. Они касаются фактического значения битов в блоках. С точки зрения файловой системы эти блоки могут быть свободными, а с точки зрения контроллера SSD “грязными” (или наоборот, кстати).
Вопрос производительности-то упирается не в работу сборщика мусора (который сам чего-то там крутит в фоне), а в обнуление страниц перед записью.
Вы фактически своими расчётами доказываете тот факт, что чем больше на SSD записано нулей, тем эффективнее он работает. Это правда, но не имеет отношения к обсуждаемому вопросу резерва файловой системы.
edo1h
19.06.2022 16:25С точки зрения файловой системы эти блоки могут быть свободными, а с точки зрения контроллера SSD “грязными”
именно для того, чтобы сообщить контроллеру, что эти блоки свободны, и придумана команда trim
Вы фактически своими расчётами доказываете тот факт, что чем больше на SSD записано нулей, тем эффективнее он работает.
сделал раздел на 128 гигабайт.
a. заполнил рандомом и прочитал:
root@debian:~# shred -n1 /dev/nvme1n1p1; sync; echo 3 > /proc/sys/vm/drop_caches … root@debian:~# fio --name=test --ioengine=libaio --iodepth=1 --numjobs=1 --rw=read --bs=1G --direct=1 --filename=/dev/nvme1n1p1 --time_based=1 --timeout=20s … Run status group 0 (all jobs): READ: bw=6330MiB/s (6638MB/s), 6330MiB/s-6330MiB/s (6638MB/s-6638MB/s), io=124GiB (133GB), run=20058-20058msecb. сделал trim и прочитал
root@debian:~# blkdiscard /dev/nvme1n1p1 root@debian:~# fio --name=test --ioengine=libaio --iodepth=1 --numjobs=1 --rw=read --bs=1G --direct=1 --filename=/dev/nvme1n1p1 --time_based=1 --timeout=20s … Run status group 0 (all jobs): READ: bw=6748MiB/s (7076MB/s), 6748MiB/s-6748MiB/s (7076MB/s-7076MB/s), io=132GiB (142GB), run=20031-20031msecc. заполнил нулями и и прочитал
root@debian:~# dd if=/dev/zero of=/dev/nvme1n1p1 oflag=direct bs=1G … root@debian:~# fio --name=test --ioengine=libaio --iodepth=1 --numjobs=1 --rw=read --bs=1G --direct=1 --filename=/dev/nvme1n1p1 --time_based=1 --timeout=20s … Run status group 0 (all jobs): READ: bw=6342MiB/s (6650MB/s), 6342MiB/s-6342MiB/s (6650MB/s-6650MB/s), io=124GiB (133GB), run=20021-20021msecкак видим, нули и случайные несжимаемые данные читаются с одной скоростью, а вот чтение из области после trim идёт быстрее (что логично, контроллеру не надо обращаться к nand для реального чтения данных, достаточно заглянуть в ftl и увидеть, что в этих секторах данных нет).
vadimr
19.06.2022 16:34именно для того, чтобы сообщить контроллеру, что эти блоки свободны, и придумана команда trim
Да, но от этого не пропадает необходимость их чистить перед записью туда.
Относительно дальнейшего - мы вообще чтение или запись обсуждаем?
edo1h
19.06.2022 18:39Относительно дальнейшего — мы вообще чтение или запись обсуждаем?
мы обсуждаем внутренние алгоритмы работы ssd. доступа к исходникам нет, реверс-инжиниринг прошивки слишком трудоёмкий, поэтому ориентируемся на косвенные данные, например производительность операций чтения или записи.
Да, но от этого не пропадает необходимость их чистить перед записью туда.
разумеется не пропадает. но что вы этим хотели сказать?
вот смотрите, у меня в блоке 1024 сектора с данными.
для 1023 я сделал trim, после этого сборщику мусора достаточно перенести один оставшийся сектор в другое место и можно делать этому блоку erase.
vadimr
19.06.2022 19:12мы обсуждаем внутренние алгоритмы работы ssd. доступа к исходникам нет, реверс-инжиниринг прошивки слишком трудоёмкий, поэтому ориентируемся на косвенные данные, например производительность операций чтения или записи.
Так работа SSD при чтении и при записи – это две совершенно разные вещи. И чтение вообще не имеет никакого отношения ни к очистке страниц, ни к trim, ни к сборщику мусора, ни к заполнению диска.
разумеется не пропадает. но что вы этим хотели сказать?
вот смотрите, у меня в блоке 1024 сектора с данными.
для 1023 я сделал trim, после этого сборщику мусора достаточно перенести один оставшийся сектор в другое место и можно делать этому блоку erase.Это всё верно, но к чему это? Я же не спорю с тем, что trim помогает сборщику мусора, для чего, собственно, он и придуман. Я говорю о том, что поддержание запаса логического свободного места в файловой системе вообще никаким образом с этим процессом не связано. Сборщику мусора по самому принципу его работы не нужно дополнительное свободное место.
edo1h
19.06.2022 21:47Так работа SSD при чтении и при записи – это две совершенно разные вещи. И чтение вообще не имеет никакого отношения ни к очистке страниц, ни к trim, ни к сборщику мусора, ни к заполнению диска.
я показывал, что ваше утверждение «чем больше на SSD записано нулей, тем эффективнее он работает» неверно: нули для накопителя ничем не отличаются от прочих данных.
Я говорю о том, что поддержание запаса логического свободного места в файловой системе вообще никаким образом с этим процессом не связано. Сборщику мусора по самому принципу его работы не нужно дополнительное свободное место.
сборщику мусора (на самом деле не совсем правильно его так называть, скорее «сборщик не-мусора») приходится перемещать тем больше данных, чем меньше мусора.
trim помечает данные как мусор, так что trim напрямую влияет на его работу.
vadimr
19.06.2022 22:11я показывал, что ваше утверждение «чем больше на SSD записано нулей, тем эффективнее он работает» неверно: нули для накопителя ничем не отличаются от прочих данных.
Если Вы пытались оспорить именно это утверждение, то Вы выбрали неверный эксперимент, не относящийся к нему. Нули, записанные Вами, сами пишутся и читаются с той же скоростью, но помогут в неопределённом будущем следующей операции записи в те же секторы завершиться быстрее. Так как не придётся стирать страницы. (Если только файловая система не напихает своей служебной информации между нулевыми данными, как, например, HPFS и NTFS устраивают band'ы для быстрого доступа на HDD; кстати, отличный пример решения, увеличивающего эффективность на HDD, но катастрофически неоптимального для SDD).
сборщику мусора (на самом деле не совсем правильно его так называть, скорее «сборщик не-мусора») приходится перемещать тем больше данных, чем меньше мусора.trim помечает данные как мусор, так что trim напрямую влияет на его работу.
Это опять верные утверждения, не имеющие отношения к обсуждаемому вопросу. Вообще вся работа сборщика мусора не относится к обсуждаемой теме.
“Мусор” в понятии сборщика мусора никак не соотносится с количеством занятых или свободных областей в файловой системе. Это просто результат выполненных ранее операций записи.
Свободное от файлов пространство может быть как чистым (состоящим из нулей), так и мусорным. И занятое файлами пространство может быть как чистым, так и кандидатом в будущий мусор.
edo1h
19.06.2022 22:49Вообще вся работа сборщика мусора не относится к обсуждаемой теме.
как это не относится?!? именно она создаёт write amplification, то есть определяет расход ресурса nand
“Мусор” в понятии сборщика мусора никак не соотносится с количеством занятых или свободных областей в файловой системе. Это просто результат выполненных ранее операций записи.
так было до появления trim.
trim именно помечает данные как мусор для накопителя.чистым (состоящим из нулей)
да нет для накопителя такого понятия «сектор, заполненный нулями». для него это просто обычный сектор с данными.
есть «незаписанный сектор» (на который был сделан trim и после этого не было операций записи)Нули, записанные Вами, сами пишутся и читаются с той же скоростью, но помогут в неопределённом будущем следующей операции записи в те же секторы завершиться быстрее. Так как не придётся стирать страницы
почему их не придётся перетирать? придётся, nand не nor, не позволяет многократную перезапись одного участка.
да если бы и позволяло, не надо забывать про ecc, в nand физически будут записаны не нули.
vadimr
19.06.2022 23:14как это не относится?!? именно она создаёт write amplification, то есть определяет расход ресурса nand
Она определяет расход ресурса, но она не зависит от размера пустого места на логическом диске.
так было до появления trim.trim именно помечает данные как мусор для накопителя.
Не всё, что пометил trim, является мусором. А только то, что при этом имеет ненулевые биты.
да нет для накопителя такого понятия «сектор, заполненный нулями». для него это просто обычный сектор с данными
Вот те на. Да это и есть самое главное для накопителя.
есть «незаписанный сектор» (на который был сделан trim и после этого не было операций записи
Это тоже есть, но это выше уровнем. Уже логика контроллера. А то – схемотехническая логика.
почему их не придётся перетирать? придётся, nand не nor, не позволяет многократную перезапись одного участка.
Что, по-вашему, делает операция стирания страницы?
да если бы и позволяло, не надо забывать про ecc, в nand физически будут записаны не нули.
Битовую маску страницы можно подобрать таким образом, чтобы результат маскирования ecc от нулевой страницы сам был бы равен нулю. Так-то там и единицы вместо нулей означают стёртое состояние, поэтому надо делать байтам данных xor $ff, так как данные чаще бывают обнулёнными, чем объединиченными.
edo1h
20.06.2022 01:16Что, по-вашему, делает операция стирания страницы?
речь про то, что write каждой страницы после erase можно делать ровно один раз, после чего изменять эту страницу до следующего erase нельзя.
и erase нужно делать всему блоку целиком, неважно как много данных на него записано, так что записывая больше или меньше нулей мы никак не облегчаем или не усложняем накопителю работу.
Вот те на. Да это и есть самое главное для накопителя.
честно говоря, не понимаю, что вы хотите сказать.
Она определяет расход ресурса, но она не зависит от размера пустого места на логическом диске.
блин, ну как же так? уже сколько раз возвращались к этому вопросу, даже приводил картинку из сигейтовской статьи, в которой английским по белому написано:
TRIM enables the OS to alert the SSD about pages that now contain unneeded data so they can be tagged as invalid. When this is done, the pages do not need to be copied during garbage collection and wear leveling.
vadimr
20.06.2022 09:40речь про то, что write каждой страницы после erase можно делать ровно один раз, после чего изменять эту страницу до следующего erase нельзя.
Erase просто устанавливает на ячейках флеш-памяти высокий потенциал, соответствующий на схемном уровне логической единице, а на уровне интерфейса – двоичному нулю. Всё. Ничего больше. После этого этот высокий потенциал можно когда угодно скидывать в низкий операцией записи, формируя на интерфейсе двоичные единички. Хоть один раз, хоть миллион, но только от высокого потенциала к низкому.
и erase нужно делать всему блоку целиком, неважно как много данных на него записано
Конечно. Я поэтому и пишу о страницах, а не о блоках диска.
так что записывая больше или меньше нулей мы никак не облегчаем или не усложняем накопителю работу.
Если мы целиком заполним нулями страницу (то есть то, что обнуляет erase), то работу крайне облегчим.
блин, ну как же так? уже сколько раз возвращались к этому вопросу, даже приводил картинку из сигейтовской статьи, в которой английским по белому написано:TRIM enables the OS to alert the SSD about pages that now contain unneeded data so they can be tagged as invalid. When this is done, the pages do not need to be copied during garbage collection and wear leveling.
Я хорошо понимаю, что здесь написано, но не пойму, что вы хотите этим доказать.
Перемещаемые сборщиком мусора валидные блоки образуются в результате любых операций записи, а не в результате уменьшения свободного пространства в файловой системе. Если вы двадцать раз перепишете существующий файл (не сразу же, а постепенно в процессе жизни), вы получите в 20 раз больше мусора и двадцатикратную работу для сборщика мусора, а свободное место с точки зрения файловой системы при этом не изменится.
Поэтому если вы скажете, что операции записи уменьшают ресурс SSD, то я соглашусь, но это и так самоочевидно. А вы пустились доказывать, что ресурс уменьшается от уменьшения свободного места в ФС, и это неверно.
Свободные блоки ФС и свободные блоки контроллера SSD – совсем не одно и то же. Хотя команда trim и помогает выполнять работу по преобразованию первого во второе, но это не единственный путь появления мусора.
Фух. Не знаю, как ещё понятнее написать.
edo1h
20.06.2022 11:36Поэтому если вы скажете, что операции записи уменьшают ресурс SSD, то я соглашусь, но это и так самоочевидно. А вы пустились доказывать, что ресурс уменьшается от уменьшения свободного места в ФС, и это неверно.
прочитайте внимательнее что я писал.
смотрите, есть два ssd, A и B, каждый по терабайту, на каждом файловая система занимает весь раздел.
на этих ssd лежит одинаковая база данных размером, ну пусть 128 ГБ.
но на ssd A ничего больше нет, на ssd B помимо БД лежат картинки, которые не изменяются, файловая система занята на 99%.данные в БД меняются, и пусть, скажем, за неделю в БД переписывается 16 раз (то есть 2 терабайта записи).
так вот, в во втором случае waf будет гораздо выше, чем в первом, то есть, несмотря на одинаковый объём записи, износ накопителей будет разным.
vadimr
20.06.2022 12:16Я с этим выводом не спорю. Но вопрос тут не в свободном месте, а в длительно лежащих без изменения файлах картинок. Любые долго лежащие файлы блокируют страницы памяти под собой.
edo1h
20.06.2022 12:27Но вопрос тут не в свободном месте, а в длительно лежащих без изменения файлах картинок
нет, именно в занятом месте.
a. если бы мы переписывали эти картинки периодически (при это свободное место не менялось бы), то waf оставался бы столь же высоким;
b. если мы сотрём эти картинки (и trim работает), то waf для вновь записываемых на накопитель B данных будет таким же, как и для записываемых на накопитель A.
edo1h
20.06.2022 13:24После этого этот высокий потенциал можно когда угодно скидывать в низкий операцией записи, формируя на интерфейсе двоичные единички. Хоть один раз, хоть миллион, но только от высокого потенциала к низкому.
нет, для NAND это не работает.
вот, например:
Erasing a flash erase block sets all of its bits to 1s, and writing a write block (smaller than an erase block, but possibly bigger than a filesystem block) sets selected bits to 0s. One or two further writes to the block could be sustained if the bits being written to 0 were previously 1s in the write block. Writing a 0 to a bit which was already 0 risked making the 0 "stick", i.e. multiple erases could be needed to return the bit to a 1. Needless to say, this multiple-write practice was not generally tested and guaranteed by flash vendors, and cannot work at all on non-SLC flash technologies.более того, многие не-slc чипы требуют, чтобы запись в страницы шла последовательно, вот старая pdf от микрона, где это ещё как рекомендация:
Reducing Program Disturb
Program pages in a block sequentially,
from page 0 to page 63 (SLC) or 127 (MLC)
Minimize partial-page programming operations (SLC)
It is mandatory to restrict page programming to a
single operation (MLC)но на многих чипах, как я понимаю, это уже обязательное требование.
вот вам пример наступившего на эти грабли.и повторюсь, даже если перезапись нулевой страницы сработает, ecc не совпадёт.
ваша идея «для нулевого блока сделать так, чтобы данные и избыточностью были тоже нулевыми», уверен, не используется, обычно стараются избегать паттернов вроде0b0000…и0b1111…, которые могут случиться при аппаратном сбое.P. S. ну а если бы проблема записи нулевых байт волновала производителей ssd, то, уверен, они бы решили это путём приравнивания записи нулей к trim (а такого я не наблюдал на тех накопителях, что я тестировал).
vadimr
20.06.2022 13:57One or two further writes to the block could be sustained
Даже если так, это никак не меняет того факта, что стёртая страница уже нулевая (единичная).
P. S. ну а если бы проблема записи нулевых байт волновала производителей ssd, то, уверен, они бы решили это путём приравнивания записи нулей к trim
Их нельзя приравнять, так как нулевая страница с данными не является незначимой и не может быть перезаписана сборщиком мусора.
edo1h
20.06.2022 14:12Их нельзя приравнять, так как нулевая страница с данными не является незначимой и не может быть перезаписана сборщиком мусора.
какой ещё сборщик мусора? он работает с nand.
а неинициализированные сектора существуют только в ftl, в nand они не хранятся.
то есть нам достаточно пометить lba как неинициализированный и не писать его вовсе в основную область nand (ну а старую версию в nand, если она есть, отметить как мусор). именно это и делает команда trim.
теперь чтение этого lba будет возвращать нули (притом на хорошей скорости; пример я приводил, но он не особо показательный — встречал накопители, на которых чтение неинициализированной области в 2-3 раза быстрее чтения реальных данных).судя по тому, что массовые ssd не включают такую очевидную оптимизацию, разработчики сочли, что это редкий случай, не стоящий минимальных усилий.
vadimr
20.06.2022 14:17Так этот сектор не является неинициализированным. Он инициализирован и содержит нули. Туда, в отличие от неинициализированных секторов, нельзя ничего перемещать.
edo1h
20.06.2022 14:25omg… куда туда?
отношение страниц nand к lba в ftl не обязательно 1:1.
если lba помечен как неинициализированный, то ему не соответствует никакая страница в nand.
vadimr
20.06.2022 14:47Вы про что вообще говорите – про сектор ФС, про страницу NAND или про запись в таблице LBA?
То, что вы предложили, опирается на предположение, что неинициализированный элемент LBA будет при чтении давать нули. Такая опция называется DRAT (Deterministic read data after TRIM) или DZAT (Deterministic read zeros after TRIM) и реализована во многих накопителях. Проверить можно командой
sudo hdparm -I /dev/sda | grep TRIM
, в ответе будет
* Deterministic read data after TRIM
или
* Deterministic read ZEROs after TRIM
edo1h
20.06.2022 15:59То, что вы предложили, опирается на предположение, что неинициализированный элемент LBA будет при чтении давать нули.
а вам встречались иные примеры?
Такая опция называется DRAT (Deterministic read data after TRIM) или DZAT (Deterministic read zeros after TRIM)
эти опции не про то как будут читаться неинициализированные данные, а про то обязательно ли контроллер будет отмечать данные как неинициализированные, и будет ли он это делать сразу или может отложить.
дело в том, что изначально эти команды воспринимались как необязательная рекомендация, и разработчики контроллера могли принять решение в каких-то случаях ради лучшей производительности «срезать углы». например, sandforce так делали, после trim'а чистилась только часть данных.
edo1h
18.06.2022 19:34Вот есть у нас диск, занят на 99%. Чтобы равномерно изнашивать блоки — придется постоянно перемещать уже записанные данные, иначе ресурс записи у оставшегося 1% блоков исчерпается очень быстро.
судя по провалам в скорости чтения давно записанных данных на многих потребительских ssd, контроллер «особо не заморачивается» перемещением данных.
https://habr.com/ru/post/379235/
https://forum.ixbt.com/topic.cgi?id=11:48920:7828#7828
https://forum.ixbt.com/topic.cgi?id=11:49499:47393#47393я не говорю про производителей второго-третьего эшелона
DuD
18.06.2022 02:04+12Укажите в статье что такого нельзя делать на основном разделе. А то сейчас народ по незнанию побежит отнимать "награбленное" системой, а потом окончанию места будет вас же и проклинать. )
А то такого много можно насоветовать. "Отключайте fsync под базами, они будут быстрее работать!", "Используйте RAID0 вместо RAID1, так вы сэкономите кучу места!" и прочие облегчающие жизнь советы...
vikarti
18.06.2022 12:55Так ведь компании с большой капитализацией некоторые именно так и делают — см https://habr.com/ru/news/t/653527/
ALiEN175
18.06.2022 03:26+1а потом при занятых 100 Тб ext4 превратится в тыкву?
Переформатировав свои 100тб дисков, я получил дополнительные 5Тб дискового пространства, просто так, на ровном месте.
А если переформатировать в btrfs или zfs со сжатием, то еще получите как минимум 10ТБ, а в лучшем случае все 200.
BugM
18.06.2022 03:34+2На практике диски лучше вообще не заполнять больше 80% от номинальной емкости. Если вам важна скорость работы.
Куда и подо что там уйдут эти 20% на самом деле не важно.
AndreyDmitriev
18.06.2022 08:29Да, я на SSD обычно создаю небольшой "блокирующий" раздел, чтобы не забивать его под горлышко.
13werwolf13
20.06.2022 09:28таким образом вы делаете "хорошо" ssd
но у почти всех фс есть свои проценты свободного места меньше которых становится "медленно и грустно", так что лучше держать 20% свободным на разделе чем 20% на разделе + 20% вне раздела.
Sly_tom_cat
18.06.2022 13:30+1Я забивал диск на 99%+ процентов, и все ок...
Только там была BTRFS, которая хоть и имеет небольшой резерв, но он не для рута, а именно для самой ФС. Что позволяет даже при 0% свободного места не мешает удалять файлы, под-тома или даже делать НОВЫЕ снапшоты.
screwer Автор
18.06.2022 15:25Сейчас большая часть дисков заполнена на 99.9%. И никаких проблем с этим. Дисков уже 120тб. Жду ещё 40тб в этом месяце, чтобы свободное место появилось наконец-то.
BugM
18.06.2022 15:27Вы точно на них активно пишите и читаете? В моих тестах после 80% заполнения деградация скорости значительная и легко видна приборах.
screwer Автор
18.06.2022 16:58-1Пишу и читаю неактивно. Не более сотни гигабайт в день на диск. Т.е.особой разницы между 240 и 180 мб сек не замечу. Основная масса файлов - громадные блобы на десятки и сотни гигабайт.
BugM
19.06.2022 00:00-2Это 25% как бы. Для нагружённой системы это означает на 25% больше серверов для сохранения нужной производительности.
Это заметные деньги. Простить 20% емкости диска дешевле.
screwer Автор
19.06.2022 13:47Пусть даже 300Gb в день пусть при скорости 100мб/сек это час работы диска. Т.е. моем случае в разы меньше В скорость диска "в долгую" ничего не упирается. Кроме того, для горячих данных очень эффективно работает системный кеш.
А вот диски совсем недешевые. Это первые я брал по 25тр за 10тб (WD Gold KRYZ). Потом они подскочили до 100, благодаря чиа-майнерам, и, не успев полностью отыграть обратно, опять выросли до сегодняшних 50тр, вопреки циферкам курса
Эти сервера - мои личные, домашние. Купленные/собранные за собственные деньги
Для быстрых данных у меня есть несколько дисковых полок, по 25 600гб 10к дисков в каждой. Но пока vendor lock я с самих полок не снял, только с дисков.
myc
19.06.2022 00:38+1Заливаю диски под завязку. И никаких проблем с этим. Дисков уже несколько сотен петабайт. m=0. НО! Данные эти статичны и почти не перезаписываются.
Фрагментация при нехватке места бич любой фс. На hdd это смерти подобно. На ssd не так критично. Там другой подход — значительно увеличиваем зону OP, при этом сокращаем резерв фс.
ALiEN175
18.06.2022 03:53+25И уберите кликбейт заголовок. Я сразу подумал про 5 ТБ облако, а не ваши несчастные 5% от 100 Тб.
Как просеренить у себя 5 терабайт свободного места, не читая man.
Или вы готовы всем желающим раздать 5 Терабайт? Как в заголовке — нахаляву?
justPersonage
18.06.2022 14:04+5Или вы готовы всем желающим раздать 5 Терабайт? Как в заголовке — нахаляву?
Я по заголовку, думал, что где-то диски раздают, как книги, бесплатно.
aik
18.06.2022 09:04+2Tune2fs — и не надо ничего форматировать.
На системных разделах, впрочем, в ноль резервирование убирать не стоит.
kvazimoda24
18.06.2022 09:52+7Что же с вами будет, когда вы осилите мануал mkfs.ext4 и узнаете о возможности уменьшить размер инодов с 256 байт, до 128 и о возможности задания количества этих самых инодов. Ведь, по умолчанию mkfs создаёт очень сильно с запасом инодов, и на моей практике всегда можно сильно уменьшить их количество. В целом, практически всегда хватает 5 миллионов с хорошим таким запасом.
Но предупреждаю, что тут надо действовать обдуманно, т.к. увеличить их количество можно только переформатированием раздела.
А ещё в Дебиан есть пакет ядра linux-image-cloud-amd64. Он занимает всего 20 МБ, для сравнения, классическое ядро, что ставится по умолчанию, весит около 700-800 МБ. Это ядро можно использовать в KVM виртуалках, если сеть и диски у них virtio, и вы не прокидываете реальные устройства устройства в виртуалку.
v1000
18.06.2022 09:54+5Только вот иногда люди не следят за количеством свободных инодов. И однажды база на полном ходу грохнулась из-за нехватки инодов. При этом свободного места на дисках хватало. Но вот про иноды немного забыли.
kvazimoda24
18.06.2022 09:58+2Я потому и написал, что надо быть аккуратным.
У нас мониторится количество свободных инодов и уже были случаи, когда наши програмисты косячили, и приложение начинало генерить безумное количество файлов. Отловили именно мониторингом инодов, т.к. размер у файлов был околонулевой.
SilverHorse
18.06.2022 10:53+6Знаете, это просто офигенная тактика написания статей на хабре. Буквально вчера у меня в трекере всплыла https://habr.com/ru/post/339470/ про это самое из-за некропост-коммента, я прочитал, хмыкнул, закрыл. Походу у автора, как и у многих других, оно тоже всплыло в трекере, для него это стало открытием, он проделал описанное в статье на своем кластере, обалдел от результата... и решил написать про это свою статью? Я открываю "читают сейчас"... и испытываю когнитивный диссонанс вместо со странным дежа вю. Автор, все новое - хорошо забытое старое?
Я понимаю, что это очередное нытье про "хабр - не торт", но имейте совесть уже, тем более что "статья" про содержимое man в линуксовой утилите, ну е-мое, дальше уже снизу стучать начнут...
vassabi
18.06.2022 15:25+1комментарии зато замечательные! (про другие способы "чо порезать" и свои любимые ФС :) )
Sly_tom_cat
18.06.2022 13:23+1Вы уж извините, но если сказали раз, то скажите и два.
EXT2-3-4 еще и по i-node выделяет овер-дофига места при форматировании.... и поменять позволяет только в сторону уменьшения.
Но, тут еще большой вопрос - стоит ли это менять? Ведь если будет 100500 мелких файликов то i-node не хватит. Но если на этом огромном диске лежат крупные файлы - то резерв i-node будет практически неиспользован.
ЗЫ А можно еще и три сказать: эта ФС - ИМХО уже слишком устарела. Там во внутренних структурах еще куча очень странных решений, мягко говоря не рассчитанных на диски большого объема. Я бы подумал над использованием XFS или BTRFS - там решения изначально принимались гораздо болееразумныеподходящие для больших дисков. Одно то, что (даже без резерва рута) EXT-4 резервирует сразу после форматирования под собственные нужды ~1,6% диска (вне зависимости от его размера), а вот XFS/BTRFS резервируют сущие копейки (меньше 0.2% на 1Gb) и с ростом размера диска этот процент еще сильнее уменьшается. И это в частности потому что никто уже давно не резеревирует i-node заранее а создают и утилизируют их по ходу работы. И проблеммы "на диске есть место а файл не записать" в нормальных FS не возникает.
SporeMaster
18.06.2022 15:01+3>И никто из моих знакомых-линуксоидов не знал.
Ужасные знакомые, ужасная статья. Про tunefs сразу сказали, можно ещё добавить, что смысла трогать эту крутилку нет, т.к. в реальной эксплуатации
руту всё равно даёт писать до 100%
когда кончается место, то уже на и 90% надо докинуть дисков. Маргинальные случаи со статичной помойкой где 1 раз заполнили на 99.99% и ничего не меняется слишком редки.
A1EF
18.06.2022 22:07Более того, несколько раз меня очень выручило это резервирование когда СРОЧНАА нужно было докинуть хоть чуть-чуть места и взять его было больше неоткуда.
Balling
19.06.2022 07:24>На логи, да!
Не на логи, а на ФС, туда ничего не пишется и вообще не трогается. Файловая система по умолчанию такая отвратительная, что ей нужно свободное место или она замедляется очень сильно. Так как в отличии от windows, защита от фрагментирования работает методом а "давай напишем прям в центр свободного места". Поэтому в конце ей нужно свободное место посредине всех нефрагментированных файлов.
У автора видно было не все в порядке.
idelgujin
20.06.2022 05:37+1Кликбейтный заголовок. Не 5 Тб дисков, а 5 Тб дискового пространства в имеющемся массиве. Это большая разница
DNolde
20.06.2022 17:13Раньше на UNIX (SunoS, Solaris, Irix) резервировалось по дефолту 10% места. Достаточно один раз установить диск в компьютер, посмотреть на результат и сразу запомнишь опцию -m.
ValdikSS
20.06.2022 21:18mkfs.ext4 -O '^resize_inode'отключит резервные inode, которые выделяются для возможности их добавления при ресайзе диска в сторону увеличения. Если вы не собираетесь ресайзить файловую систему, то эту опцию можно безболезненно отключить.mkfs.ext4 -N 1000000статически задаст количество inode'ов — это основной элемент, «расходующий» свободное место диска и увеличивающийся с его размером.mkfs.ext4 -T largefileзадаст тип файловой системы в "largefile" — оптимизация распределения и количества inode'ов под конкретный сценарий использования. Возможные значения и их конкретные параметры смотреть в /etc/mke2fs.conf.
goletsa
Мне кажется, или процент резерва легко меняется через tune2fs без форматирования?
screwer Автор
Видел, но не пробовал. Вполне возможно что я тогда пошёл сложным путём.
Popadanec
А проблема с размерами дисков в разнице систем отсчёта. В магазине продают гигабайты, а система отображает гибибайты.
vitaly_il1
абсолютно точно!