Короткая заметка, написать которую меня натолкнуло появление этой статьи: "Неожиданная находка, которая освобождает 20 GB". Ха! Всего 20GB ? Есть универсальный способ освободить больше.

Linux утилита mkfs.ext4 (ext2/ext3/ext4) имеет параметр -m, о котором мало кто знает. Я не знал. И никто из моих знакомых-линуксоидов не знал.

Этот параметр резервирует место, в процентах, доступное только суперпользователю. Чтобы, когда обычные юзеры выжрут весь диск, демоны продолжали оголтело писать свои логи, не падая. Значение по-умолчанию: 5. ПЯТЬ ПРОЦЕНТОВ! Что на диске в 10Тб даёт сумасшедшую цифру в 500 гигабайт. На логи, да! Наверное в начале-середине 90х такая процентовка имела смысл, но явно не сейчас.

Мало того что производители дисков жонглируют гига- гиги- байтами, неизменно продавая обьём меньше интуитивно ожидаемого. Так ещё и "налог" сверху, в 5%, от утилиты форматирования! Особенно для дисков с данными, где никаких логов нет и не предвидится.

Переформатировав свои 100тб дисков, я получил дополнительные 5Тб дискового пространства, просто так, на ровном месте.

Всем хороших выходных!

Комментарии (194)


  1. goletsa
    17.06.2022 23:19
    +59

    Мне кажется, или процент резерва легко меняется через tune2fs без форматирования?


    1. screwer Автор
      17.06.2022 23:37
      -13

      Видел, но не пробовал. Вполне возможно что я тогда пошёл сложным путём.


    1. Popadanec
      18.06.2022 11:35
      +12

      А проблема с размерами дисков в разнице систем отсчёта. В магазине продают гигабайты, а система отображает гибибайты.


    1. vitaly_il1
      20.06.2022 14:46

      абсолютно точно!


  1. randomsimplenumber
    17.06.2022 23:26
    +110

    Linux утилита mkfs.ext4 (ext2/ext3/ext4) имеет параметр -m, о котором мало кто знает.

    Выросло поколение, man не читающее. (Бурчит себе под нос).


    1. screwer Автор
      17.06.2022 23:36
      +6

      Как показал 1,5 года назад мой беглый опрос - нас таких, не читающих, много (((

      Причём некоторые с Линуксом больше 25 лет. Так что - вдруг кому-то пригодится, уже польза.


      1. jsirex
        18.06.2022 12:09
        +12

        Часто на проверку оказывается, что это не 25 лет опыта в линукса, а 1 год опыта работы с линуксом 25 раз. Да и в цифре 25 сильно сомневаюсь. Скорее не больше 20


        1. 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 окружение.


          1. levkib
            20.06.2022 06:42

            Странно, что он не знал. Может он не знал именно про опцию '-m' ?

            У меня примерно такой же опыт общения с linux, с 90-х. Опция резервирования места регулярно спасала при тогдашних объемах дисков.


            1. foxweb
              20.06.2022 14:27
              +1

              ой, чуваки, не спорьте, в жизни и не такое бывает. в 2010 я встретил сисадмина-эникейщика туристической фирмы уже в годах, который не знал, что такое Ubuntu (линукс-дистрибутив). можно работать всю жизнь без знаний, без которых кто-то другой не представляет себе жизни.


          1. demitel
            20.06.2022 10:03
            +2

            Двадцать пять лет назад, если система не досталась волшебным образом в дар вместе с обслуживающим её человеком, установка, настройки и использование линукса предполагали изучение огромного количества документации, в том числе tune2fs. По крайней мере двадцать лет назад мне не удалось этого избежать. В те годы многие, воспринимаемые сейчас как само собой разумеющиеся, вещи были удивительны в настройке, например монтирование или проверка дисков, что заставляло RTFM. В те времена каждый мегабайт был на учёте, и, например, потеря целых 200 мегов на моём 4,3 гигабайтном фуджике не могла пройти незамеченной уж никак. Да и восемь лет назад коллега при переходе с винды довольно быстро заметил эту особенность с резервом, что характерно, сам.


        1. strvv
          19.06.2022 13:23

          почему?

          1996год,redhat4.

          1994vax/vms,dec_alpha...

          2.2&2.4=конец90х.


        1. falcon4fun
          19.06.2022 16:11
          +1

          Соглашусь с ТС скорее. ДевОпс тому прекрасный пример: специализированный набор утилит, который нигде, кроме девопса, не используется. В большинстве своем отсутствие базовых знаний (ведь зачем знать, как работает акпп, чтобы ездить на машине.

          Зато потом огромный процент людей спрашивает: а что будет, если ревер тыркнуть на ходу?)


          1. sdore
            19.06.2022 18:15
            +3

            После прочтения вашего комментария мне захотелось узнать и то, и другое.


          1. SlimShaggy
            20.06.2022 10:47

            А на МКПП что будет? Вчера случайно попробовал: хрустит и не втыкается (усилий не прилагал).


            1. screwer Автор
              20.06.2022 17:09

              Задняя без синхронизаторов, попробуйте с двойной перегазовкой.


              1. DrPass
                20.06.2022 17:12

                Да, заодно и узнаете, сколько стоит замена шестерней с сорванными зубами в МКПП.


      1. A1EF
        18.06.2022 22:18
        +5

        Чо уж, я сам-то узнал про факт, описываемый в посте, так: мой тогдашний руководитель отдела обратил внимание, что на серверах сразу после установки операционки свободное и занятое место не согласуются с суммарным объемом. Я отмахнулся, мол это приколы перевода объемов в степенях двойки и десятки скорее всего. Он полез разбираться и нашел про это самое резервирование и как через tune2fs подвинуть. Я добавил себе в копилку знаний и на будущее взял на заметку впредь быть повъедливей:)


      1. KSCF
        19.06.2022 13:28

        Если какая-то вещь создана таким образом, что о ней нужно читать, значит о прочитанном будет обязательно забыто. Слишком уж много в мире теперь писатели пишут. Печально, что в линуксе нужно читать и про логи, и про форматирование. Базовые вещи, которые должны быть хорошими "искаропки"


        1. Dorval
          20.06.2022 02:47
          +3

          Вот и выросло поколение программистов, не умеющих читать...


    1. 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 читать… Я после такого вообще в шоке был.


      1. DrinkFromTheCup
        18.06.2022 12:08
        +6

        Тут скрипт требует K-Lite Codec Pack, но его нету на linux по этому пути

        Т. е. как минимум с:\\ у него в линуксе - ЕСТЬ?!


        1. makapohmgn
          18.06.2022 19:24
          +2

          Ну wine же. Непонятно только нахера такие извращения


      1. DrPass
        20.06.2022 15:12
        +1

        Ну смотря что это был за юзер. Если это разработчик — то да, перебор. Если обычный юзер приложения, то с ним-то всё ок, проблема в софте, который на линуксе такое может выдать.


    1. awoland
      19.06.2022 10:00
      +2

      Помню среди профеcсионалов была популярна побуждающая аббревиатура RTFM...


  1. sunnybear
    17.06.2022 23:27
    +2

    Вы ещё журнал не пробовали отключать. И резерв самих контроллеров диска :)


    1. screwer Автор
      17.06.2022 23:33
      +1

      Эти оба-два чреваты потерей данных. В отличие от ненужного (для дисков с данными) резерва под логи.


      1. AlexGluck
        18.06.2022 01:14
        +7

        tune2fs -r "$((300*1024*1024/$(tune2fs -l /dev/sda1 |grep "^Block size:" | cut -f2 -d ':' | xargs)))" /dev/sda1

        АВТОР ЭТОГО WISYWIG УМРИ!

        Отключать резервирование не надо, иначе даже от рута не залогинитесь. Третий раз писать почему, не буду, редактор отстой. Я ставлю резерв 300МБ.


        1. screwer Автор
          18.06.2022 01:24
          +3

          Напомню, что речь идёт о дисках с данными. Не о рутфс. Причем тут "залогиниться" ?


          1. AlexGluck
            18.06.2022 01:27
            +3

            Всё равно пространство для манёвра оставлять надо, если надо будет провести архивацию старых данных (например логи в текстовом режиме писали), то хоть на пол шишечки место не повредит, а жадничать 300 метров это уже ту мач в современном мире.


          1. aml
            19.06.2022 00:21

            При том, что когда системные демоны запускаются, им иногда надо создавать файлы - pid-файлы, локальные unix domain sockets. Если места ноль, может не получиться, и система уже не поднимется. При нынешних объемах дисков конечно 5% это до фига. Можно и меньше поставить.


      1. ALiEN175
        18.06.2022 05:58
        +9

        кто вам наплёл сказки про мифические логи? Резерв root для раздела ext3/4 с ОС существует, чтобы вы не получили чёрный экранчик с мигающим курсором, если у вас всё место забито на 100%.


        1. SlimShaggy
          20.06.2022 10:54

          Какие нежные эти ваши линуха. Винда с 0 байт на системном разделе спокойно стартует.


          1. Tomasina
            20.06.2022 11:27

            ...и на 92% загрузки уходит в синий экран.


      1. celebrate
        18.06.2022 11:26

        Это был сарказм, если что  :)


  1. vadimr
    17.06.2022 23:34
    +1

    Более интересный вопрос – зачем вообще использовать ext в сегодняшних реалиях.


    1. superconductor
      17.06.2022 23:37
      +4

      А какой фс сейчас пользоваться более модно, если не ext4?


      1. vadimr
        17.06.2022 23:39
        +1

        SUSE, например, рекомендует btrfs для корневого раздела и xfs для данных. Никогда особо над этим не задумывался и просто так и делал.


        1. sim2q
          18.06.2022 07:24
          +1

          уже точно можно?
          я просто немного консервативен, btrfs стоит на backup потому что не жалко жмёт не плохо - вроде нормально


          1. vadimr
            18.06.2022 09:41
            +1

            Лет 10 пользуюсь везде, проблем не было.

            Журналирование - полезная вещь. Опять-таки, можно будет написать статью, как пропуржить журнал :)


          1. 13werwolf13
            20.06.2022 09:19

            btrfs однозначно ДА
            10 лет назад в случае мигнувшего питания или проблем с hba она превращалась в тыкву без возможности восстановить данные, сейчас это стабильная и очень фичастая фс

            а вот xfs я бы не советовал тем кто не уверен на 100500 процентов в том что его сервер/компьютер/ноут будет ВСЕГДА graceful shutdown. так что если не нужна фичастость btrfs то лучше ext4

            ну а из фич btrfs лично я юзаю:
            1) подтома
            2) сжатие (после перехода на zstd оно перестало оказывать влияние на скорость чтения/записи)
            3) массивы (да, да.. как в zfs, только аналогов zvol нету пока)
            4) снапшоты (накосячил кривыми ручками что-то, бах и откатился в рабочую систему, нраися..)
            CoW конечно дико фрагментирует данные на диски, но в отличии от винды в линуксе это как-то незаметно влияет на скорость работы даже на медленных блинах 5400rpm, ну а на ssd всё это вообще не играет роли. Ну а если прям хочется то CoW можно и отключить


          1. maratkoRuEkb
            20.06.2022 17:10

            Полгода назад статья же выходила что btrfs высаживает диски быстро, потому что постоянно чтото пишет и переписывает в гораздо большем объеме чем надо.


        1. DerRotBaron
          18.06.2022 19:12
          +6

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


          1. sirota
            18.06.2022 21:11

            И вот я с вами соглашусь. Сино активно суют эту фс и так же присел в лужу.


          1. Akon32
            20.06.2022 12:15

            А что именно произошло? Это были описанные в документации проблемы с raid5/6 или что-то другое?


      1. isden
        18.06.2022 01:58
        +10

        zfs


        1. ivanrt
          18.06.2022 03:07
          +2

          Пользую zfs. Прозрачная быстрое сжатие (lz4) сжимает диски моих виртуальных машин в два раза не учитывая thin provisioning, но безполезно для видео и музыки. С другой стороны zfs плохо работает без 20% пустого места. Btrfs тоже сжимает и вообще прогрессивна, но крэшила мне виртуальные машины и вообще сожрала мои тестовые данные два года назад. Пользуюсь zfs из-за удобного управления местом, снэпшотов, умного рейда и репликации.


          1. Pavel1114
            18.06.2022 07:50
            +1

            Прозрачная быстрое сжатие

            Вот и тема для следующей статьи. На этом, в зависимости от данных, можно поболее жалких 5% выиграть. Но вроде современные дистрибутивы по умолчанию включают эту опцию в zfs и btrfs.


            1. entze
              18.06.2022 12:59

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

              Хотел использовать OpenZFS на Mac, но ленивая жопа не стал разбираться с CLI, а GUI не работал. Выбрал дедупликацию сторонними средствами для APFS и для свалки обнаружил ощутимый прирост свободного места.


              1. isden
                18.06.2022 17:47

                Хотел использовать OpenZFS на Mac

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


            1. screwer Автор
              18.06.2022 15:21
              +2

              выиграть можно, но какой ценой ?

              Я поставил один 6тб диск "поиграться", разметив его в ZFS. Сжатие и дедупликация дают великолепную экономию места. Но как же это всё тормозит! Даже удаление сотни гигабайт файлов занимает несколько часов. А заливка пары террабайт длилась почти сутки. И это на виртуалке с 48 процессорами и 128гб озу! Вообщем пользоваться этим "по-дефолту" невозможно, надо как-то тюнить производительность.

              Ещё был сюрприз, при переносе диска из Ubuntu18 в Ubuntu22. Пул стал, внезапно, degraded. При переносе обратно - всё отлично, online. scrub не помог.


              1. edo1h
                18.06.2022 15:36
                +1

                Сжатие и дедупликация дают великолепную экономию места. Но как же это всё тормозит! Даже удаление сотни гигабайт файлов занимает несколько часов. А заливка пары террабайт длилась почти сутки. И это на виртуалке с 48 процессорами и 128гб озу!

                странно, использую zfs на бекапном сервере.
                каждую ночь на него заливается около 10 терабайт, никаких проблем.


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


              1. isden
                18.06.2022 17:51
                +1

                Но как же это всё тормозит! Даже удаление сотни гигабайт файлов занимает несколько часов. А заливка пары террабайт длилась почти сутки.

                Я уже много лет использую zfs (в том числе и как rootfs).
                Описанных проблем не встречал, хотя доводилось и удалять и заливать сотнями гигабайт.


              1. nidalee
                19.06.2022 03:30
                +2

                Тут что-то не так. У меня несколько ТБ файлов удаляется за секунды.


        1. dodikru
          19.06.2022 22:27

          zfs очень-очень медленный, увы.


          1. isden
            19.06.2022 22:57

            У меня он достаточно резво работает.
            ext4 конечно быстрее (а ext2 или fat еще быстрее), но в нем нет всех киллер-фич zfs.


    1. screwer Автор
      17.06.2022 23:39

      Какие альтернативы вы предлагаете ?


      1. Daimos
        18.06.2022 10:19

        xfs хотя бы, которую RedHat для Enterprise использует.


    1. aik
      18.06.2022 09:07

      Простая, дубовая, совместимая.
      Решение по умолчанию, в общем. Все эти зфс и бтрфс — только если нужны их фишки.


    1. A1EF
      18.06.2022 11:51
      +3

      Встречный вопрос: а чем плох ext4? Если не рассматривать какие-то очень специфичные сценарии, конечно.


      1. vadimr
        18.06.2022 11:58
        +1

        • нет снапшотов

        • нет управления томами и ресайза в онлайне

        • нет сжатия

        • нет сopy-on-write

        • не оптимизирована для SSD

        Для меня уже и первого пункта достаточно. Второй тоже важен при смене оборудования. В btrfs можно в пределе даже переехать с одного физического диска на другой, не останавливая работу системы.

        В btrfs новая версия файла не затирает старую, что может оказаться важным в случае неприятностей.


        1. DonAgosto
          18.06.2022 13:46
          -1

          нет снапшотов
          для системного диска на десктопе вполне заменяется timeshift
          на SSD снимок делается за некритичное время


          1. vadimr
            18.06.2022 14:14

            Ну всё можно так или иначе делать костылями. Снапшот-то вообще не занимает времени и не требует дополнительного диска.

            Одно дело, когда у вас отметка снапшота выполняется мгновенно, а другое – когда будет шерстить весь диск и сбрасывать изменения, пусть даже это и SSD.


            1. DonAgosto
              18.06.2022 14:27

              Снапшот-то вообще не занимает времени
              я про время специально указал — для типичного десктопа вобще нет разницы сколько там оно копируется в фоне — 0.1с или 100с
              и не требует дополнительного диска.
              timeshift тоже не требует. Но если сохранять снимки на другой диск/раздел, то это уже преимущество перед снимками ФС — получим фактически инкрементный бэкап, стойкий к повреждению ФС на исходном разделе.


              1. vadimr
                18.06.2022 14:36
                +1

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


                1. DonAgosto
                  18.06.2022 14:48

                  да, безусловно, если ваша работа/досуг состоят в основном из подобных задач, встроенные снапшоты в ФС будут более удобны
                  но мне кажется, наиболее частый сценарий для десктопа — быстро откатить, если что-нито сломалось при очередном обновлении — а это конечно довольно редкое событие


                  1. vadimr
                    18.06.2022 15:10
                    +1

                    Сломалось - редкое событие, а обновить что-нибудь - частое. Поэтому задача как раз в том, чтобы мгновенно сохранить, а не в том, чтобы быстро откатить.


        1. edo1h
          18.06.2022 15:28
          +3

          не оптимизирована для SSD

          можно пример фс, эффективно оптимизированной под ssd?


          1. vadimr
            18.06.2022 15:37
            +1

            APFS, например

            А, возвращаясь к теме, та же btrfs по-разному строит структуры данных на HDD и SSD.


            1. edo1h
              18.06.2022 15:40
              +1

              А, возвращаясь к теме, та же btrfs по-разному строит структуры данных на HDD и SSD.

              и даёт ли это какой-либо измеримый эффект?


              1. vadimr
                18.06.2022 17:27

                Я не мерял. Теоретически ресурс должен быть больше.


                1. 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.html


                  1. vadimr
                    18.06.2022 22:12

                    Не, там другое дело. Речь идёт о дублировании служебных блоков, и определяется это не по устаревшей опции монтирования ssd, а непосредственно по запросу типа диска (cat /sys/block/sda/queue/rotational)


                    1. 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.


                      1. vadimr
                        18.06.2022 22:40

                        Наверное, замучали их люди, делающие dd с hdd на ssd.


            1. d2d8
              18.06.2022 16:26
              +1

              Если учесть, что SSD в принципе пофигу как там что расположено, то зачем делать разные структуры?


              1. 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-хранилищами, например.


                1. Tomasina
                  20.06.2022 11:30

                  Это заботы контроллера SSD, а не ОС.


              1. vadimr
                18.06.2022 17:25
                +1

                Для SDD - беречь ресурс записи.

                Для HDD - уменьшать задержки на позиционирование.

                Также, например, дублирование управляющих структур на SSD не имеет смысла, так как контроллер выполняет дедупликацию.


                1. edo1h
                  18.06.2022 17:36

                  так как контроллер выполняет дедупликацию.

                  нет. во всяком случае мне такое не встречалось.
                  можете сами взять и проверить, у fio есть специальный флаг refill_buffers


                  1. vadimr
                    18.06.2022 19:20

                    Не очень понял Вашу мысль. С refill_buffers fio ожидаемо выдаёт более плохой результат.


                    1. 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=0


                      1. vadimr
                        18.06.2022 19:48

                        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


                      1. edo1h
                        18.06.2022 21:06

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


                      1. vadimr
                        18.06.2022 21:31

                        На самом деле я ещё в прошлый раз по ошибке всадил 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 крайне зависима от предыстории.


                      1. edo1h
                        18.06.2022 22:00

                        Поскольку блоки, записанные ранее, физически остаются на SSD, то при каждом новом запуске fio результаты всё улучшаются, независимо от параметров

                        честно говоря не понял, что значит «блоки остаются на ssd».


                      1. vadimr
                        18.06.2022 22:08

                        Ну я же создал тестовый файл при помощи fio. Его содержимое никуда не делось с ssd, когда я этот файл стёр перед следующим запуском программы. Когда я второй раз запускаю программу, она генерит такие же блоки с теми же контрольными суммами (хотя они и разные от блока к блоку, но всего их ограниченное число), это ловит алгоритм дедупликации в контроллере SSD и просто использует блоки, записанные при прошлом запуске программы, вместо того чтобы писать ещё раз.


                      1. edo1h
                        18.06.2022 22:21
                        +1

                        Его содержимое никуда не делось с ssd, когда я этот файл стёр перед следующим запуском программы

                        а как же trim? или он в apfs сильно отложенный?


                        это ловит алгоритм дедупликации в контроллере SSD

                        не верю.


                        1. алгоритм дедупликации требует кучу памяти (а на накопителях обычно впритык ftl разместить);
                        2. дедупликация требует чтения найденного дубля для верификации совпадения (может же оказаться, что обнаружилась коллизия). так что стоит ожидать скорее падения скорости, чем прироста.

                        меня смущает, что вы работаете с файлом, а не с устройством, возможно, вы столкнулись с какой-то особенностью apfs


                      1. vadimr
                        18.06.2022 22:36

                        Trim просто говорит о том, что данные в блоке не нужны компьютеру. Он не приводит к их стиранию.

                        По поводу дедупликации: https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&cad=rja&uact=8&ved=2ahUKEwik3MGT37f4AhUD_CoKHabXA8AQFnoECCYQAQ&url=https%3A%2F%2Fwww.usenix.org%2Fevent%2Ffast11%2Fposters_files%2FKim_J.pdf&usg=AOvVaw3ZQZuX5QuBkueaCAgaHAP7

                        Работа 2010 года. Сейчас это уже общее место.

                        На HDD c APFS такого эффекта нет, там более-менее ровные времена доступа с производительностью около 10 MiB/s. Чуть быстрее с разными блоками, как и у Вас (думаю, это связано с тем, что файл из одинаковых блоков организуется как sparse и тратится время на алгоритм компрессии).


                      1. entze
                        19.06.2022 17:25

                        У APFS есть copy-on-write, возможно она слишком умная?


                      1. vadimr
                        19.06.2022 17:35

                        На HDD нет такого эффекта.


                      1. entze
                        19.06.2022 20:29

                        Тогда не оно, copy-on-write на HDD работает. Дедуплицировал свалку копий с SD карты.


            1. A1EF
              18.06.2022 19:30
              +1

              APFS - это Apple File System? Если да, то где это вообще есть, кроме Apple?

              Интересно было услышать именно в контексте Linux: какие файловые системы лучше "оптимизированы под SSD" и конкретно в чём эта оптимизация выражается?


              1. vadimr
                18.06.2022 19:34

                Я выше ответил, вроде.


          1. 13werwolf13
            20.06.2022 09:23

            f2fs, btrfs, zfs - изначально имели оптимизации для ssd, остальные фс тоже уже подтянулись


        1. A1EF
          18.06.2022 19:23
          +2

          Про тома и снапшоты: lvm2+ext4. Понимаю, что это вряд ли прозвучит убедительно плюс тащит лишнюю сущность, но на моей практике это частая комбинация. XFS вообще умеет только расширяться. К btrfs же я просто предвзят. Огрёб как-то проблем несколько лет назад, желание продолжать отпало.


          1. vadimr
            18.06.2022 19:26

            lvm2 никак не поможет исключить том из файловой системы ext4 (не потеряв её содержимое).

            С btrfs как-то у меня была одна проблема много лет назад, с тех пор тьфу-тьфу-тьфу. По сравнению с тем, сколько раз слетали ext'ы, это фигня.


            1. A1EF
              18.06.2022 20:00

              Почему? С помощью pvmove вполне вытаскивал диск.


              1. gavk
                19.06.2022 05:05

                Перед этим надо не забыть уменьшить ФС на размер вытаскиваемого диска.


        1. 13werwolf13
          20.06.2022 09:22

          не оптимизирована для SSD

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


          1. edo1h
            20.06.2022 11:00

            вы сначала приведите пример оптимизации для ssd, которая не применима к hdd.


            пока все «оптимизации», что я видел, заключались в отключении некоторых оптимизаций, изначально придуманных для hdd, и только.


    1. vitaly_il1
      20.06.2022 14:49

      ИМХО нужно использовать ту filesystem, которая по умолчанию в дистрибутиве.


  1. akakoychenko
    17.06.2022 23:48
    +10

    Вспомнилось, как на заре Гугла там писали данные только на внешние дорожки дисков (дальние от центра), ибо, скорость чтения там выше так, как, физически, область под головкой там движется быстрее при одинаковой скорости вращения шпинделя. Что позволяло им иметь SLA по скорости линейного чтения/записи выше, чем без таких приколов.

    А это было критично (тут уже не знаю, а предполагаю), видимо, потому, что они практиковали массивно-параллельные архитектуры до того, как это стало мейнстримом, и, соответственно, все воркеры ждали самый медленный диск (тот, на котором данные лежат ближе к центру), что приводило к простоям


    1. Schokn-Itrch
      18.06.2022 02:02

      Вспоминается Crash Bandicoot и "мусор" на диске.


      1. akakoychenko
        18.06.2022 12:07

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


  1. 4umak
    18.06.2022 00:04
    +6

    Переформатировав свои 100тб дисков

    просто так, на ровном месте.

    tune2fs -m 0 /dev/sda1


    1. AlexGluck
      18.06.2022 01:18
      +10

      Ага, а потом чтобы без простоя вернуть систему в строй надо... А ничего не надо, вы просто не залогинитесь даже рутом. Ведь при логине создаются дескрипторы, временные файлы, другая обязательная фигня и аля улю, ребут сервера в rescue режим. Выше описал альтернативное решение.


  1. Sergey_datex
    18.06.2022 00:05

    Ext файловые системы вообще очень жадны к резервируемому пространству под файловые структуры. Таких проглодитов в мире айти я больше не видел. 20 гиг под файловые структуры на терабайтном диске? а пжалста


    1. hogstaberg
      18.06.2022 01:53
      +2

      А другие файловые системы служебную информацию в ноосфере хранят, ага.


      1. Sergey_datex
        18.06.2022 02:00
        +6

        Нет, ее сильно меньше. Только в ext идиотская разбивка на блоки, в каждом из которых зарезервировано место под битмапы и прочую служебку. Разбивка очень "густая", блоки мелкие. Минусаторы могут детально изучить структуру файловой и глянуть ее с помощью какого-нибудь средства визуализации/подсчета занимаемого места. А, еще минус Ext - он равномерно "размазан" по всему носителю. При восстановлении данных нам это доставляет мнооого проблем. NTFS - вся мета (почти) в одном метафайле, обычно компактно лежащем в одном месте. FAT|exFAT - мета размазана по носителю, но там где она нужна, а не как в Ext.

        PS: все то идиотство в Ext тянется исторически с дремучих времен с цилиндрами и другими архаизмами...


        1. Schokn-Itrch
          18.06.2022 02:08
          +3

          Contig v1.8 - Contig
          Copyright (C) 2001-2016 Mark Russinovich
          Sysinternals

          c:$Mft is in 403 fragments
          c:$Mft::$BITMAP is in 318 fragments

          SSD. Диску около года. Только w10 и больше ничего. Свопа нет, гибернация отключена, все времянки в другом месте, оперативки 32 гига с первого дня. Так что "компактно в одном месте" это что-то не про нашу реальность.


          1. Sergey_datex
            18.06.2022 02:19

            Сколько там десятков гигабайт в mft?


            1. Schokn-Itrch
              18.06.2022 02:43
              +1

              Полтора. 15,8Гб.


          1. Busla
            18.06.2022 12:40
            +2

            По дэфолту MFT начинает фрагментироваться при заполнении диска более 87,5%. Похоже, вы перестарались с оптимизаторами и уменьшили в реестре резерв непрерывного пространства за MFT.

            Крутить NtfsMFTZoneReservation особого смысла нет, т.к. это не жёсткий резерв пространства в целом, а лишь задание зоны, которая будет использоваться в последнюю очередь.


            1. Schokn-Itrch
              18.06.2022 23:28

              Я ничего не делал вообще. Вы вообще прочитали условия? 32 гига оперативки. Даже будь я конченным извратом, который в принцие способен применять какие-то-там оптимизаторы, за год нельзя засрать систему так, что бы они потребовались.

              Фактически на этом компе установлены только SoftMaker Office, Vivaldi и WACUP. Причем все они установлены на второй раздел и все данные которые они используют находятся на втором разделе.

              P.S. Почему на офисной читалко-писалке 32Гб? "Патамушта" Осень прошлого года, переизбыток комплектухи у конкретной фирмы, низкие цены. По этой же причине там и 5750G.


              1. Busla
                19.06.2022 12:25
                +2

                Вот именно, что я прочитал условия:

                Свопа нет, гибернация отключена, все времянки в другом месте

                И пришёл к выводу, что кое-какими оптимизациями занимались.

                При чём в этом обсуждении объём RAM и модель CPU мне решительно непонятно, но если вам так хочется похвастаться конфигурацией, то пожалуйста.


          1. CoolCmd
            18.06.2022 12:41

            а если проверить $secure?


  1. Nbx
    18.06.2022 00:10
    +2

    Есть много интересных флагов, я например в своё время noatime всегда ставил.

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


  1. dyadyaSerezha
    18.06.2022 01:32
    +4

    Переформатировать 100 ТБ... Это ж сколько времени ушло на копирование данных с каждого диска и обратно на диск? Прямо жалко автора)


    1. screwer Автор
      18.06.2022 01:40
      +3

      Было чуть легче - обратно уже не копировал. Переносил данные на свеже-отформатированный, затем форматировал источник.


  1. hogstaberg
    18.06.2022 01:52
    +10

    Вообще то эти 5% нужны не для того чтобы логи писать. Они нужны для того, чтобы даже при почти полностью забитом разделе файловая система не начинала фрагментировать записываемые данные как сумасшедшая. И что-то мне подсказывает: у тех, кто уменьшает процент зарезервированного пространства, всё остальное место как раз таки занято. Ну или не занято, но тогда и крутилку трогать по сути незачем раньше времени.
    Строго говоря, я бы вообще не рекомендовал бездумно менять дефолтные параметры файловых систем без чёткого понимания того что, как и зачем меняется и чем это чревато.


    1. ilmarin77
      18.06.2022 02:04

      Ещё это нужно потому-что если на /tmp занято 100% (или /var), то даже root в эту систему не пробьётся через SSH.


      1. hogstaberg
        18.06.2022 07:02
        +1

        Ну это уже приятный бонус, реально ноги у этого растут именно из задачи уменьшения фрагментации данных, а конкретный процент от объема раздела из каких-то там соображений и расчётов, сделанных, ЕМНИП, ещё в 80-х годах в университете Беркли.


        1. vadimr
          18.06.2022 13:14
          +1

          Тут можно отметить, что для SSD вопрос фрагментации совершенно неактуален.


          1. screwer Автор
            18.06.2022 15:24

            для SSD вопрос с резервированием гораздо более актуален.

            Потому что надо обеспечить равномерный износ блоков. Если свободного запаса нет - придётся эти блоки сначала освободить, что удвоит нагрузку по записи, и удвоит износ ССД.


            1. vadimr
              18.06.2022 15:39
              +1

              Освобождение блоков не требует операции записи в случае наличия у фс понятия о TRIM.

              А равномерностью износа занимается контроллер SSD.


              1. screwer Автор
                18.06.2022 16:56

                Причем тут trim ? Вот есть у нас диск, занят на 99%. Чтобы равномерно изнашивать блоки - придется постоянно перемещать уже записанные данные, иначе ресурс записи у оставшегося 1% блоков исчерпается очень быстро.

                Если же свободно 50% можно особо не париться (до некоторого момента) и размазывать записи по ним.

                Трим же для понимания контроллеру, какие записи свободны, а какие нет.


                1. vadimr
                  18.06.2022 17:22

                  Блоки перемещает при записи сам контроллер, компьютер про это не должен думать.


                  1. screwer Автор
                    18.06.2022 18:57

                    Речь не о том, кто перемещает. А о влиянии свободного места на ресурс.


                    1. vadimr
                      18.06.2022 19:08

                      Так именно поэтому свободное место не влияет на ресурс.


                      1. screwer Автор
                        19.06.2022 00:41

                        Ну как же не влияет. В изначальном примере - если записывать-стирать данные, когда свободного места почти нет - что должен делать контроллер ? Жонглировать только пустыми блоками ? Тогда их ресурс исчерпается очень быстро.


                      1. vadimr
                        19.06.2022 11:33

                        Их ресурс исчерпается, но ресурс других за их счёт сохранится. Сумма не изменится.


                      1. Ndochp
                        19.06.2022 12:03

                        Так на сумму плевать, если мы сожгем 1% свободного и весь резерв при однократно записанных 99% остальных областях диск все равно уйдет в помойку.


                      1. vadimr
                        19.06.2022 12:09

                        Надо уж очень сильно постараться, чтобы реализовался такой сценарий. Годами не трогать 99% содержимого диска.

                        Речь-то изначально шла о совсем другом – что само по себе высокое заполнение диска якобы вредно, и поэтому его не допускает файловая система. А не о том, чтобы отлёживать на SSD однократно записанные данные, используя его в режиме CD-R.

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


                      1. edo1h
                        19.06.2022 12:26

                        Так именно поэтому свободное место не влияет на ресурс.

                        неправда.
                        посмотрите, чем различаются одноплатформенные накопители с ресурсом 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


                      1. vadimr
                        19.06.2022 12:30

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


                      1. edo1h
                        19.06.2022 12:51

                        а в чём разница-то?
                        у нас есть N ГБ nand, и есть D ГБ данных.
                        чем ниже отношение D/N, тем ниже waf, или, другими словами, выше ресурс.


                      1. vadimr
                        19.06.2022 13:07

                        Не так. Ресурс относится ко всему пользовательскому объёму диска, а не только к занятому данными. Поэтому число D тут не причём.

                        Есть N ГБ nand, M ГБ пользовательской памяти и (N-M) ГБ резерва блоков на подмену. Чем выше M/N, тем выше ресурс. А сколько у нас в моменте будет занято данными – вообще ни на что не влияет. Блоку пофиг, занят он или нет. И если диск практически пустой, а подменные блоки кончились, он так же выйдет из строя.


                      1. edo1h
                        19.06.2022 13:58

                        Есть N ГБ nand, M ГБ пользовательской памяти и (N-M) ГБ резерва блоков на подмену

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


                        почитайте сигейтовоскую статью про overprovisioning


                        вот вам картинка оттуда

                        image


                        освобождённое файловой системой пространство используется наравне с заводским OP.


                        P. S. статьи про overprovisioning есть и у интел, и у самсунга, и у кингстона, во всех написано примерно одно и то же.


                      1. vadimr
                        19.06.2022 14:00

                        Какая разница? Речь идёт о том, что пользователю доступно M блоков, а изначально имеется N, которое постепенно расходуется вплоть до M. Понятно, что все блоки внутри устроены одинаково, и когда я говорю о резерве, то имеется в виду резерв количества, а не конкретные физические блоки.

                        Ниже, чем граница Real OP на картинке, количество исправных блоков опуститься не может. Хоть называй то, что ниже, "Dynamic OP", хоть "Presumed Valid Data", хоть "Free Space".


                      1. 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 раз.


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


                        Так именно поэтому свободное место не влияет на ресурс.

                        надеюсь, что этот вопрос мы закрыли


                      1. vadimr
                        19.06.2022 15:08

                        Вот только эти все расчёты не имеют никакого отношения к занятым и свободным блокам с точки зрения файловой системы. Они касаются фактического значения битов в блоках. С точки зрения файловой системы эти блоки могут быть свободными, а с точки зрения контроллера SSD “грязными” (или наоборот, кстати).

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

                        Вы фактически своими расчётами доказываете тот факт, что чем больше на SSD записано нулей, тем эффективнее он работает. Это правда, но не имеет отношения к обсуждаемому вопросу резерва файловой системы.


                      1. 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-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-20031msec

                        c. заполнил нулями и и прочитал


                        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 и увидеть, что в этих секторах данных нет).


                      1. vadimr
                        19.06.2022 16:34

                        именно для того, чтобы сообщить контроллеру, что эти блоки свободны, и придумана команда trim

                        Да, но от этого не пропадает необходимость их чистить перед записью туда.

                        Относительно дальнейшего - мы вообще чтение или запись обсуждаем?


                      1. edo1h
                        19.06.2022 18:39

                        Относительно дальнейшего — мы вообще чтение или запись обсуждаем?

                        мы обсуждаем внутренние алгоритмы работы ssd. доступа к исходникам нет, реверс-инжиниринг прошивки слишком трудоёмкий, поэтому ориентируемся на косвенные данные, например производительность операций чтения или записи.


                        Да, но от этого не пропадает необходимость их чистить перед записью туда.

                        разумеется не пропадает. но что вы этим хотели сказать?
                        вот смотрите, у меня в блоке 1024 сектора с данными.
                        для 1023 я сделал trim, после этого сборщику мусора достаточно перенести один оставшийся сектор в другое место и можно делать этому блоку erase.


                      1. vadimr
                        19.06.2022 19:12

                        мы обсуждаем внутренние алгоритмы работы ssd. доступа к исходникам нет, реверс-инжиниринг прошивки слишком трудоёмкий, поэтому ориентируемся на косвенные данные, например производительность операций чтения или записи.

                        Так работа SSD при чтении и при записи – это две совершенно разные вещи. И чтение вообще не имеет никакого отношения ни к очистке страниц, ни к trim, ни к сборщику мусора, ни к заполнению диска.

                        разумеется не пропадает. но что вы этим хотели сказать?
                        вот смотрите, у меня в блоке 1024 сектора с данными.
                        для 1023 я сделал trim, после этого сборщику мусора достаточно перенести один оставшийся сектор в другое место и можно делать этому блоку erase.

                        Это всё верно, но к чему это? Я же не спорю с тем, что trim помогает сборщику мусора, для чего, собственно, он и придуман. Я говорю о том, что поддержание запаса логического свободного места в файловой системе вообще никаким образом с этим процессом не связано. Сборщику мусора по самому принципу его работы не нужно дополнительное свободное место.


                      1. edo1h
                        19.06.2022 21:47

                        Так работа SSD при чтении и при записи – это две совершенно разные вещи. И чтение вообще не имеет никакого отношения ни к очистке страниц, ни к trim, ни к сборщику мусора, ни к заполнению диска.

                        я показывал, что ваше утверждение «чем больше на SSD записано нулей, тем эффективнее он работает» неверно: нули для накопителя ничем не отличаются от прочих данных.


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

                        сборщику мусора (на самом деле не совсем правильно его так называть, скорее «сборщик не-мусора») приходится перемещать тем больше данных, чем меньше мусора.
                        trim помечает данные как мусор, так что trim напрямую влияет на его работу.


                      1. vadimr
                        19.06.2022 22:11

                        я показывал, что ваше утверждение «чем больше на SSD записано нулей, тем эффективнее он работает» неверно: нули для накопителя ничем не отличаются от прочих данных.

                        Если Вы пытались оспорить именно это утверждение, то Вы выбрали неверный эксперимент, не относящийся к нему. Нули, записанные Вами, сами пишутся и читаются с той же скоростью, но помогут в неопределённом будущем следующей операции записи в те же секторы завершиться быстрее. Так как не придётся стирать страницы. (Если только файловая система не напихает своей служебной информации между нулевыми данными, как, например, HPFS и NTFS устраивают band'ы для быстрого доступа на HDD; кстати, отличный пример решения, увеличивающего эффективность на HDD, но катастрофически неоптимального для SDD).

                        сборщику мусора (на самом деле не совсем правильно его так называть, скорее «сборщик не-мусора») приходится перемещать тем больше данных, чем меньше мусора.trim помечает данные как мусор, так что trim напрямую влияет на его работу.

                        Это опять верные утверждения, не имеющие отношения к обсуждаемому вопросу. Вообще вся работа сборщика мусора не относится к обсуждаемой теме.

                        “Мусор” в понятии сборщика мусора никак не соотносится с количеством занятых или свободных областей в файловой системе. Это просто результат выполненных ранее операций записи.

                        Свободное от файлов пространство может быть как чистым (состоящим из нулей), так и мусорным. И занятое файлами пространство может быть как чистым, так и кандидатом в будущий мусор.


                      1. edo1h
                        19.06.2022 22:49

                        Вообще вся работа сборщика мусора не относится к обсуждаемой теме.

                        как это не относится?!? именно она создаёт write amplification, то есть определяет расход ресурса nand


                        “Мусор” в понятии сборщика мусора никак не соотносится с количеством занятых или свободных областей в файловой системе. Это просто результат выполненных ранее операций записи.

                        так было до появления trim.
                        trim именно помечает данные как мусор для накопителя.


                        чистым (состоящим из нулей)

                        да нет для накопителя такого понятия «сектор, заполненный нулями». для него это просто обычный сектор с данными.
                        есть «незаписанный сектор» (на который был сделан trim и после этого не было операций записи)


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

                        почему их не придётся перетирать? придётся, nand не nor, не позволяет многократную перезапись одного участка.
                        да если бы и позволяло, не надо забывать про ecc, в nand физически будут записаны не нули.


                      1. vadimr
                        19.06.2022 23:14

                        как это не относится?!? именно она создаёт write amplification, то есть определяет расход ресурса nand

                        Она определяет расход ресурса, но она не зависит от размера пустого места на логическом диске.

                        так было до появления trim.trim именно помечает данные как мусор для накопителя.

                        Не всё, что пометил trim, является мусором. А только то, что при этом имеет ненулевые биты.

                        да нет для накопителя такого понятия «сектор, заполненный нулями». для него это просто обычный сектор с данными

                        Вот те на. Да это и есть самое главное для накопителя.

                        есть «незаписанный сектор» (на который был сделан trim и после этого не было операций записи

                        Это тоже есть, но это выше уровнем. Уже логика контроллера. А то – схемотехническая логика.

                        почему их не придётся перетирать? придётся, nand не nor, не позволяет многократную перезапись одного участка.

                        Что, по-вашему, делает операция стирания страницы?

                        да если бы и позволяло, не надо забывать про ecc, в nand физически будут записаны не нули.

                        Битовую маску страницы можно подобрать таким образом, чтобы результат маскирования ecc от нулевой страницы сам был бы равен нулю. Так-то там и единицы вместо нулей означают стёртое состояние, поэтому надо делать байтам данных xor $ff, так как данные чаще бывают обнулёнными, чем объединиченными.


                      1. 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.


                      1. 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 и помогает выполнять работу по преобразованию первого во второе, но это не единственный путь появления мусора.

                        Фух. Не знаю, как ещё понятнее написать.


                      1. edo1h
                        20.06.2022 11:36

                        Поэтому если вы скажете, что операции записи уменьшают ресурс SSD, то я соглашусь, но это и так самоочевидно. А вы пустились доказывать, что ресурс уменьшается от уменьшения свободного места в ФС, и это неверно.

                        прочитайте внимательнее что я писал.
                        смотрите, есть два ssd, A и B, каждый по терабайту, на каждом файловая система занимает весь раздел.
                        на этих ssd лежит одинаковая база данных размером, ну пусть 128 ГБ.
                        но на ssd A ничего больше нет, на ssd B помимо БД лежат картинки, которые не изменяются, файловая система занята на 99%.


                        данные в БД меняются, и пусть, скажем, за неделю в БД переписывается 16 раз (то есть 2 терабайта записи).


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


                      1. vadimr
                        20.06.2022 12:16

                        Я с этим выводом не спорю. Но вопрос тут не в свободном месте, а в длительно лежащих без изменения файлах картинок. Любые долго лежащие файлы блокируют страницы памяти под собой.


                      1. edo1h
                        20.06.2022 12:27

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

                        нет, именно в занятом месте.
                        a. если бы мы переписывали эти картинки периодически (при это свободное место не менялось бы), то waf оставался бы столь же высоким;
                        b. если мы сотрём эти картинки (и trim работает), то waf для вновь записываемых на накопитель B данных будет таким же, как и для записываемых на накопитель A.


                      1. 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 (а такого я не наблюдал на тех накопителях, что я тестировал).


                      1. vadimr
                        20.06.2022 13:57

                        One or two further writes to the block could be sustained

                        Даже если так, это никак не меняет того факта, что стёртая страница уже нулевая (единичная).

                        P. S. ну а если бы проблема записи нулевых байт волновала производителей ssd, то, уверен, они бы решили это путём приравнивания записи нулей к trim

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


                      1. edo1h
                        20.06.2022 14:12

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

                        какой ещё сборщик мусора? он работает с nand.
                        а неинициализированные сектора существуют только в ftl, в nand они не хранятся.
                        то есть нам достаточно пометить lba как неинициализированный и не писать его вовсе в основную область nand (ну а старую версию в nand, если она есть, отметить как мусор). именно это и делает команда trim.
                        теперь чтение этого lba будет возвращать нули (притом на хорошей скорости; пример я приводил, но он не особо показательный — встречал накопители, на которых чтение неинициализированной области в 2-3 раза быстрее чтения реальных данных).


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


                      1. vadimr
                        20.06.2022 14:17

                        Так этот сектор не является неинициализированным. Он инициализирован и содержит нули. Туда, в отличие от неинициализированных секторов, нельзя ничего перемещать.


                      1. edo1h
                        20.06.2022 14:25

                        omg… куда туда?
                        отношение страниц nand к lba в ftl не обязательно 1:1.
                        если lba помечен как неинициализированный, то ему не соответствует никакая страница в nand.


                      1. 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


                      1. edo1h
                        20.06.2022 15:59

                        То, что вы предложили, опирается на предположение, что неинициализированный элемент LBA будет при чтении давать нули.

                        а вам встречались иные примеры?


                        Такая опция называется DRAT (Deterministic read data after TRIM) или DZAT (Deterministic read zeros after TRIM)

                        эти опции не про то как будут читаться неинициализированные данные, а про то обязательно ли контроллер будет отмечать данные как неинициализированные, и будет ли он это делать сразу или может отложить.
                        дело в том, что изначально эти команды воспринимались как необязательная рекомендация, и разработчики контроллера могли принять решение в каких-то случаях ради лучшей производительности «срезать углы». например, sandforce так делали, после trim'а чистилась только часть данных.


                1. 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


                  я не говорю про производителей второго-третьего эшелона


  1. DuD
    18.06.2022 02:04
    +12

    Укажите в статье что такого нельзя делать на основном разделе. А то сейчас народ по незнанию побежит отнимать "награбленное" системой, а потом окончанию места будет вас же и проклинать. )

    А то такого много можно насоветовать. "Отключайте fsync под базами, они будут быстрее работать!", "Используйте RAID0 вместо RAID1, так вы сэкономите кучу места!" и прочие облегчающие жизнь советы...


    1. vikarti
      18.06.2022 12:55

      Так ведь компании с большой капитализацией некоторые именно так и делают — см https://habr.com/ru/news/t/653527/


  1. ALiEN175
    18.06.2022 03:26
    +1

    а потом при занятых 100 Тб ext4 превратится в тыкву?

    Переформатировав свои 100тб дисков, я получил дополнительные 5Тб дискового пространства, просто так, на ровном месте.


    А если переформатировать в btrfs или zfs со сжатием, то еще получите как минимум 10ТБ, а в лучшем случае все 200.


  1. BugM
    18.06.2022 03:34
    +2

    На практике диски лучше вообще не заполнять больше 80% от номинальной емкости. Если вам важна скорость работы.

    Куда и подо что там уйдут эти 20% на самом деле не важно.


    1. AndreyDmitriev
      18.06.2022 08:29

      Да, я на SSD обычно создаю небольшой "блокирующий" раздел, чтобы не забивать его под горлышко.


      1. 13werwolf13
        20.06.2022 09:28

        таким образом вы делаете "хорошо" ssd

        но у почти всех фс есть свои проценты свободного места меньше которых становится "медленно и грустно", так что лучше держать 20% свободным на разделе чем 20% на разделе + 20% вне раздела.


    1. Sly_tom_cat
      18.06.2022 13:30
      +1

      Я забивал диск на 99%+ процентов, и все ок...

      Только там была BTRFS, которая хоть и имеет небольшой резерв, но он не для рута, а именно для самой ФС. Что позволяет даже при 0% свободного места не мешает удалять файлы, под-тома или даже делать НОВЫЕ снапшоты.


    1. screwer Автор
      18.06.2022 15:25

      Сейчас большая часть дисков заполнена на 99.9%. И никаких проблем с этим. Дисков уже 120тб. Жду ещё 40тб в этом месяце, чтобы свободное место появилось наконец-то.


      1. BugM
        18.06.2022 15:27

        Вы точно на них активно пишите и читаете? В моих тестах после 80% заполнения деградация скорости значительная и легко видна приборах.


        1. screwer Автор
          18.06.2022 16:58
          -1

          Пишу и читаю неактивно. Не более сотни гигабайт в день на диск. Т.е.особой разницы между 240 и 180 мб сек не замечу. Основная масса файлов - громадные блобы на десятки и сотни гигабайт.


          1. BugM
            19.06.2022 00:00
            -2

            Это 25% как бы. Для нагружённой системы это означает на 25% больше серверов для сохранения нужной производительности.

            Это заметные деньги. Простить 20% емкости диска дешевле.


            1. screwer Автор
              19.06.2022 13:47

              Пусть даже 300Gb в день пусть при скорости 100мб/сек это час работы диска. Т.е. моем случае в разы меньше В скорость диска "в долгую" ничего не упирается. Кроме того, для горячих данных очень эффективно работает системный кеш.

              А вот диски совсем недешевые. Это первые я брал по 25тр за 10тб (WD Gold KRYZ). Потом они подскочили до 100, благодаря чиа-майнерам, и, не успев полностью отыграть обратно, опять выросли до сегодняшних 50тр, вопреки циферкам курса

              Эти сервера - мои личные, домашние. Купленные/собранные за собственные деньги

              Для быстрых данных у меня есть несколько дисковых полок, по 25 600гб 10к дисков в каждой. Но пока vendor lock я с самих полок не снял, только с дисков.


      1. myc
        19.06.2022 00:38
        +1

        Заливаю диски под завязку. И никаких проблем с этим. Дисков уже несколько сотен петабайт. m=0. НО! Данные эти статичны и почти не перезаписываются.

        Фрагментация при нехватке места бич любой фс. На hdd это смерти подобно. На ssd не так критично. Там другой подход — значительно увеличиваем зону OP, при этом сокращаем резерв фс.


  1. ALiEN175
    18.06.2022 03:53
    +25

    И уберите кликбейт заголовок. Я сразу подумал про 5 ТБ облако, а не ваши несчастные 5% от 100 Тб.
    Как просеренить у себя 5 терабайт свободного места, не читая man.
    Или вы готовы всем желающим раздать 5 Терабайт? Как в заголовке — нахаляву?


    1. justPersonage
      18.06.2022 14:04
      +5

      Или вы готовы всем желающим раздать 5 Терабайт? Как в заголовке — нахаляву?

      Я по заголовку, думал, что где-то диски раздают, как книги, бесплатно.


  1. aik
    18.06.2022 09:04
    +2

    Tune2fs — и не надо ничего форматировать.
    На системных разделах, впрочем, в ноль резервирование убирать не стоит.


  1. Fodin
    18.06.2022 09:05
    +19

    Как нахаляву получить 10 миллионов рублей? Положить на год 100 миллионов в банк под 10% годовых.


    1. d2d8
      18.06.2022 16:29
      +1

      Это может быть и рецепт как из 100 млн сделать 10.


  1. kvazimoda24
    18.06.2022 09:52
    +7

    Что же с вами будет, когда вы осилите мануал mkfs.ext4 и узнаете о возможности уменьшить размер инодов с 256 байт, до 128 и о возможности задания количества этих самых инодов. Ведь, по умолчанию mkfs создаёт очень сильно с запасом инодов, и на моей практике всегда можно сильно уменьшить их количество. В целом, практически всегда хватает 5 миллионов с хорошим таким запасом.

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

    А ещё в Дебиан есть пакет ядра linux-image-cloud-amd64. Он занимает всего 20 МБ, для сравнения, классическое ядро, что ставится по умолчанию, весит около 700-800 МБ. Это ядро можно использовать в KVM виртуалках, если сеть и диски у них virtio, и вы не прокидываете реальные устройства устройства в виртуалку.


    1. v1000
      18.06.2022 09:54
      +5

      Только вот иногда люди не следят за количеством свободных инодов. И однажды база на полном ходу грохнулась из-за нехватки инодов. При этом свободного места на дисках хватало. Но вот про иноды немного забыли.


      1. kvazimoda24
        18.06.2022 09:58
        +2

        Я потому и написал, что надо быть аккуратным.

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


  1. SilverHorse
    18.06.2022 10:53
    +6

    Знаете, это просто офигенная тактика написания статей на хабре. Буквально вчера у меня в трекере всплыла https://habr.com/ru/post/339470/ про это самое из-за некропост-коммента, я прочитал, хмыкнул, закрыл. Походу у автора, как и у многих других, оно тоже всплыло в трекере, для него это стало открытием, он проделал описанное в статье на своем кластере, обалдел от результата... и решил написать про это свою статью? Я открываю "читают сейчас"... и испытываю когнитивный диссонанс вместо со странным дежа вю. Автор, все новое - хорошо забытое старое?

    Я понимаю, что это очередное нытье про "хабр - не торт", но имейте совесть уже, тем более что "статья" про содержимое man в линуксовой утилите, ну е-мое, дальше уже снизу стучать начнут...


    1. vassabi
      18.06.2022 15:25
      +1

      комментарии зато замечательные! (про другие способы "чо порезать" и свои любимые ФС :) )


  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 не возникает.


  1. SporeMaster
    18.06.2022 15:01
    +3

    >И никто из моих знакомых-линуксоидов не знал.

    Ужасные знакомые, ужасная статья. Про tunefs сразу сказали, можно ещё добавить, что смысла трогать эту крутилку нет, т.к. в реальной эксплуатации

    1. руту всё равно даёт писать до 100%

    2. когда кончается место, то уже на и 90% надо докинуть дисков. Маргинальные случаи со статичной помойкой где 1 раз заполнили на 99.99% и ничего не меняется слишком редки.


    1. A1EF
      18.06.2022 22:07

      Более того, несколько раз меня очень выручило это резервирование когда СРОЧНАА нужно было докинуть хоть чуть-чуть места и взять его было больше неоткуда.


  1. domix32
    18.06.2022 21:09

    Гиги за логи


  1. Balling
    19.06.2022 07:24

    >На логи, да!

    Не на логи, а на ФС, туда ничего не пишется и вообще не трогается. Файловая система по умолчанию такая отвратительная, что ей нужно свободное место или она замедляется очень сильно. Так как в отличии от windows, защита от фрагментирования работает методом а "давай напишем прям в центр свободного места". Поэтому в конце ей нужно свободное место посредине всех нефрагментированных файлов.

    У автора видно было не все в порядке.


  1. idelgujin
    20.06.2022 05:37
    +1

    Кликбейтный заголовок. Не 5 Тб дисков, а 5 Тб дискового пространства в имеющемся массиве. Это большая разница


  1. DNolde
    20.06.2022 17:13

    Раньше на UNIX (SunoS, Solaris, Irix) резервировалось по дефолту 10% места. Достаточно один раз установить диск в компьютер, посмотреть на результат и сразу запомнишь опцию -m.


  1. ValdikSS
    20.06.2022 21:18

    mkfs.ext4 -O '^resize_inode' отключит резервные inode, которые выделяются для возможности их добавления при ресайзе диска в сторону увеличения. Если вы не собираетесь ресайзить файловую систему, то эту опцию можно безболезненно отключить.

    mkfs.ext4 -N 1000000 статически задаст количество inode'ов — это основной элемент, «расходующий» свободное место диска и увеличивающийся с его размером.

    mkfs.ext4 -T largefile задаст тип файловой системы в "largefile" — оптимизация распределения и количества inode'ов под конкретный сценарий использования. Возможные значения и их конкретные параметры смотреть в /etc/mke2fs.conf.