Комментарии 243
Мне кажется, или процент резерва легко меняется через tune2fs без форматирования?
Видел, но не пробовал. Вполне возможно что я тогда пошёл сложным путём.
Но, почему-то, оперативную память продают в гигабайтах и отображается она в гигабайтах и её ровно столько, сколько написано!
Почему с дисковыми накопителями иначе?
Да и в линуксе судя по комментам та же ситуация.
А вы не думали что приставка Гиги вообще появилась (про неё узнали) сильно позже чем western digital (вроде бы с них началось) начали писать на коробочке диска 100000000 байт....
А сам стандарт был принят только в 1999 году, но что-то не помню чтобы кто-то в 2000х их применял....
Жертва ЕГЭ? Про международную систему единиц СИ не в курсе?
Это признание?
Я то школу заканчивал ещё до ЕГЭ ;)
И даты написал исходя из добавления этих приставок в ту самую м. СИ...
Причём поленился перепроверить(хотя я не информацию(странно вы же ит-аналитик, ваша работа же должна быть связана с анализом информации) или по вашему мнению СИ это что-то принятое в каменном веке и не изменяющееся со временем?
абсолютно точно!
Linux утилита mkfs.ext4 (ext2/ext3/ext4) имеет параметр -m, о котором мало кто знает.
Выросло поколение, man не читающее. (Бурчит себе под нос).
Как показал 1,5 года назад мой беглый опрос - нас таких, не читающих, много (((
Причём некоторые с Линуксом больше 25 лет. Так что - вдруг кому-то пригодится, уже польза.
Часто на проверку оказывается, что это не 25 лет опыта в линукса, а 1 год опыта работы с линуксом 25 раз. Да и в цифре 25 сильно сомневаюсь. Скорее не больше 20
Часто на проверку оказывается, что это не 25 лет опыта в линукса, а 1 год опыта работы с линуксом 25 раз.
Вы не правы. ИМХО можно хоть всю жизнь быть с линуксом, и прекрасно обходиться без обсуждаемой опции.
Скорее не больше 20
Ну давайте посчитаем... С тем человеком я работал в 2003-2005 годах, он уже тогда пришёл на должность главного админа большого предприятия. >2000 человек, ~200 компьютеров, полсотни сетевых принтеров, ИП телефония, 2 оракловых сервера, файловый сервер на FC, 30 терминальных серверов, куча цисок, распределённая сеть между офисом (город) и производством (область). Это было почти 20 лет назад. По его словам его путь с линуксом начался ещё с 1.0, выкачиваемом в 90е по диалапу, и ручной сборкой. ЕМНИП тогда сам линукс ещё был в младенческом состоянии, версия ядра 2.2 или 2.4, однозадачного как ДОС (я имею в виду, что внутри ядра preemting не работало). Точно помню, что мы тестировали разные версии ext файловых систем. Тупым тестом на СИ, который я написал, создающем в многопотоке файлы/каталоги, читающем, пишущем и удаляющем их. В итоге попсовые ФС тогда тупо разваливались уже после нескольких часов такой нагрузки. По-моему это была ext2, но за давностью лет уже зуб не дам. Что выбрали в качестве стабильной ФС тоже не вспомню. Просто зарисовка, в каком состоянии тогда было Linux окружение.
Странно, что он не знал. Может он не знал именно про опцию '-m' ?
У меня примерно такой же опыт общения с linux, с 90-х. Опция резервирования места регулярно спасала при тогдашних объемах дисков.
ой, чуваки, не спорьте, в жизни и не такое бывает. в 2010 я встретил сисадмина-эникейщика туристической фирмы уже в годах, который не знал, что такое Ubuntu (линукс-дистрибутив). можно работать всю жизнь без знаний, без которых кто-то другой не представляет себе жизни.
Иногда что-то забывается, когда этим редко пользуешься.
Я очень давно форматировал диски в Linux, и я только недавно тоже вспомнил про опцию резервирования места, хотя и узнал про неё давно.
Двадцать пять лет назад, если система не досталась волшебным образом в дар вместе с обслуживающим её человеком, установка, настройки и использование линукса предполагали изучение огромного количества документации, в том числе tune2fs. По крайней мере двадцать лет назад мне не удалось этого избежать. В те годы многие, воспринимаемые сейчас как само собой разумеющиеся, вещи были удивительны в настройке, например монтирование или проверка дисков, что заставляло RTFM. В те времена каждый мегабайт был на учёте, и, например, потеря целых 200 мегов на моём 4,3 гигабайтном фуджике не могла пройти незамеченной уж никак. Да и восемь лет назад коллега при переходе с винды довольно быстро заметил эту особенность с резервом, что характерно, сам.
почему?
1996год,redhat4.
1994vax/vms,dec_alpha...
2.2&2.4=конец90х.
Соглашусь с ТС скорее. ДевОпс тому прекрасный пример: специализированный набор утилит, который нигде, кроме девопса, не используется. В большинстве своем отсутствие базовых знаний (ведь зачем знать, как работает акпп, чтобы ездить на машине.
Зато потом огромный процент людей спрашивает: а что будет, если ревер тыркнуть на ходу?)
После прочтения вашего комментария мне захотелось узнать и то, и другое.
На автомате / вариаторе / роботе ничего не будет. Давно проработана защита от дурака. Если хватит сил перевести селектор, АКПП перейдет в нейтраль, и после остановки автомобиля включится задняя
У меня жена воткнула как-то раз на ходу заднюю на вариаторе (Nissan X-trail, 31 кузов). Был весьма неприятный звук типа как на шуруповерте проворачивается головка на заблокированном шурупе "крррак", только сильно громче. Вроде не сломалось, но я хз, какие последствия были, машину вскоре планово продал.
Так ведь на гидротрансформаторе сил никаких не надо. :) Просто тормоз чуть нажать и переводи в любую позицию.
Но да, пакеты разожмутся, будут в, мягко говоря, шоке, мозги будут долго думать "ЧТО ЖЭ ДЕЛАТЬ?!" и ждать момент "Ну вот сейчас", когда скорость станет +- возможной для подтыкания задней, и опять можно будет собрать этот конструктор Лего вместе (:
Если посмотреть на схему работы того же вариатора, то размыкания гидротрансформатора недостаточно а т.к. электронное управление не совсем чисто электронное, то и выходит вот этот хруст как указал @safari2012
А на МКПП что будет? Вчера случайно попробовал: хрустит и не втыкается (усилий не прилагал).
Задняя без синхронизаторов, попробуйте с двойной перегазовкой.
Я случайно втыкал на ВАЗ 2109. Там её было сравнительно легко перепутать с первой: первая - влево и вперёд, задняя - влево преодолевая "щелчок" и тоже вперёд.
Так вот. Замедляюсь перед выездом на шоссе, плавно тормозя двигателем на второй передаче. При скорости около 5-10 км/час переключаю на первую, чтобы тронуться и встроиться в поток когда появится возможность. Но вместо первой втыкаю заднюю. Воткнулась. Дальше отпускаю сцепление (но газ давлю не сильно, т. к. надо ещё чуть докатиться) и двигатель глохнет.
Было это лет 15-20 назад. Последствий не было, машина ещё более пяти лет проездила у меня и у родственников.
Нужно ооооочень хорошо стараться.
Но вообще, не раз обсуждалось. Если хочется уж совсем подробно: идём на ютуб и смотрим интересующее видео. Например у того же крашеного (Асафьева) было на эту тему: "Всё, что ЕЩЁ вы стеснялись спросить про авто". Где-то в конце видео (:
Жена друга, однажды, так сделала. На Ниве. Звук был очень неприятный, но на СТО сказали что всё ок. Коробка потом ещё 5 лет отходила, дальше не знаю -- машину продал.
Чо уж, я сам-то узнал про факт, описываемый в посте, так: мой тогдашний руководитель отдела обратил внимание, что на серверах сразу после установки операционки свободное и занятое место не согласуются с суммарным объемом. Я отмахнулся, мол это приколы перевода объемов в степенях двойки и десятки скорее всего. Он полез разбираться и нашел про это самое резервирование и как через tune2fs подвинуть. Я добавил себе в копилку знаний и на будущее взял на заметку впредь быть повъедливей:)
Если какая-то вещь создана таким образом, что о ней нужно читать, значит о прочитанном будет обязательно забыто. Слишком уж много в мире теперь писатели пишут. Печально, что в линуксе нужно читать и про логи, и про форматирование. Базовые вещи, которые должны быть хорошими "искаропки"
Юзер:
У меня ошибка:
FileNotFoundError: [Errno 2] Нет такого файла или каталога: 'C:\\Program Files (x86)\\K-Lite Codec Pack\\MPC-HC64\\mpc-hc64_nvo.exe'
Тут скрипт требует K-Lite Codec Pack, но его нету на linux по этому пути
А вы говорите — man читать… Я после такого вообще в шоке был.
Тут скрипт требует K-Lite Codec Pack, но его нету на linux по этому пути
Т. е. как минимум с:\\ у него в линуксе - ЕСТЬ?!
Ну wine же. Непонятно только нахера такие извращения
Нет его. Не находит ни "диска", ни файла, скорее всего.
В том и суть, кроссплатформенный проект, запущенный в линуксе, ищет нечто по виндовому пути, оказываясь совсем не кроссплатформенным проектом (и, вполне возможно, плохо спроектированным архитектурно, ибо прослойка работы с OS должна быть изолированная и покрытая тестами).
Пользователю было указано на существование настройки, но он это проигнорил и сказал, что это баг :)
Так попросил-бы поискать внимательнее)
Помню среди профеcсионалов была популярна побуждающая аббревиатура RTFM...
Вы ещё журнал не пробовали отключать. И резерв самих контроллеров диска :)
Эти оба-два чреваты потерей данных. В отличие от ненужного (для дисков с данными) резерва под логи.
tune2fs -r "$((300*1024*1024/$(tune2fs -l /dev/sda1 |grep "^Block size:" | cut -f2 -d ':' | xargs)))" /dev/sda1АВТОР ЭТОГО WISYWIG УМРИ!
Отключать резервирование не надо, иначе даже от рута не залогинитесь. Третий раз писать почему, не буду, редактор отстой. Я ставлю резерв 300МБ.
Напомню, что речь идёт о дисках с данными. Не о рутфс. Причем тут "залогиниться" ?
Всё равно пространство для манёвра оставлять надо, если надо будет провести архивацию старых данных (например логи в текстовом режиме писали), то хоть на пол шишечки место не повредит, а жадничать 300 метров это уже ту мач в современном мире.
При том, что когда системные демоны запускаются, им иногда надо создавать файлы - pid-файлы, локальные unix domain sockets. Если места ноль, может не получиться, и система уже не поднимется. При нынешних объемах дисков конечно 5% это до фига. Можно и меньше поставить.
Лучше вот так, мне кажется:
DRIVE=$( mount | grep 'on / type' | cut -d ' ' -f1 )
tune2fs -r "$((300*1024*1024/$(tune2fs -l "$DRIVE" |grep "^Block size:" | cut -f2 -d ':' | xargs)))" "$DRIVE"
P.S. У меня просто /dev/sda1 под EFI отдан, а так спасибо, хороший однострочник.
Root не имеет права использовать это пространство тоже. Только что проверил, apt-get update не имеет права писать в эти 5%.
Это был сарказм, если что :)
Более интересный вопрос – зачем вообще использовать ext в сегодняшних реалиях.
А какой фс сейчас пользоваться более модно, если не ext4?
SUSE, например, рекомендует btrfs для корневого раздела и xfs для данных. Никогда особо над этим не задумывался и просто так и делал.
уже точно можно?
я просто немного консервативен, btrfs стоит на backup потому что не жалко жмёт не плохо - вроде нормально
Лет 10 пользуюсь везде, проблем не было.
Журналирование - полезная вещь. Опять-таки, можно будет написать статью, как пропуржить журнал :)
btrfs однозначно ДА
10 лет назад в случае мигнувшего питания или проблем с hba она превращалась в тыкву без возможности восстановить данные, сейчас это стабильная и очень фичастая фс
а вот xfs я бы не советовал тем кто не уверен на 100500 процентов в том что его сервер/компьютер/ноут будет ВСЕГДА graceful shutdown. так что если не нужна фичастость btrfs то лучше ext4
ну а из фич btrfs лично я юзаю:
1) подтома
2) сжатие (после перехода на zstd оно перестало оказывать влияние на скорость чтения/записи)
3) массивы (да, да.. как в zfs, только аналогов zvol нету пока)
4) снапшоты (накосячил кривыми ручками что-то, бах и откатился в рабочую систему, нраися..)
CoW конечно дико фрагментирует данные на диски, но в отличии от винды в линуксе это как-то незаметно влияет на скорость работы даже на медленных блинах 5400rpm, ну а на ssd всё это вообще не играет роли. Ну а если прям хочется то CoW можно и отключить
Фрагментирование не может не оказывать влияние на скорость чтения hdd.
При этом тип, вид или род операционной системы тут вообще не важен - траектория движения физических головок от этого не меняется.
Если у Вас в системе ни чего не меняется при возрастании фрагментации - значит она у Вас тормозит на каком то другом узком месте изначально и до влияния дисковой подсистемы просто не доходит.
btrfs убивает любые ssd постоянной записью. Это факт.
По этому целесообразность выбора этой файловой системы в 95% случаев под большим вопросом....
пару раз
это вам просто повезло
а по поводу:
начало сильно тормозить IO
могу только спросить "а в чём причина то была?". потому как если причина неизвестна то очень может быть что дело и на в ФС совсем, а например в прямоте рук..
BTRFS весьма фичастая, а это значит что она даёт чуть больше свободы в плане выстрела в ногу, а с дуру можно и.... ну вы поняли.
Полгода назад статья же выходила что btrfs высаживает диски быстро, потому что постоянно чтото пишет и переписывает в гораздо большем объеме чем надо.
zfs
Пользую zfs. Прозрачная быстрое сжатие (lz4) сжимает диски моих виртуальных машин в два раза не учитывая thin provisioning, но безполезно для видео и музыки. С другой стороны zfs плохо работает без 20% пустого места. Btrfs тоже сжимает и вообще прогрессивна, но крэшила мне виртуальные машины и вообще сожрала мои тестовые данные два года назад. Пользуюсь zfs из-за удобного управления местом, снэпшотов, умного рейда и репликации.
Прозрачная быстрое сжатие
Вот и тема для следующей статьи. На этом, в зависимости от данных, можно поболее жалких 5% выиграть. Но вроде современные дистрибутивы по умолчанию включают эту опцию в zfs и btrfs.
Не только сжатие, но и дедупликация. В некоторых сценариях может оказаться, что дублей достаточно для солидной экономии.
Хотел использовать OpenZFS на Mac, но ленивая жопа не стал разбираться с CLI, а GUI не работал. Выбрал дедупликацию сторонними средствами для APFS и для свалки обнаружил ощутимый прирост свободного места.
выиграть можно, но какой ценой ?
Я поставил один 6тб диск "поиграться", разметив его в ZFS. Сжатие и дедупликация дают великолепную экономию места. Но как же это всё тормозит! Даже удаление сотни гигабайт файлов занимает несколько часов. А заливка пары террабайт длилась почти сутки. И это на виртуалке с 48 процессорами и 128гб озу! Вообщем пользоваться этим "по-дефолту" невозможно, надо как-то тюнить производительность.
Ещё был сюрприз, при переносе диска из Ubuntu18 в Ubuntu22. Пул стал, внезапно, degraded. При переносе обратно - всё отлично, online. scrub не помог.
Сжатие и дедупликация дают великолепную экономию места. Но как же это всё тормозит! Даже удаление сотни гигабайт файлов занимает несколько часов. А заливка пары террабайт длилась почти сутки. И это на виртуалке с 48 процессорами и 128гб озу!
странно, использую zfs на бекапном сервере.
каждую ночь на него заливается около 10 терабайт, никаких проблем.
другое дело, что дедупликацией пользоваться можно только очень осторожно, но про это, вроде бы, на каждом углу написано.
Но как же это всё тормозит! Даже удаление сотни гигабайт файлов занимает несколько часов. А заливка пары террабайт длилась почти сутки.
Я уже много лет использую zfs (в том числе и как rootfs).
Описанных проблем не встречал, хотя доводилось и удалять и заливать сотнями гигабайт.
Какие альтернативы вы предлагаете ?
Решение по умолчанию, в общем. Все эти зфс и бтрфс — только если нужны их фишки.
Встречный вопрос: а чем плох ext4? Если не рассматривать какие-то очень специфичные сценарии, конечно.
нет снапшотов
нет управления томами и ресайза в онлайне
нет сжатия
нет сopy-on-write
не оптимизирована для SSD
Для меня уже и первого пункта достаточно. Второй тоже важен при смене оборудования. В btrfs можно в пределе даже переехать с одного физического диска на другой, не останавливая работу системы.
В btrfs новая версия файла не затирает старую, что может оказаться важным в случае неприятностей.
Ну всё можно так или иначе делать костылями. Снапшот-то вообще не занимает времени и не требует дополнительного диска.
Одно дело, когда у вас отметка снапшота выполняется мгновенно, а другое – когда будет шерстить весь диск и сбрасывать изменения, пусть даже это и SSD.
не оптимизирована для SSD
можно пример фс, эффективно оптимизированной под ssd?
APFS, например
А, возвращаясь к теме, та же btrfs по-разному строит структуры данных на HDD и SSD.
А, возвращаясь к теме, та же btrfs по-разному строит структуры данных на HDD и SSD.
и даёт ли это какой-либо измеримый эффект?
Я не мерял. Теоретически ресурс должен быть больше.
погуглил, основное (единственное?) отличие в режиме 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.html
Не, там другое дело. Речь идёт о дублировании служебных блоков, и определяется это не по устаревшей опции монтирования ssd, а непосредственно по запросу типа диска (cat /sys/block/sda/queue/rotational)
вы про это:
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.
Если учесть, что SSD в принципе пофигу как там что расположено, то зачем делать разные структуры?
ну не совсем пофиг.
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-хранилищами, например.
Для SDD - беречь ресурс записи.
Для HDD - уменьшать задержки на позиционирование.
Также, например, дублирование управляющих структур на SSD не имеет смысла, так как контроллер выполняет дедупликацию.
так как контроллер выполняет дедупликацию.
нет. во всяком случае мне такое не встречалось.
можете сами взять и проверить, у fio есть специальный флаг refill_buffers
Не очень понял Вашу мысль. С refill_buffers fio ожидаемо выдаёт более плохой результат.
какой накопитель и какие точные параметры тестирования? можеть быть у вас в процессор упирается? (если вы не указываете 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=0
Mac 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
так я говорю, вы измерили накладные расходы на генерацию 8к рандома в одном потоке. при этом вероятную дедупликацию вы не протестировали, так как с дефолтными настройками fio меняет несколько байт в каждом запросе чтобы помешать дедпуликации.
На самом деле я ещё в прошлый раз по ошибке всадил randread вместо randwrite :(
Вот правильные результаты:
fio --scramble_buffers=1 jobfile.fio
random-rw-test1: (g=0): rw=randwrite, bs=(R) 8192B-8192B, (W) 8192B-8192B, (T) 8192B-8192B, ioengine=psync, iodepth=32
WRITE: bw=64.5MiB/s
fio --scramble_buffers=0 jobfile.fio
random-rw-test1: (g=0): rw=randwrite, bs=(R) 8192B-8192B, (W) 8192B-8192B, (T) 8192B-8192B, ioengine=psync, iodepth=32
WRITE: bw=298MiB/s
Разница от дедупликации почти в пять раз!
Upd: Всё, я не могу поставить методически корректный эксперимент. Поскольку блоки, записанные ранее, физически остаются на SSD, то при каждом новом запуске fio результаты всё улучшаются, независимо от параметров. Уже до 432MiB/s дошло.
Возможно, помогло бы после каждого запуска обесточивать компьютер, но на такой геморрой идти не хочется.
Во всяком случае, качественно можно оценить, что производительность записи на SSD крайне зависима от предыстории.
Поскольку блоки, записанные ранее, физически остаются на SSD, то при каждом новом запуске fio результаты всё улучшаются, независимо от параметров
честно говоря не понял, что значит «блоки остаются на ssd».
Ну я же создал тестовый файл при помощи fio. Его содержимое никуда не делось с ssd, когда я этот файл стёр перед следующим запуском программы. Когда я второй раз запускаю программу, она генерит такие же блоки с теми же контрольными суммами (хотя они и разные от блока к блоку, но всего их ограниченное число), это ловит алгоритм дедупликации в контроллере SSD и просто использует блоки, записанные при прошлом запуске программы, вместо того чтобы писать ещё раз.
Его содержимое никуда не делось с ssd, когда я этот файл стёр перед следующим запуском программы
а как же trim? или он в apfs сильно отложенный?
это ловит алгоритм дедупликации в контроллере SSD
не верю.
- алгоритм дедупликации требует кучу памяти (а на накопителях обычно впритык ftl разместить);
- дедупликация требует чтения найденного дубля для верификации совпадения (может же оказаться, что обнаружилась коллизия). так что стоит ожидать скорее падения скорости, чем прироста.
меня смущает, что вы работаете с файлом, а не с устройством, возможно, вы столкнулись с какой-то особенностью apfs
Trim просто говорит о том, что данные в блоке не нужны компьютеру. Он не приводит к их стиранию.
Работа 2010 года. Сейчас это уже общее место.
На HDD c APFS такого эффекта нет, там более-менее ровные времена доступа с производительностью около 10 MiB/s. Чуть быстрее с разными блоками, как и у Вас (думаю, это связано с тем, что файл из одинаковых блоков организуется как sparse и тратится время на алгоритм компрессии).
У APFS есть copy-on-write, возможно она слишком умная?
APFS - это Apple File System? Если да, то где это вообще есть, кроме Apple?
Интересно было услышать именно в контексте Linux: какие файловые системы лучше "оптимизированы под SSD" и конкретно в чём эта оптимизация выражается?
f2fs, btrfs, zfs - изначально имели оптимизации для ssd, остальные фс тоже уже подтянулись
Про тома и снапшоты: lvm2+ext4. Понимаю, что это вряд ли прозвучит убедительно плюс тащит лишнюю сущность, но на моей практике это частая комбинация. XFS вообще умеет только расширяться. К btrfs же я просто предвзят. Огрёб как-то проблем несколько лет назад, желание продолжать отпало.
не оптимизирована для SSD
давно уже оптимизирована, почти все существующие ФС получили оптимизации для работы с ssd. в какой фс эти оптимизации оптимизированней вопрос конечно открытый, но говорить что фс не оптимизирована для ssd это крайне неверно.
Многие из этих задач можно решить на уровне блочного устройства, практически без содействия драйвера файловой системы. Точно ли этот набор потребностей достаточен для переезда с ext4 на btrfs?
Если бы меня спросили, почему стоит использовать btrfs, я бы вспомнил про btrfs send.
ИМХО нужно использовать ту filesystem, которая по умолчанию в дистрибутиве.
Вспомнилось, как на заре Гугла там писали данные только на внешние дорожки дисков (дальние от центра), ибо, скорость чтения там выше так, как, физически, область под головкой там движется быстрее при одинаковой скорости вращения шпинделя. Что позволяло им иметь SLA по скорости линейного чтения/записи выше, чем без таких приколов.
А это было критично (тут уже не знаю, а предполагаю), видимо, потому, что они практиковали массивно-параллельные архитектуры до того, как это стало мейнстримом, и, соответственно, все воркеры ждали самый медленный диск (тот, на котором данные лежат ближе к центру), что приводило к простоям
Переформатировав свои 100тб дисков
просто так, на ровном месте.
tune2fs -m 0 /dev/sda1
Ext файловые системы вообще очень жадны к резервируемому пространству под файловые структуры. Таких проглодитов в мире айти я больше не видел. 20 гиг под файловые структуры на терабайтном диске? а пжалста
Нет, ее сильно меньше. Только в ext идиотская разбивка на блоки, в каждом из которых зарезервировано место под битмапы и прочую служебку. Разбивка очень "густая", блоки мелкие. Минусаторы могут детально изучить структуру файловой и глянуть ее с помощью какого-нибудь средства визуализации/подсчета занимаемого места. А, еще минус Ext - он равномерно "размазан" по всему носителю. При восстановлении данных нам это доставляет мнооого проблем. NTFS - вся мета (почти) в одном метафайле, обычно компактно лежащем в одном месте. FAT|exFAT - мета размазана по носителю, но там где она нужна, а не как в Ext.
PS: все то идиотство в Ext тянется исторически с дремучих времен с цилиндрами и другими архаизмами...
Contig v1.8 - Contig
Copyright (C) 2001-2016 Mark Russinovich
Sysinternalsc:$Mft is in 403 fragments
c:$Mft::$BITMAP is in 318 fragments
SSD. Диску около года. Только w10 и больше ничего. Свопа нет, гибернация отключена, все времянки в другом месте, оперативки 32 гига с первого дня. Так что "компактно в одном месте" это что-то не про нашу реальность.
Сколько там десятков гигабайт в mft?
По дэфолту MFT начинает фрагментироваться при заполнении диска более 87,5%. Похоже, вы перестарались с оптимизаторами и уменьшили в реестре резерв непрерывного пространства за MFT.
Крутить NtfsMFTZoneReservation особого смысла нет, т.к. это не жёсткий резерв пространства в целом, а лишь задание зоны, которая будет использоваться в последнюю очередь.
Я ничего не делал вообще. Вы вообще прочитали условия? 32 гига оперативки. Даже будь я конченным извратом, который в принцие способен применять какие-то-там оптимизаторы, за год нельзя засрать систему так, что бы они потребовались.
Фактически на этом компе установлены только SoftMaker Office, Vivaldi и WACUP. Причем все они установлены на второй раздел и все данные которые они используют находятся на втором разделе.
P.S. Почему на офисной читалко-писалке 32Гб? "Патамушта" Осень прошлого года, переизбыток комплектухи у конкретной фирмы, низкие цены. По этой же причине там и 5750G.
а если проверить $secure?
Переформатировать 100 ТБ... Это ж сколько времени ушло на копирование данных с каждого диска и обратно на диск? Прямо жалко автора)
Строго говоря, я бы вообще не рекомендовал бездумно менять дефолтные параметры файловых систем без чёткого понимания того что, как и зачем меняется и чем это чревато.
Ещё это нужно потому-что если на /tmp занято 100% (или /var), то даже root в эту систему не пробьётся через SSH.
Тут можно отметить, что для SSD вопрос фрагментации совершенно неактуален.
для SSD вопрос с резервированием гораздо более актуален.
Потому что надо обеспечить равномерный износ блоков. Если свободного запаса нет - придётся эти блоки сначала освободить, что удвоит нагрузку по записи, и удвоит износ ССД.
Освобождение блоков не требует операции записи в случае наличия у фс понятия о TRIM.
А равномерностью износа занимается контроллер SSD.
Причем тут trim ? Вот есть у нас диск, занят на 99%. Чтобы равномерно изнашивать блоки - придется постоянно перемещать уже записанные данные, иначе ресурс записи у оставшегося 1% блоков исчерпается очень быстро.
Если же свободно 50% можно особо не париться (до некоторого момента) и размазывать записи по ним.
Трим же для понимания контроллеру, какие записи свободны, а какие нет.
Блоки перемещает при записи сам контроллер, компьютер про это не должен думать.
Речь не о том, кто перемещает. А о влиянии свободного места на ресурс.
Так именно поэтому свободное место не влияет на ресурс.
Ну как же не влияет. В изначальном примере - если записывать-стирать данные, когда свободного места почти нет - что должен делать контроллер ? Жонглировать только пустыми блоками ? Тогда их ресурс исчерпается очень быстро.
Их ресурс исчерпается, но ресурс других за их счёт сохранится. Сумма не изменится.
Так на сумму плевать, если мы сожгем 1% свободного и весь резерв при однократно записанных 99% остальных областях диск все равно уйдет в помойку.
Надо уж очень сильно постараться, чтобы реализовался такой сценарий. Годами не трогать 99% содержимого диска.
Речь-то изначально шла о совсем другом – что само по себе высокое заполнение диска якобы вредно, и поэтому его не допускает файловая система. А не о том, чтобы отлёживать на SSD однократно записанные данные, используя его в режиме CD-R.
И кстати, если уж на то пошло, описанные в статье 5% резерва не спасут отца русской демократии от такого сценария.
Это неправда. Файловая система просто пометит bed-ы. Плюс у них есть резерв ячеек, недоступный пользователю.
После какого-то кол-ва износа диск блокируется на запись, да.
Так именно поэтому свободное место не влияет на ресурс.
неправда.
посмотрите, чем различаются одноплатформенные накопители с ресурсом dwpd=1 и с dwpd=3
samsung pm1733 3.84 TB: 1 dwpd
samsung pm1735 3.2 TB: 3 dwpd
micron 7400 pro 3.84 TB: 1 dwpd
micron 7400 max 3.2 TB: 3 dwpd
intel d7-p5520 3.84 TB: 1 dwpd
intel d7-p5620 3.2 TB 3 dwpd
Так это расходуемый запас блоков для пополнения, а не вечно свободное место.
а в чём разница-то?
у нас есть N ГБ nand, и есть D ГБ данных.
чем ниже отношение D/N, тем ниже waf, или, другими словами, выше ресурс.
Не так. Ресурс относится ко всему пользовательскому объёму диска, а не только к занятому данными. Поэтому число D тут не причём.
Есть N ГБ nand, M ГБ пользовательской памяти и (N-M) ГБ резерва блоков на подмену. Чем выше M/N, тем выше ресурс. А сколько у нас в моменте будет занято данными – вообще ни на что не влияет. Блоку пофиг, занят он или нет. И если диск практически пустой, а подменные блоки кончились, он так же выйдет из строя.
Есть N ГБ nand, M ГБ пользовательской памяти и (N-M) ГБ резерва блоков на подмену
вы считаете, что «лишние» блоки используется просто как резервный фонд на случай выхода из строя основных?
нет, они являются частью общего пула блоков, с которым работает контроллер.
почитайте сигейтовоскую статью про overprovisioning
освобождённое файловой системой пространство используется наравне с заводским OP.
P. S. статьи про overprovisioning есть и у интел, и у самсунга, и у кингстона, во всех написано примерно одно и то же.
Какая разница? Речь идёт о том, что пользователю доступно M блоков, а изначально имеется N, которое постепенно расходуется вплоть до M. Понятно, что все блоки внутри устроены одинаково, и когда я говорю о резерве, то имеется в виду резерв количества, а не конкретные физические блоки.
Ниже, чем граница Real OP на картинке, количество исправных блоков опуститься не может. Хоть называй то, что ниже, "Dynamic OP", хоть "Presumed Valid Data", хоть "Free Space".
Ниже, чем граница 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 раз.
разумеется, это очень грубые прикидки, мы предполагали, что все блоки заполнены одинаково, при реальной работе это не так.
но общее представление о влиянии свободного места на ресурс можно получить.
Так именно поэтому свободное местоневлияет на ресурс.
надеюсь, что этот вопрос мы закрыли
Вот только эти все расчёты не имеют никакого отношения к занятым и свободным блокам с точки зрения файловой системы. Они касаются фактического значения битов в блоках. С точки зрения файловой системы эти блоки могут быть свободными, а с точки зрения контроллера SSD “грязными” (или наоборот, кстати).
Вопрос производительности-то упирается не в работу сборщика мусора (который сам чего-то там крутит в фоне), а в обнуление страниц перед записью.
Вы фактически своими расчётами доказываете тот факт, что чем больше на SSD записано нулей, тем эффективнее он работает. Это правда, но не имеет отношения к обсуждаемому вопросу резерва файловой системы.
С точки зрения файловой системы эти блоки могут быть свободными, а с точки зрения контроллера 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-20058msec
b. сделал 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 и увидеть, что в этих секторах данных нет).
именно для того, чтобы сообщить контроллеру, что эти блоки свободны, и придумана команда trim
Да, но от этого не пропадает необходимость их чистить перед записью туда.
Относительно дальнейшего - мы вообще чтение или запись обсуждаем?
Относительно дальнейшего — мы вообще чтение или запись обсуждаем?
мы обсуждаем внутренние алгоритмы работы ssd. доступа к исходникам нет, реверс-инжиниринг прошивки слишком трудоёмкий, поэтому ориентируемся на косвенные данные, например производительность операций чтения или записи.
Да, но от этого не пропадает необходимость их чистить перед записью туда.
разумеется не пропадает. но что вы этим хотели сказать?
вот смотрите, у меня в блоке 1024 сектора с данными.
для 1023 я сделал trim, после этого сборщику мусора достаточно перенести один оставшийся сектор в другое место и можно делать этому блоку erase.
мы обсуждаем внутренние алгоритмы работы ssd. доступа к исходникам нет, реверс-инжиниринг прошивки слишком трудоёмкий, поэтому ориентируемся на косвенные данные, например производительность операций чтения или записи.
Так работа SSD при чтении и при записи – это две совершенно разные вещи. И чтение вообще не имеет никакого отношения ни к очистке страниц, ни к trim, ни к сборщику мусора, ни к заполнению диска.
разумеется не пропадает. но что вы этим хотели сказать?
вот смотрите, у меня в блоке 1024 сектора с данными.
для 1023 я сделал trim, после этого сборщику мусора достаточно перенести один оставшийся сектор в другое место и можно делать этому блоку erase.
Это всё верно, но к чему это? Я же не спорю с тем, что trim помогает сборщику мусора, для чего, собственно, он и придуман. Я говорю о том, что поддержание запаса логического свободного места в файловой системе вообще никаким образом с этим процессом не связано. Сборщику мусора по самому принципу его работы не нужно дополнительное свободное место.
Так работа SSD при чтении и при записи – это две совершенно разные вещи. И чтение вообще не имеет никакого отношения ни к очистке страниц, ни к trim, ни к сборщику мусора, ни к заполнению диска.
я показывал, что ваше утверждение «чем больше на SSD записано нулей, тем эффективнее он работает» неверно: нули для накопителя ничем не отличаются от прочих данных.
Я говорю о том, что поддержание запаса логического свободного места в файловой системе вообще никаким образом с этим процессом не связано. Сборщику мусора по самому принципу его работы не нужно дополнительное свободное место.
сборщику мусора (на самом деле не совсем правильно его так называть, скорее «сборщик не-мусора») приходится перемещать тем больше данных, чем меньше мусора.
trim помечает данные как мусор, так что trim напрямую влияет на его работу.
я показывал, что ваше утверждение «чем больше на SSD записано нулей, тем эффективнее он работает» неверно: нули для накопителя ничем не отличаются от прочих данных.
Если Вы пытались оспорить именно это утверждение, то Вы выбрали неверный эксперимент, не относящийся к нему. Нули, записанные Вами, сами пишутся и читаются с той же скоростью, но помогут в неопределённом будущем следующей операции записи в те же секторы завершиться быстрее. Так как не придётся стирать страницы. (Если только файловая система не напихает своей служебной информации между нулевыми данными, как, например, HPFS и NTFS устраивают band'ы для быстрого доступа на HDD; кстати, отличный пример решения, увеличивающего эффективность на HDD, но катастрофически неоптимального для SDD).
сборщику мусора (на самом деле не совсем правильно его так называть, скорее «сборщик не-мусора») приходится перемещать тем больше данных, чем меньше мусора.trim помечает данные как мусор, так что trim напрямую влияет на его работу.
Это опять верные утверждения, не имеющие отношения к обсуждаемому вопросу. Вообще вся работа сборщика мусора не относится к обсуждаемой теме.
“Мусор” в понятии сборщика мусора никак не соотносится с количеством занятых или свободных областей в файловой системе. Это просто результат выполненных ранее операций записи.
Свободное от файлов пространство может быть как чистым (состоящим из нулей), так и мусорным. И занятое файлами пространство может быть как чистым, так и кандидатом в будущий мусор.
Вообще вся работа сборщика мусора не относится к обсуждаемой теме.
как это не относится?!? именно она создаёт write amplification, то есть определяет расход ресурса nand
“Мусор” в понятии сборщика мусора никак не соотносится с количеством занятых или свободных областей в файловой системе. Это просто результат выполненных ранее операций записи.
так было до появления trim.
trim именно помечает данные как мусор для накопителя.
чистым (состоящим из нулей)
да нет для накопителя такого понятия «сектор, заполненный нулями». для него это просто обычный сектор с данными.
есть «незаписанный сектор» (на который был сделан trim и после этого не было операций записи)
Нули, записанные Вами, сами пишутся и читаются с той же скоростью, но помогут в неопределённом будущем следующей операции записи в те же секторы завершиться быстрее. Так как не придётся стирать страницы
почему их не придётся перетирать? придётся, nand не nor, не позволяет многократную перезапись одного участка.
да если бы и позволяло, не надо забывать про ecc, в nand физически будут записаны не нули.
как это не относится?!? именно она создаёт write amplification, то есть определяет расход ресурса nand
Она определяет расход ресурса, но она не зависит от размера пустого места на логическом диске.
так было до появления trim.trim именно помечает данные как мусор для накопителя.
Не всё, что пометил trim, является мусором. А только то, что при этом имеет ненулевые биты.
да нет для накопителя такого понятия «сектор, заполненный нулями». для него это просто обычный сектор с данными
Вот те на. Да это и есть самое главное для накопителя.
есть «незаписанный сектор» (на который был сделан trim и после этого не было операций записи
Это тоже есть, но это выше уровнем. Уже логика контроллера. А то – схемотехническая логика.
почему их не придётся перетирать? придётся, nand не nor, не позволяет многократную перезапись одного участка.
Что, по-вашему, делает операция стирания страницы?
да если бы и позволяло, не надо забывать про ecc, в nand физически будут записаны не нули.
Битовую маску страницы можно подобрать таким образом, чтобы результат маскирования ecc от нулевой страницы сам был бы равен нулю. Так-то там и единицы вместо нулей означают стёртое состояние, поэтому надо делать байтам данных xor $ff, так как данные чаще бывают обнулёнными, чем объединиченными.
Что, по-вашему, делает операция стирания страницы?
речь про то, что 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.
речь про то, что 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 и помогает выполнять работу по преобразованию первого во второе, но это не единственный путь появления мусора.
Фух. Не знаю, как ещё понятнее написать.
Поэтому если вы скажете, что операции записи уменьшают ресурс SSD, то я соглашусь, но это и так самоочевидно. А вы пустились доказывать, что ресурс уменьшается от уменьшения свободного места в ФС, и это неверно.
прочитайте внимательнее что я писал.
смотрите, есть два ssd, A и B, каждый по терабайту, на каждом файловая система занимает весь раздел.
на этих ssd лежит одинаковая база данных размером, ну пусть 128 ГБ.
но на ssd A ничего больше нет, на ssd B помимо БД лежат картинки, которые не изменяются, файловая система занята на 99%.
данные в БД меняются, и пусть, скажем, за неделю в БД переписывается 16 раз (то есть 2 терабайта записи).
так вот, в во втором случае waf будет гораздо выше, чем в первом, то есть, несмотря на одинаковый объём записи, износ накопителей будет разным.
Я с этим выводом не спорю. Но вопрос тут не в свободном месте, а в длительно лежащих без изменения файлах картинок. Любые долго лежащие файлы блокируют страницы памяти под собой.
Но вопрос тут не в свободном месте, а в длительно лежащих без изменения файлах картинок
нет, именно в занятом месте.
a. если бы мы переписывали эти картинки периодически (при это свободное место не менялось бы), то waf оставался бы столь же высоким;
b. если мы сотрём эти картинки (и trim работает), то waf для вновь записываемых на накопитель B данных будет таким же, как и для записываемых на накопитель A.
После этого этот высокий потенциал можно когда угодно скидывать в низкий операцией записи, формируя на интерфейсе двоичные единички. Хоть один раз, хоть миллион, но только от высокого потенциала к низкому.
нет, для 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 (а такого я не наблюдал на тех накопителях, что я тестировал).
One or two further writes to the block could be sustained
Даже если так, это никак не меняет того факта, что стёртая страница уже нулевая (единичная).
P. S. ну а если бы проблема записи нулевых байт волновала производителей ssd, то, уверен, они бы решили это путём приравнивания записи нулей к trim
Их нельзя приравнять, так как нулевая страница с данными не является незначимой и не может быть перезаписана сборщиком мусора.
Их нельзя приравнять, так как нулевая страница с данными не является незначимой и не может быть перезаписана сборщиком мусора.
какой ещё сборщик мусора? он работает с nand.
а неинициализированные сектора существуют только в ftl, в nand они не хранятся.
то есть нам достаточно пометить lba как неинициализированный и не писать его вовсе в основную область nand (ну а старую версию в nand, если она есть, отметить как мусор). именно это и делает команда trim.
теперь чтение этого lba будет возвращать нули (притом на хорошей скорости; пример я приводил, но он не особо показательный — встречал накопители, на которых чтение неинициализированной области в 2-3 раза быстрее чтения реальных данных).
судя по тому, что массовые ssd не включают такую очевидную оптимизацию, разработчики сочли, что это редкий случай, не стоящий минимальных усилий.
Так этот сектор не является неинициализированным. Он инициализирован и содержит нули. Туда, в отличие от неинициализированных секторов, нельзя ничего перемещать.
omg… куда туда?
отношение страниц nand к lba в ftl не обязательно 1:1.
если lba помечен как неинициализированный, то ему не соответствует никакая страница в nand.
Вы про что вообще говорите – про сектор ФС, про страницу 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
То, что вы предложили, опирается на предположение, что неинициализированный элемент LBA будет при чтении давать нули.
а вам встречались иные примеры?
Такая опция называется DRAT (Deterministic read data after TRIM) или DZAT (Deterministic read zeros after TRIM)
эти опции не про то как будут читаться неинициализированные данные, а про то обязательно ли контроллер будет отмечать данные как неинициализированные, и будет ли он это делать сразу или может отложить.
дело в том, что изначально эти команды воспринимались как необязательная рекомендация, и разработчики контроллера могли принять решение в каких-то случаях ради лучшей производительности «срезать углы». например, sandforce так делали, после trim'а чистилась только часть данных.
Вот есть у нас диск, занят на 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
я не говорю про производителей второго-третьего эшелона
Актуален, если мы тупо фрагмент пишем, он занимает весь размер сектора (пресловутое "на диске"). Так что либо ssd должен дефрагменитировать, либо мы.
Укажите в статье что такого нельзя делать на основном разделе. А то сейчас народ по незнанию побежит отнимать "награбленное" системой, а потом окончанию места будет вас же и проклинать. )
А то такого много можно насоветовать. "Отключайте fsync под базами, они будут быстрее работать!", "Используйте RAID0 вместо RAID1, так вы сэкономите кучу места!" и прочие облегчающие жизнь советы...
Так ведь компании с большой капитализацией некоторые именно так и делают — см https://habr.com/ru/news/t/653527/
На практике диски лучше вообще не заполнять больше 80% от номинальной емкости. Если вам важна скорость работы.
Куда и подо что там уйдут эти 20% на самом деле не важно.
Да, я на SSD обычно создаю небольшой "блокирующий" раздел, чтобы не забивать его под горлышко.
Я забивал диск на 99%+ процентов, и все ок...
Только там была BTRFS, которая хоть и имеет небольшой резерв, но он не для рута, а именно для самой ФС. Что позволяет даже при 0% свободного места не мешает удалять файлы, под-тома или даже делать НОВЫЕ снапшоты.
Сейчас большая часть дисков заполнена на 99.9%. И никаких проблем с этим. Дисков уже 120тб. Жду ещё 40тб в этом месяце, чтобы свободное место появилось наконец-то.
Вы точно на них активно пишите и читаете? В моих тестах после 80% заполнения деградация скорости значительная и легко видна приборах.
Пишу и читаю неактивно. Не более сотни гигабайт в день на диск. Т.е.особой разницы между 240 и 180 мб сек не замечу. Основная масса файлов - громадные блобы на десятки и сотни гигабайт.
Это 25% как бы. Для нагружённой системы это означает на 25% больше серверов для сохранения нужной производительности.
Это заметные деньги. Простить 20% емкости диска дешевле.
Пусть даже 300Gb в день пусть при скорости 100мб/сек это час работы диска. Т.е. моем случае в разы меньше В скорость диска "в долгую" ничего не упирается. Кроме того, для горячих данных очень эффективно работает системный кеш.
А вот диски совсем недешевые. Это первые я брал по 25тр за 10тб (WD Gold KRYZ). Потом они подскочили до 100, благодаря чиа-майнерам, и, не успев полностью отыграть обратно, опять выросли до сегодняшних 50тр, вопреки циферкам курса
Эти сервера - мои личные, домашние. Купленные/собранные за собственные деньги
Для быстрых данных у меня есть несколько дисковых полок, по 25 600гб 10к дисков в каждой. Но пока vendor lock я с самих полок не снял, только с дисков.
На ext4 незначительно. А вот на ext3 ужас.
Заливаю диски под завязку. И никаких проблем с этим. Дисков уже несколько сотен петабайт. m=0. НО! Данные эти статичны и почти не перезаписываются.
Фрагментация при нехватке места бич любой фс. На hdd это смерти подобно. На ssd не так критично. Там другой подход — значительно увеличиваем зону OP, при этом сокращаем резерв фс.
На системных разделах, впрочем, в ноль резервирование убирать не стоит.
Как нахаляву получить 10 миллионов рублей? Положить на год 100 миллионов в банк под 10% годовых.
Что же с вами будет, когда вы осилите мануал mkfs.ext4 и узнаете о возможности уменьшить размер инодов с 256 байт, до 128 и о возможности задания количества этих самых инодов. Ведь, по умолчанию mkfs создаёт очень сильно с запасом инодов, и на моей практике всегда можно сильно уменьшить их количество. В целом, практически всегда хватает 5 миллионов с хорошим таким запасом.
Но предупреждаю, что тут надо действовать обдуманно, т.к. увеличить их количество можно только переформатированием раздела.
А ещё в Дебиан есть пакет ядра linux-image-cloud-amd64. Он занимает всего 20 МБ, для сравнения, классическое ядро, что ставится по умолчанию, весит около 700-800 МБ. Это ядро можно использовать в KVM виртуалках, если сеть и диски у них virtio, и вы не прокидываете реальные устройства устройства в виртуалку.
Знаете, это просто офигенная тактика написания статей на хабре. Буквально вчера у меня в трекере всплыла https://habr.com/ru/post/339470/ про это самое из-за некропост-коммента, я прочитал, хмыкнул, закрыл. Походу у автора, как и у многих других, оно тоже всплыло в трекере, для него это стало открытием, он проделал описанное в статье на своем кластере, обалдел от результата... и решил написать про это свою статью? Я открываю "читают сейчас"... и испытываю когнитивный диссонанс вместо со странным дежа вю. Автор, все новое - хорошо забытое старое?
Я понимаю, что это очередное нытье про "хабр - не торт", но имейте совесть уже, тем более что "статья" про содержимое man в линуксовой утилите, ну е-мое, дальше уже снизу стучать начнут...
Вы уж извините, но если сказали раз, то скажите и два.
EXT2-3-4 еще и по i-node выделяет овер-дофига места при форматировании.... и поменять позволяет только в сторону уменьшения.
Но, тут еще большой вопрос - стоит ли это менять? Ведь если будет 100500 мелких файликов то i-node не хватит. Но если на этом огромном диске лежат крупные файлы - то резерв i-node будет практически неиспользован.
ЗЫ А можно еще и три сказать: эта ФС - ИМХО уже слишком устарела. Там во внутренних структурах еще куча очень странных решений, мягко говоря не рассчитанных на диски большого объема. Я бы подумал над использованием XFS или BTRFS - там решения изначально принимались гораздо более разумные подходящие для больших дисков. Одно то, что (даже без резерва рута) EXT-4 резервирует сразу после форматирования под собственные нужды ~1,6% диска (вне зависимости от его размера), а вот XFS/BTRFS резервируют сущие копейки (меньше 0.2% на 1Gb) и с ростом размера диска этот процент еще сильнее уменьшается. И это в частности потому что никто уже давно не резеревирует i-node заранее а создают и утилизируют их по ходу работы. И проблеммы "на диске есть место а файл не записать" в нормальных FS не возникает.
>И никто из моих знакомых-линуксоидов не знал.
Ужасные знакомые, ужасная статья. Про tunefs сразу сказали, можно ещё добавить, что смысла трогать эту крутилку нет, т.к. в реальной эксплуатации
руту всё равно даёт писать до 100%
когда кончается место, то уже на и 90% надо докинуть дисков. Маргинальные случаи со статичной помойкой где 1 раз заполнили на 99.99% и ничего не меняется слишком редки.
Более того, несколько раз меня очень выручило это резервирование когда СРОЧНАА нужно было докинуть хоть чуть-чуть места и взять его было больше неоткуда.
Нет, root не может писать в резерв. Может только какие-то системные данные.
ерунду какую-то пишете. создаём тестовую fs на 20 гигов с резервом 50%
edo@edo-home:~$ truncate -s 20G testfile
edo@edo-home:~$ /sbin/mkfs.ext4 -m 50 testfile
mke2fs 1.46.2 (28-Feb-2021)
Discarding device blocks: done
Creating filesystem with 5242880 4k blocks and 1310720 inodes
Filesystem UUID: b9a87412-340d-4171-9fe3-c7ec31ccbc6e
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000
Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done
edo@edo-home:~$ mkdir testmnt
edo@edo-home:~$ sudo mount -o loop testfile testmnt/
edo@edo-home:~$ sudo chown edo testmnt/пробуем писать от обычного пользователя, получается записать только 10 гигабайт:
edo@edo-home:~$ dd if=/dev/zero of=testmnt/1 bs=128M status=progress
10200547328 байт (10 GB, 9,5 GiB) скопирован, 33 s, 308 MB/s
dd: ошибка записи 'testmnt/1': На устройстве не осталось свободного места
77+0 записей получено
76+0 записей отправлено
10203222016 байт (10 GB, 9,5 GiB) скопирован, 33,1336 s, 308 MB/sпробуем от рута, получается записать ещё 10 гигабайт:
edo@edo-home:~$ sudo dd if=/dev/zero of=testmnt/2 bs=128M status=progress
10603200512 байт (11 GB, 9,9 GiB) скопирован, 39 s, 275 MB/s
dd: ошибка записи 'testmnt/2': На устройстве не осталось свободного места
80+0 записей получено
79+0 записей отправлено
10737057792 байт (11 GB, 10 GiB) скопирован, 39,0339 s, 275 MB/s
Гиги за логи
>На логи, да!
Не на логи, а на ФС, туда ничего не пишется и вообще не трогается. Файловая система по умолчанию такая отвратительная, что ей нужно свободное место или она замедляется очень сильно. Так как в отличии от windows, защита от фрагментирования работает методом а "давай напишем прям в центр свободного места". Поэтому в конце ей нужно свободное место посредине всех нефрагментированных файлов.
У автора видно было не все в порядке.
Кликбейтный заголовок. Не 5 Тб дисков, а 5 Тб дискового пространства в имеющемся массиве. Это большая разница
Раньше на UNIX (SunoS, Solaris, Irix) резервировалось по дефолту 10% места. Достаточно один раз установить диск в компьютер, посмотреть на результат и сразу запомнишь опцию -m.
mkfs.ext4 -O '^resize_inode' отключит резервные inode, которые выделяются для возможности их добавления при ресайзе диска в сторону увеличения. Если вы не собираетесь ресайзить файловую систему, то эту опцию можно безболезненно отключить.
mkfs.ext4 -N 1000000 статически задаст количество inode'ов — это основной элемент, «расходующий» свободное место диска и увеличивающийся с его размером.
mkfs.ext4 -T largefile задаст тип файловой системы в "largefile" — оптимизация распределения и количества inode'ов под конкретный сценарий использования. Возможные значения и их конкретные параметры смотреть в /etc/mke2fs.conf.
сложно заранее и на будущее знать сколько инодов потребуется для конкретного размера диска - сейчас там например видео, а потом исходники\картинки\кэши
на btrfs и заметил жор ядра проца типа kworker events_unbound, возникает непонятно когда
Возможно, это: https://bugzilla.kernel.org/show_bug.cgi?id=212185
Мало того что производители дисков жонглируют гига- гиги- байтами, неизменно продавая обьём меньше интуитивно ожидаемого.
Никто ничем не жонглирует. Производители накопителей указывают число байт на накопителях и используют десятичные приставки СИ. Чтобы увидеть те "потерянные гиги" в Linux, всего лишь надо использовать нужный ключ, например "df -H", дальше можно ввести "df -h" удивиться потерянным гигабайтам.
Тут больше проблема в том, что та же Windows использует двоичные приставки, но указывает их как десятичные. Это если бы вам обещали зарплату в долларах, а выплатили бы ту же сумму рублями, а что, тоже деньги. В macOS (и вообще в технике Apple) корректно используются десятичные приставки.
Никто ничем не жонглирует.
когда диски были маленькие, то на hdd указывали "нечестные" мегабайты, а потом "исправились" ?
Microsoft до сих пор думает что он двоичный.
За древние системы не подскажу, но то, что MS использует двоичные приставки, но называет их десятичными — факт. В Linux я вижу повсеместное использование двоичных, но там и используются соответствующие двоичные названия. Непривычно, но, думаю, можно где-то настроить, во всяком случае в базовых консольных утилитах есть оба варианта. Так что тут вопрос не о "нечестных производителях", а об одной фирме, которая сделала неправильное отображение данных, но не исправляет эту ошибку десятилетиями. Впрочем, как и множество других.
А сами байты никуда не делись. Сколько заявлено, столько и есть. И если система правильно показывает эту информацию, то никаких вопросов не возникает. В итоге путается приличное число людей, в том числе те, кто работает в индустрии.
Честно говоря я вообще не понимаю, что это за такой странный случай, когда у тебя 100 Гб места (или мегабайт, не важно) и тебе вот прям 5 не хватило ))) Заполнение диска под 100% это как бы само по себе плохо. Я думаю, что если тебе не хватило 100 Гб, значит надо покупать ещё 100 как минимум? Не?
5% прибавки - это не о чём...
А 5тб это тоже "ниочем" ? Сегодня это уже 8тб. У многих весь компьютер имеет в разы меньше, чем тут одна экономия.
Это, например, лишняя пара недель в запасе, чтобы найти и купить дополнительный диск по хорошей цене. Что сейчас стало непросто сделать - диски, в среднем, стали вдвое дороже от цен 2020, хотя оф.курс значительно ниже.
Как получить 5 Тб дисков нахаляву