Ещё один взгляд на вопрос «нужна ли дефрагментация для SSD»

    Несомненно, вопрос, вынесенный в заголовок статьи, не нов, поднимался не раз и по нему достигнут консенсус «не особо нужна, и даже может быть вредна».
    Однако недавнее обсуждение в комментариях заставило меня ещё раз задуматься.


    Со временем любой SSD всё равно сильно фрагментируется (внутри, в FTL)… Свежезаписанный SSD при линейном чтении даст высокую скорость, а уже поработавший — гораздо ниже, потому что линейными оно будет только для вас.

    Да, обычно такое не должно происходить: или мы пишем «понемногу» в мелкие файлы/небольшие блоки метаинформации ФС (скорость линейного чтения которых нас не особо волнует), либо же мы пишем «помногу» в большие файлы и всё будет хорошо. Бывает и дозапись мелкими блоками в большие файлы — логи, например, однако они относительно короткоживущие и особой проблемы я тут не вижу.
    Но легко представился вполне реальный сценарий, при котором всё-таки внутренняя фрагментация SSD может проявиться: файл базы данных, в который идёт достаточно активная случайная запись. Со временем он (оставаясь нефрагментированным на уровне операционной системы) окажется физически очень даже фрагментированным, что может существенно снизить скорость seq scan, резервного копирования и т.п.


    Для проверки я написал скрипт и провёл тесты.


    Спойлер: проблема присутствует (существенно влияет на производительность) только на одной из попавшихся под руки моделей (и та позиционируется производителем не как datacenter, а как десктопная/ноутбучная).


    Про что тут вообще речь? Какая ещё фрагментация внутри SSD?

    Если в двух словах, SSD устроен очень непросто. В NAND flash можно писать (точнее стирать) только большими блоками. А операционная система видит SSD как набор 512-байтовых (или 4096-байтовых) секторов, каждый из которых может быть адресован независимо.
    Чтобы как-то это совместить, придумана такая вещь, как FTL (flash translation layer): данные во flash-памяти лежат не последовательно, а (очень условно) в том порядке, в котором они были записаны, что-то вроде log-структурированных файловых систем.
    Такие структуры очень хорошо обрабатывают случайную запись, превращая её в последовательную, но, увы, ничто не бывает бесплатно — в результате зачастую последовательное чтение превращается в случайное.


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


    Идея скрипта: создаём файл на несколько гигабайт, заполненный случайными данными, замеряем скорость последовательного чтения.
    Далее используя случайный доступ переписываем часть тестового файла и снова измеряем скорость линейного чтения. Если наши подозрения верны, то теперь чтение из файла будет идти медленнее.
    После каждой записи делаем по три операции чтения с задержкой между ними на случай, если какой-то накопитель в фоне производит дефрагментацию и потом скорость чтения улучшится.


    Немного о том, почему нужно заполнять SSD перед тестированием

    Не раз встречал обзоры, в которых запускают чтение с нового накопителя, получают какие-то фантастические цифры и, ничтоже сумняшеся, публикуют их. Через какое-то время тест повторяют уже на не столь девственном диске, и вдруг оказывается, что время доступа выросло, а скорость, соответственно, упала.
    Дело в поддержке TRIM: контроллер внутри SSD может «знать», что в конкретном блоке нет полезных данных, информация об этом хранится в FTL. И при запросе на чтение из такого блока он не обращается к медленной NAND flash, а сразу возвращает нули. На новом накопителе все блоки помечены как неиспользуемые, соответственно, в тестах на чтение он готов ставить рекорды. Только нас же интересует с какой скоростью SSD умеет отдавать не нули, а данные.


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


    Поэтому, перед тестированием стоит заполнять SSD несжимаемыми данными (в linux хорошим источником может служить /dev/urandom).


    шелловский скрипт

    тестовый файл создаётся в текущем каталоге.


    тестировал только под linux c dash, coreutils и fio из debian buster, с другими дистрибутивами навряд ли будут проблемы, а вот под freebsd и другие операционные системы скорее всего скрипт придётся «допиливать».


    echo preparing...
    dd if=/dev/urandom of=testfile bs=1M count=4096 status=none
    sync
    for A in 1 2 3; do
        sleep 10
        dd if=testfile of=/dev/null bs=1M iflag=direct
    done
    
    for A in 50 200 800 4000; do
        echo fio: write ${A}M...
        fio --name=test1 --filename=testfile --bs=4k --iodepth=1 --numjobs=1  --rw=randwrite  --io_size=${A}M --randrepeat=0 --direct=1 --size=4096M > /dev/null
        sync
    
        for B in 1 2 3; do
            echo sleep ${B}0
            sleep ${B}0
            dd if=testfile of=/dev/null bs=1M iflag=direct
        done
    done
    
    echo sleep 3600
    sleep 3600
    dd if=testfile of=/dev/null bs=1M iflag=direct

    Обнаружилось, что NVMe-накопители intel у меня сейчас только на серверах с windows; пришлось с помощью гугла, stackexchange и какой-то матери слепить вариант и под винду


    вариант на ps

    Из внешних зависимостей только fio; путь к exe-файлу и временному файлу указывается в первых строчках скрипта.


    $testfile = "c:\temp\testfile"
    $fio = "c:\temp\fio-3.18-x64\fio"
    
    echo "preparing..."
    
    $filestream = New-Object System.IO.FileStream($testfile, "Create")
    $binarywriter = New-Object System.IO.BinaryWriter($filestream)
    $out = new-object byte[] 1048576
    
    For ($i=1; $i -le 4096; $i++) {
        (new-object Random).NextBytes($out);
        $binarywriter.write($out)
    }
    $binarywriter.Close()
    
    For ($i=1; $i -le 3; $i++) {
        sleep 10
        $time = Measure-Command {
            Invoke-Expression "$fio --name=test1 --filename=$testfile --bs=1M --iodepth=1 --numjobs=1  --rw=read --direct=1 --size=4096M" *>$null
        }
    
        $seconds = $time.Minutes*60+$time.Seconds+$time.Milliseconds/1000
        echo "read in $seconds"
    }
    
    foreach ($A in 50,200,800,4000) {
        echo "fio: write ${A}M..."
        Invoke-Expression "$fio --name=test1 --filename=$testfile --bs=4k --iodepth=1 --numjobs=1  --rw=randwrite  --io_size=${A}M --randrepeat=0 --direct=1 --size=4096M" *>$null
        For ($i=10; $i -le 30; $i+=10) {
            echo "sleep $i"
            sleep $i
            $time = Measure-Command {
                Invoke-Expression "$fio --name=test1 --filename=$testfile --bs=1M --iodepth=1 --numjobs=1  --rw=read --direct=1 --size=4096M" *>$null
            }
    
            $seconds = $time.Minutes*60+$time.Seconds+$time.Milliseconds/1000
            echo "read in $seconds"
        }
    }
    
    rm $testfile

    Получил следующие результаты:


    • фоновой дефрагментации в тестируемых моделях не обнаружено: скорость чтения не повышается через некоторое время после записи, в том числе длительный «отстой» (час и даже более суток) ничего не меняет, поэтому в таблице ниже привожу просто лучший результат из трёх запусков;
    • под windows почему-то время чтения менее стабильно и оказалось выше ожидаемого (впрочем, возможно, дело в том, что эти сервера оказались более нагружены);
    • продолжение записи сверх указанного в скрипте (перезапись файла более одного раза) не влияет на производительность.

    Время чтения (в секундах) файла размером 4Гб для разных дисков:


    Диск Первое чтение после последовательного заполнения файла После случайной записи 50Мб +200Мб +800Мб +4000Мб
    intel S3510 SSDSC2BB480G6 10.7 10.7 10.8 10.8 10.8
    toshiba XG5 KXG50ZNV512G 1.9 2.9 3.7 4.8 6.8
    samsung PM963 MZQLW960HMJP 2.8 3.2 3.5 3.7 4.2
    samsung PM983 MZQLB960HAJR 3.3 3.6 3.4 3.4 3.4
    samsung PM981 MZVLB1T0HALR 1.8 1.8 2.1 2.5 3.5
    samsung PM1725b MZPLL1T6HAJQ 1.8 1.9 2.0 2.3 2.9
    micron 5200 eco 9.3 9.8 10.4 12.2 10.7
    samsung PM883 MZ7LH1T9HMLT 7.9 7.9 8.1 8.1 8.0
    intel P3520 (win) 5.8 5.9 6.0 6.1 5.8
    intel P4500 (win) 4.2 4.2 4.3 4.4 4.3

    Жирным отмечены DC модели (остальные — десктопные/ноутбучные); где SATA, а где NVMe, думаю, видно без пояснений.


    Мы видим, что по мере случайной записи в файл у самсунга PM981 скорость чтения падала и в итоге упала вдвое (но осталась, правда, достаточно неплохой), а у единственной тошибы в таблице — вовсе в 3.5 раза, фактически сравнявшись с таковой у SATA устройств.
    С другой стороны, у большинства устройств случайная запись или вовсе не повлияла на производительность, или повлияла незначительно.


    Моя интерпретация этих результатов: скорость линейного чтения у SSD действительно может деградировать со временем, однако деградация, вызванная внутренней фрагментацией, не носит совсем уж фатального характера на большинстве дисков (на дисках intel, например, она вовсе незаметна; на дисках samsung если и заметна, всё равно скорость чтения остаётся вполне приемлемой).


    Остаётся открытым вопрос деградирует ли скорость чтения со временем по другим причинам (например, из-за износа NAND flash).
    Могу сказать про тошибу XG5: разницы в поведении между диском, на который по SMART было записано >>150Тб, и новым диском я не заметил ­— или 300-400 перезаписей недостаточно, чтобы износ flash стал заметен, или он вовсе не влияет на производительность SSD.


    По поводу падения производительности после случайной записи: у меня как раз на такой тошибе хранится достаточно нагруженная БД mysql размером около 100Гб. Действительно, в полном соответствии с изложенными выше теорией и измерениями, скорость чтения «боевых» таблиц mysql оказалась достаточно низкой (около 600Мб/с), скорость же чтения других крупных файлов с той же файловой системы гораздо выше (>2Гб/с).


    Как бороться с внутренней фрагментацией SSD

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


    sync
    fsfreeze -f /mountpoint
    dd  if=/dev/nvme0n1p2 of=/dev/nvme0n1p2 bs=512M iflag=direct oflag=direct status=progress
    fsfreeze -u /mountpoint

    Его можно запустить на «живой» системе без размонтирования ФС и остановки сервисов. Он тоже может привести к некоторому простою из-за замораживания ФС, но при желании можно разбить его на несколько итераций, чтобы уменьшить время, на которое замораживается ввод-вывод. Есть ещё одно «но»: я не уверен на 100%, что все SSD правильно обрабатывают ситуацию «пишем нули в область, для которой до этого делали TRIM» (то есть с точки зрения накопителя области ФС, на которые ранее делали TRIM, могут теперь считаться не свободными, а занятыми данными).
    В целом, рекомендация «забить смириться или выбирать диски» остаётся в силе.


    Резюме: дефрагментация может быть полезна для некоторых SSD, однако не совсем такая (совсем не такая?) как для HDD. Нам важно не только то, что файл расположен в непрерывной цепочке секторов, но и то, что запись в эти секторы шла последовательно.


    P.S. был бы благодарен, если бы читатели запустили скрипт у себя и привели цифры для своих SSD, так как моя выборка накопителей достаточно однобокая.

    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 85

      +5
      А почему вообще для ssd скорость чтения зависит от того, читаем мы последовательно или в случайном порядке? Позиционирования головок то нет.
        +1
        Вангую что зависит от поддерживаемых контроллером команд обращения к памяти. Одни поддерживают кэшированное чтение по случайным адресам, а другие — только последовательное.
          0
          В иопсы упирается видимо. Лично я после установки системы ссд дефрагментирую. Пусть системные файлы лежат последовательно — хуже не будет, а несколько гигов ресурса флеша погоды не сделают.
            +3

            Последовательно? Но в ssd же таблицы трансляции адресов, которые ОС не контролирует…
            У вас есть замеры скорости до и после дефрагментации?

              0
              Как я уже написал ниже, фрагментация на уровне FS может приводить к дополнительным чтениям, что опять же тратит такой ресурс как IOPS.
                –1
                По идее расположение данных во флеше вообще роли не играет. Всё равно ссд для каждого блока лезет в таблицу трансляции. Тем не менее последовательное чтение файла гораздо быстрее. Пока команда дойдёт до таблицы адресов — уже сожрёт изрядно времени цпу и контроллера ссд…
                0
                Именно. А IOPSы складываются из времени доступа к матрице FLASH. Например, если взять типичную NAND, то у неё между матрицей FLASH и шиной есть два буфера, размер которых совпадает с размером страницы чтения/записи (не путать с размером блока стирания, он больше). И при выполнении команды чтения время на загрузку этого буфера не нулевое и вполне конкретное (например, для K9F4G08U0A это 25мкс). Но если изменить алгоритм чтения и задействовать второй буфер, то совмещение времени выборки данных из матрицы и выгрузкой их на шину данных позволит получить почти двухкратный прирост. При записи это время ожидаемо сильно растёт.

                Накопители же используют сразу несколько микросхем в параллель для увеличения скорости чтения/записи, используют достаточно крупный набортный буфер ОЗУ, чтобы скрыть время работы с массивом FLASH между отсутствием обращения к накопителю со стороны системы. Сами NANDы тоже развиваются в плане достижения более высоких скоростей работы, но базовый принцип работы NAND это не отменяет.

                Именно поэтому, скорость работы SSD следует оценивать не по линейной скорости а конкретно по IOPS. Причём, не по маркетинговым цифрам а в тестах. Ведь, даже если читать фрагментированный большой файл или папку то приходится делать дополнительные чтения метаданных.
                  +1
                  Данные «последовательно», или «равномерно и симметрично размазанными по чипам и блокам флэша» не будут находится — FTL будет их часто двигать для выравнивания износа ячеек, не только из-за записи но даже из-за интенсивного чтения.
                    0

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

                      +1
                      Зонирование и неймспейсы еще большая редкость, да и-то будут доступны только для NVMe.
                      А вообще SSD пишут во всю доступную емкость флэша, и параллельно на все чипы NAND, только данные по блокам не всегда будут симметрично записаны, иногда вне очереди влетает срочная запись от сборщика мусора или flush от драйвера. Так что данные на NAND в принципе почти всегда фрагментированы, вопрос в том, насколько они равномерно замаплены на флэше, чтобы их можно было в параллели читать, или что-то приходится читать в одну нитку с одного чипа (в худшем случае).
                        0
                        Диск использует весь объём для записи.
                          0

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


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


                          скорее опасна обратная ситуация: 90% диска забито статичными данными (скажем, коллекция фильмов), а в оставшиеся 10% идёт активная запись (ну, например своп, и на машине у вас куча виртуалок, которым не хватает памяти). если вся запись пойдёт только в эти 10% диска, то ресурс этих областей быстро исчерпается, чтобы такого не произошло, накопитель должен периодически перемещать записанные данные. но как это реализовано (и реализовано ли во всех накопителях) — мы не знаем.

                            0
                            У вас странные выводы.
                            Вы протестировали несколько устройств, получили РАЗНЫЕ результаты, в том числе и явно свидетельствующие, что некоторые производители уже решили эту проблемы.
                            Но вывод у вас «SSD деградируют».

                            Так давайте все-же честно интерпретировать результаты — некоторые модели некоторых производителей имеют неоптимальные алгоритмы, из-за чего они могут деградировать в таких случаях.
                              0

                              поясните, пожалуйста, к чему относится ваш комментарий. перечитал несколько раз свой комментарий, на который вы ответили —ничего про «SSD деградируют» я в нём не писал.

                                0
                                Быть может речь за это?
                                если вся запись пойдёт только в эти 10% диска, то ресурс этих областей быстро исчерпается

                        +6

                        Напоминает:
                        "Лично я садясь на самолёт на всякий случай окропил его святой водой, перекрестился. Хуже не будет, а покой дорог, однако"

                          –2
                          Ну, кому напоминает — пусть хихикают. А мне не напоминает: если эффект от религиозных ритуалов ни один прибор не засекает, то чтение каждого дополнительного блока файла — это вполне конкретная ~сотня микросекунд накладных расходов.
                        0
                        Автор предположил, что возможно это связано с трансляцией блоков, т.е. файловая система устроена блоками по 512 байт или 4кбайта, а на диске физически лежит всё немного по другому, например, может быть по 4 килобайта, или ещё как нибудь, например страница по 16 кб, в этом случае сперва читаем кусочек из одной страницы кратный сектору нашей ФС, а потом другой, и так читая по кусочкам получается что мы прочитали например 10 страниц по 16 кб, а забрали оттуда например всего 10х512 байт. Такая же проблема с фрагментацией есть на HDD, но там не только связано с расположением секторов на диске, но и перемещение головки на новую дорожку. Кстати с появлением HDD с сектором 4К появилась проблема с выравниванием секторов, вроде бы эта же проблема появилась и на SSD.
                          0

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


                          вот с тестовой машины:


                          root@debian:/# fio  --name=test1 --filename=testfile --bs=4k --iodepth=1 --numjobs=1  --rw=read --timeout=10 |grep IOPS
                            read: IOPS=425k, BW=1659MiB/s (1740MB/s)(16.0GiB/9874msec)
                          root@debian:/# fio  --name=test1 --filename=testfile --bs=4k --iodepth=1 --numjobs=1  --rw=randread --timeout=10 |grep IOPS
                            read: IOPS=12.4k, BW=48.6MiB/s (50.0MB/s)(486MiB/10001msec)
                          root@debian:/# fio  --name=test1 --filename=testfile --bs=4k --iodepth=1 --numjobs=1  --rw=read --direct=1 --timeout=10 |grep IOPS
                            read: IOPS=12.5k, BW=48.7MiB/s (51.0MB/s)(487MiB/10001msec)
                          root@debian:/# blockdev --setra 0 /dev/nvme0n1p2; fio  --name=test1 --filename=testfile --bs=4k --iodepth=1 --numjobs=1  --rw=read --timeout=10 |grep IOPS
                            read: IOPS=12.5k, BW=48.6MiB/s (51.0MB/s)(487MiB/10001msec)

                          первая попытка: последовательное чтение блоками по 4кб (включается упреждающее чтение операционной системы), имеем >>400к iops.
                          вторая попытка: случайное чтение, имеем 12.4к iops (операционная система догадывается отключить упреждающее чтение).
                          третья попытка: последовательное чтение в обход кэша, имеем 12.5к iops (операционная система не может использовать упреждающее чтение).
                          третья попытка: последовательное чтение с явно отключенным упреждающим чтением, имеем 12.5к iops.


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


                          почему же при внутренней фрагментации падает скорость линейного чтения — сие пока для меня тайна великая есть.

                            0
                            почему же при внутренней фрагментации падает скорость линейного чтения — сие пока для меня тайна великая есть.

                            Ответ тут.
                            На верхней части этой картинки:
                              0

                              не понимаю.


                              контроллеру пришли 32 команды "прочитай 4кб сектор", какая ему разница, расположены физически эти сектора подряд, или разбросаны по нескольким страницам с «дырками»?

                                0
                                Это можно объяснить только тем, что он читает не по 4КБ, а гораздо большими областями, например, целыми страницами. Думаю, это основной момент.

                                У многих профессиональных SSD сектор вообще 512 байт. Явно это сделано в угоду совместимости, а не является оптимальным размером для NAND.

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

                                Вот из википедии:
                                Технология NOR позволяет получить быстрый доступ индивидуально к каждой ячейке, однако площадь ячейки велика. Наоборот, NAND имеют малую площадь ячейки, но относительно длительный доступ сразу к большой группе ячеек.
                                  0
                                  Так ведь уже с 2011 года размер сектора 4к у всех HDD
                                  Почему SSD все еще 512байт спустя 10 лет?
                                  Тем более что кластера и блоки по дефолту тоже уже 4к лет 10.
                                    0
                                    Нет, не у всех. У многих HDD сектор 512N и 512E.
                                    У большинства SSD сектор 512 байт.

                                    Потому что сектор 512 байт универсальнее. Вот почему. Например, vmware лучше работает с сектором 512 байт.
                                  0
                                  Так ведь чипов не 32 шт. чтоб считать сразу со всех одновременно, а некоторые архитектуры ещё имеют нелинейную адресацию, что может вызывать проблемы*
                                  Из тех что я тыкал, были, условные, команды -«читать не переставая», «читать х последовательно», «читать одну страницу». Притом время на команду была сильно разная, и иногда было выгодней «дефрагментировать» и читать целиком 1МБ, а не по 100 раз обрывая чтение. Разница при этом может быть до ~40% (могу и врать, это было года 3-4 назад)
                                0
                                итого: именно упреждающее чтение обеспечивает более высокую скорость линейного чтения на SSD

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

                                  0

                                  А почему вы так прицепились к 4КБ? У большинства ссд логический блок вообще 512 байт. Поэтому можно было написать "блоками больше 512 байт".

                                    0
                                    У большинства ссд логический блок вообще 512 байт

                                    но мы же обычно не обращаемся к блочным устройствам напрямую, а используем файловые системы.
                                    размер блока по умолчанию в ext4 и xfs как раз и есть 4кб. ЕМНИП в ntfs размер кластера по умолчанию тоже 4кб.

                                      0
                                      А файловые системы обращаются к диску, используя размер именно логического сектора накопителя. Нет никакой гарантии, что диск всегда умеет правильно объединять эти сектора.

                                      В особенности при параллельной нагрузке.
                                        0
                                        Эм, эта проблема была решена очень давно, еще в 2010-2012 годах. Некоторые производители винчестеров даже предоставляли align tool.
                                        Сейчас при разбитии диска на разделы, современный софт сам правильно начинает новый раздел.
                                          0
                                          Это совершенно другая проблема. Когда логический ФС сектор был не на границе физического сектора устройства.
                                            –1
                                            Это именно оно. WD align и другие подобные утилиты как раз и выравнивали начало раздела (то есть кластера ФС) с началом сектора.
                                          0

                                          Чтение и запись группы секторов были включены еще в ATA-2, раздел 10.6.

                                    0
                                    Вы уверены, что первая попытка это было упреждающее чтение, а не просто кэш от предыдущей операции с этим файлом?
                                    0
                                    Потому что erase block сильно больше write block. И при чтении будет читаться много лишнего, если write block'и раскиданы по разным erase block.
                                      +1
                                      К чтению erase block никакого отношения не имеет.
                                    0

                                    Вы пытаетесь бенчмаркать производительность writeback-кеша на SSD. Выключите (hdparm -W0) и посмотрите после этого.


                                    Все SSD поделятся на три класса:


                                    • начнут невообразимо тормозить (400 IOPS — уже круто).
                                    • начнут тормозить за пределами добра и зла (30 IOPS)
                                    • не поменяют производительность.

                                    Наиболее интересные — третьи. Они срали на команду "выключить writeback" и продолжают его делать. Некоторые самсунги этим грешат. Есть кондёр на устройстве — "мы лучше знаем нужен вам writeback или нет".

                                      +1
                                      Вы пытаетесь бенчмаркать производительность writeback-кеша на SSD

                                      тестами скорости чтения?


                                      Есть кондёр на устройстве — "мы лучше знаем нужен вам writeback или нет".

                                      так оно и есть.
                                      без конденсатора "честные" ssd начинают тупить под типичной нагрузкой БД (синхронная запись в лог), для того и нужны DC накопители, чтобы при разумных гарантиях сохранности данных иметь хорошую производительность.

                                        0

                                        Всё сложнее.


                                        База данных использует flush (что такое flush зависит от шины, но внутри ядра это BIO_FLUSH) для обеспечения write barriers. Интерпретация flush'а зависит от устройства. Например, рейды с батарейкой его игнорируют. Так же поступают DC-grade SSD, у которых есть кондёр на борту для завершения записи в случае фейла.


                                        А есть управление кешом. Например, у серьёзных аппаратных рейдов выключение кеша его выключает. Даже если рейд может быстро и с writeback'ом, если сказал "выключить", значит "выключить". Аналогично должны вести себя и устройства. Если им сказали "выключить кеш", значит кеш надо выключить.


                                        Но бывают товарищи, которые умнее всех и верят, что у них-то фирмваря без багов, и это игнорируют.
                                        Есть большая разница между игнорированием flush'а и игнорированием команды "выключить кеширование на запись".

                                          0

                                          не представляю ситуации, в которой действительно может потребоваться отключить wb кэш на dc дисках (да и не на dc тоже, надо просто "к месту" вызывать sync aka flush).
                                          это же будет жутко медленно и с огромным write amplification внутри.


                                          хотя, вроде бы, есть некоторые кастомерские ssd, которые работают вовсе без wb. ну и, конечно, есть optane, которому это не нужно.

                                            0

                                            Например, если диск под рейдом с writeback'ом, то write amplification будет меньше. Хотя всё равно будет, да.


                                            Вкл/выкл я привожу как метод оценить реальную производительность и честность вендора.

                                              0
                                              > не представляю ситуации, в которой действительно может потребоваться отключить wb кэш на dc дисках

                                              Любое применение, где критично считать, что если диск сказал «записано», то оно там реально записано. Например, базы данных.

                                              > это же будет жутко медленно и с огромным write amplification внутри.

                                              Медленно — решается тем, что такое применение ставит много асинхронных параллельных операций одновременно. Не зря в пост-SATA интерфейсах (как тот же NVMe) дают, например, 65536 одновременных операций (пространство тегов — 16 бит).
                                              Усиление записи — да, если к моменту, когда контроллер дойдёт до выполнения операции, не скажут записать соседние блоки — будет большое усиление, а как иначе-то?

                                              > хотя, вроде бы, есть некоторые кастомерские ssd, которые работают вовсе без wb.

                                              Как раз для дома тайный writeback почти безвреден, а для серверной стороны это критично — если диск отрапортует, что записал, а на самом деле нет — получить невосстановимую базу будет банально.
                                                0
                                                а для серверной стороны это критично — если диск отрапортует, что записал, а на самом деле нет — получить невосстановимую базу будет банально.

                                                ну для всяких log-based структур это не так критично, скорее всего будет откат на прошлое консистентное состояние (я понимаю, что это тоже зачастую неприемлемо)


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

                                                  0
                                                  > ну для всяких log-based структур это не так критично, скорее всего будет откат на прошлое консистентное состояние (я понимаю, что это тоже зачастую неприемлемо)

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

                                                  > как минимум неожиданное отключение питания обрабатывается

                                                  Ну если на запасе энергии оно сумеет таки записать весь свой кэш — тогда ok. Но ещё во времена наличия только HDD были скандалы про диски, которые для улучшения бенчмарков не давали выключать WB кэш. Там запаса не было.
                                                    0
                                                    Но ещё во времена наличия только HDD были скандалы про диски, которые для улучшения бенчмарков не давали выключать WB кэш

                                                    ну это совсем другая история.
                                                    все встречавшиеся мне enterprise ssd имеют защиту от пропадания питания, подобной защиты на hdd я не помню, слишком много энергии жрёт hdd (потому так популярны были raid-контроллеры с bbwc).


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

                                                      +1
                                                      не подвесит ли его некий нестандартный пакет на pci-e шине?

                                                      Такое возможно? Откуда такому пакету взяться?
                                                        +1
                                                        Откуда такому пакету взяться?

                                                        вот так рассуждают программисты, а потом очередная CVE появляется )))

                                                          0
                                                          То есть вы хотите сказать, что протокол PCIe содержит такие пакеты?
                                                            +1

                                                            В яслях для программистов учат наизусть «Не доверяй входным данным».


                                                            А в чуть более старшей группе садика для программистов изучают законы Мёрфи и следствия из них, например: "Даже если неприятность не может случиться, она случается" (Обобщение следствий, сделанное Шнэттеpли).

                                                              0
                                                              Но на вопрос не ответили.
                                                                0

                                                                Я пытаюсь вам объяснить, что вопрос задан неверно.
                                                                Нужно доказывать не то, что злокозненный пакет может появиться, а то, что он не может появиться. И если не это доказано (а оно не может быть доказано хотя бы в силу разнообразия аппаратных систем) — считать, что на входе у нас может быть что угодно.

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

                                                                    гхм, одно другого совсем не исключает.


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

                                                                  0
                                                                  Осмелюсь предположить, что речь об этой табличке:
                                                                  image
                                                                  Очевидно, что здесь перечислены не все комбинации для 8 бит. Т.е. если у пакета из Reserved будет правильная CRC, это и будет нестандартным пакетом для устройства, не учитывающего возможное появления таких пакетов.
                                            0

                                            А какие консьюмерские SSD имеют надёжные кондёры? Скажем 970 Pro имеют?

                                              0

                                              AFAIK это отличительная особенность именно enterprise накопителей

                                                0

                                                Не пониманию я это позиционирование. Обычно в энтерпрайзе всякие прикольные штуки вроде двух блоков питания, ИБП и тд, без них никто в своём уме сервер не держит. А вот дома этого всего нет, хлоп и готово. При том, что быстрый кеш на запись вроде как все хотят.

                                                0

                                                Вы так спрашиваете у окружающих "а у них там надёжные кондёры?", что ответов может быть два:


                                                • Да, конечно! Нет, нифига!
                                                • Ну, с учётом выборки исследованных устройств результаты были неубедительными.

                                                Выбирайте, какой вам больше нравится?

                                              0
                                              В NAND flash можно писать (точнее стирать) только большими блоками. А операционная система видит SSD как набор 512-байтовых (или 4096-байтовых) секторов, каждый из которых может быть адресован независимо.

                                              Насколько большие блоки? Может выставить соответствующий размер сектора?
                                                0

                                                В современных моделях, ЕМНИП, используют даже по 32М.

                                                  0

                                                  взял первый попавшийся даташит на NAND, размер erase block 1Мб. Плюс надо понимать, что контроллеры многоканальные (работают с несколькими микросхемами сразу), то есть эффективный размер блока будет в несколько раз больше.

                                                  0

                                                  Скажу за себя: всегда периодически (раз в месяц, иногда реже) оптимизирую файловую таблицу и дефрагментирую ssd при помощи UltraDefrag (старой, бесплатной, версией).

                                                    0
                                                    Раз в пару месяцев я бэкаплю системный ssd полностью на второй такой же (не посекторно!) и сразу ставлю его в машину. Одновременно и бэкап, и его проверка, и дефрагментация.
                                                    Ps: а кто у нас сейчас в топе для бэкапа дисков/разделов? Использую актив диск но это немного не то. Акронису иногда крышу сносит от свободного места в конце диска. Гост медленный.
                                                      0
                                                      Раз в пару месяцев я бэкаплю системный ssd полностью на второй такой же (не посекторно!) и сразу ставлю его в машину. Одновременно и бэкап, и его проверка, и дефрагментация.

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

                                                        +1
                                                        Ps: а кто у нас сейчас в топе для бэкапа дисков/разделов?

                                                        Clonezilla — если на накопителе поддерживаемая файловая система (список велик), то копируются и восстанавливаюся только занятые блоки.

                                                        Лично я предпочитаю Parted Magic, который использует всё ту же Clonezilla. Благодаря тому, что дистрибутив идёт под GNU GPL, его совершенно легально можно скачать с торрентов, куда его выкладывают покупатели (на оф.сайте бесплатное скачивание недоступно).
                                                        0
                                                        Возможно, в данной ситуации, имеет смысл говорить не о дефрагментации SSD как физического устройства, а о дефрагментации файловой системы на нём, для снижения накладных расходов драйвера. Сейчас не редки ситуации, когда небольшие файлы на SSD распадаются на сотни тысяч кусочков по всей NTFS.
                                                          0

                                                          как раз наоборот: статья про фрагментацию внутри SSD, её не видно снаружи, но можно определить её наличие по косвенным признакам.

                                                            0
                                                            Дефрагментация ФС и дефрагментация FTL перемножаются, взаимно усиливаясь.
                                                          +1
                                                          Прогнал на серваке. Две Samsung MZVLB1T0HALR в MD Raid 0. Файловая система ext4. Оба накопителя изношены в ноль:
                                                          Available Spare:                    100%
                                                          Available Spare Threshold:          10%
                                                          Percentage Used:                    181%
                                                          Data Units Read:                    493,393,022 [252 TB]
                                                          Data Units Written:                 417,292,043 [213 TB]
                                                          Host Read Commands:                 61,788,393,431
                                                          Host Write Commands:                14,257,962,326
                                                          Controller Busy Time:               1,598,454,616
                                                          Power Cycles:                       11
                                                          Power On Hours:                     7,918
                                                          

                                                          Результат, без часового ожидания в конце.
                                                          preparing...
                                                          4096+0 records in
                                                          4096+0 records out
                                                          4294967296 bytes (4.3 GB, 4.0 GiB) copied, 1.22541 s, 3.5 GB/s
                                                          4096+0 records in
                                                          4096+0 records out
                                                          4294967296 bytes (4.3 GB, 4.0 GiB) copied, 2.4611 s, 1.7 GB/s
                                                          4096+0 records in
                                                          4096+0 records out
                                                          4294967296 bytes (4.3 GB, 4.0 GiB) copied, 1.29826 s, 3.3 GB/s
                                                          fio: write 50M...
                                                          sleep 10
                                                          4096+0 records in
                                                          4096+0 records out
                                                          4294967296 bytes (4.3 GB, 4.0 GiB) copied, 2.51806 s, 1.7 GB/s
                                                          sleep 20
                                                          4096+0 records in
                                                          4096+0 records out
                                                          4294967296 bytes (4.3 GB, 4.0 GiB) copied, 2.4617 s, 1.7 GB/s
                                                          sleep 30
                                                          4096+0 records in
                                                          4096+0 records out
                                                          4294967296 bytes (4.3 GB, 4.0 GiB) copied, 2.46044 s, 1.7 GB/s
                                                          fio: write 200M...
                                                          sleep 10
                                                          4096+0 records in
                                                          4096+0 records out
                                                          4294967296 bytes (4.3 GB, 4.0 GiB) copied, 2.51369 s, 1.7 GB/s
                                                          sleep 20
                                                          4096+0 records in
                                                          4096+0 records out
                                                          4294967296 bytes (4.3 GB, 4.0 GiB) copied, 2.50427 s, 1.7 GB/s
                                                          sleep 30
                                                          4096+0 records in
                                                          4096+0 records out
                                                          4294967296 bytes (4.3 GB, 4.0 GiB) copied, 2.57665 s, 1.7 GB/s
                                                          fio: write 800M...
                                                          sleep 10
                                                          4096+0 records in
                                                          4096+0 records out
                                                          4294967296 bytes (4.3 GB, 4.0 GiB) copied, 2.44405 s, 1.8 GB/s
                                                          sleep 20
                                                          4096+0 records in
                                                          4096+0 records out
                                                          4294967296 bytes (4.3 GB, 4.0 GiB) copied, 2.67699 s, 1.6 GB/s
                                                          sleep 30
                                                          4096+0 records in
                                                          4096+0 records out
                                                          4294967296 bytes (4.3 GB, 4.0 GiB) copied, 2.43979 s, 1.8 GB/s
                                                          fio: write 4000M...
                                                          sleep 10
                                                          4096+0 records in
                                                          4096+0 records out
                                                          4294967296 bytes (4.3 GB, 4.0 GiB) copied, 2.52351 s, 1.7 GB/s
                                                          sleep 20
                                                          4096+0 records in
                                                          4096+0 records out
                                                          4294967296 bytes (4.3 GB, 4.0 GiB) copied, 2.75889 s, 1.6 GB/s
                                                          sleep 30
                                                          4096+0 records in
                                                          4096+0 records out
                                                          4294967296 bytes (4.3 GB, 4.0 GiB) copied, 2.64889 s, 1.6 GB/s
                                                          
                                                            0
                                                            Время чтения (в секундах) файла размером 4Гб для разных дисков:

                                                            Стоит учесть что многие накопители (самсунги в частности) имеют SLC кэш (от 4 до 40+ Gib — обычно есть в спецификации). Я думаю подобное тестирование имеет смысл делать на объемах от 100 GiB.

                                                              0

                                                              ну 100Гб сободного места у меня не везде есть.
                                                              но в целом замечание годное, проверю как-нибудь

                                                              0
                                                              Ну во первых и самое главное — чтоб бы там на диске не было, изменить этого никак нельзя.
                                                              Просто нет никаких возможностей для управления размещением файлов на SSD из системы.
                                                              Всем заведует контроллер.
                                                              я не уверен на 100%, что все SSD правильно обрабатывают ситуацию «пишем нули в область, для которой до этого делали TRIM»
                                                              А зачем их писать? Какой в этом смысл? И главное — практически все ssd на лету сжимают данные, поэтому нули он скорее всего просто не запишет.

                                                              По поводу дефрагментации —
                                                              Оптимальное расположение файлов на HDD — непрерывно в одном месте диска.
                                                              Оптимальное расположение файлов на SSD — файл равномерно размазан по всем микросхемам.
                                                              По факту для наибольшего быстродействия файл должен быть очень сильно фрагментирован, если это слово вообще применимо к SSD.

                                                              Ну и если не устраивает такая свистопляска — смотрите в сторону Intel Optane на 3dxpoint, там нет всех этих премудростей nand памяти с очисткой ячеек и выравниванием износа — тупо идет запись туда, куда сказали, прям как на HDD.
                                                                0
                                                                А зачем их писать? Какой в этом смысл?

                                                                Запись нулей на SSD — это "TRIM для бедных", потому что не все контроллеры поддерживали TRIM, а некоторые нехорошие RAID контроллеры (на удивление, очень многие и даже high-end) не пропускают TRIM к SSD (и не используют его). И нет, далеко не все SSD используют компрессию. В любом случае проще обнаруживать запись нулей и отмечать блок как "неиспользованный", потому что в этом случае можно просто отдавать нули обратно при чтении неиспользованных блоков. Правда, не все контроллеры это распознают (распознавали).


                                                                Оптимальное расположение файлов на SSD — файл равномерно размазан по всем микросхемам.

                                                                Только если эта "размазанность" не во вред производительности. Так или иначе существует максимальный (и минимальный) размер блока (страницы) который можно читать/писать, размазанность частей этого блока "по микросхемам" может ускорять процессы (striping), но когда мы оперируем на уровне размеров блоков, фрагментация уже может стать проблемой (о чём и говорят тесты выше), в зависимости от физической реализации.

                                                                0
                                                                Samsung SSD 960 EVO 500GB
                                                                preparing...
                                                                4096+0 записей получено
                                                                4096+0 записей отправлено
                                                                4294967296 байт (4,3 GB, 4,0 GiB) скопирован, 5,17868 s, 829 MB/s
                                                                4096+0 записей получено
                                                                4096+0 записей отправлено
                                                                4294967296 байт (4,3 GB, 4,0 GiB) скопирован, 5,19728 s, 826 MB/s
                                                                4096+0 записей получено
                                                                4096+0 записей отправлено
                                                                4294967296 байт (4,3 GB, 4,0 GiB) скопирован, 5,24497 s, 819 MB/s
                                                                fio: write 50M...
                                                                ./1.sh: строка 11: fio: команда не найдена
                                                                sleep 10
                                                                4096+0 записей получено
                                                                4096+0 записей отправлено
                                                                4294967296 байт (4,3 GB, 4,0 GiB) скопирован, 5,29743 s, 811 MB/s
                                                                sleep 20
                                                                4096+0 записей получено
                                                                4096+0 записей отправлено
                                                                4294967296 байт (4,3 GB, 4,0 GiB) скопирован, 5,13125 s, 837 MB/s
                                                                sleep 30
                                                                4096+0 записей получено
                                                                4096+0 записей отправлено
                                                                4294967296 байт (4,3 GB, 4,0 GiB) скопирован, 5,32871 s, 806 MB/s
                                                                fio: write 200M...
                                                                ./1.sh: строка 11: fio: команда не найдена
                                                                sleep 10
                                                                4096+0 записей получено
                                                                4096+0 записей отправлено
                                                                4294967296 байт (4,3 GB, 4,0 GiB) скопирован, 5,32313 s, 807 MB/s
                                                                sleep 20
                                                                4096+0 записей получено
                                                                4096+0 записей отправлено
                                                                4294967296 байт (4,3 GB, 4,0 GiB) скопирован, 5,40436 s, 795 MB/s
                                                                sleep 30
                                                                4096+0 записей получено
                                                                4096+0 записей отправлено
                                                                4294967296 байт (4,3 GB, 4,0 GiB) скопирован, 5,32842 s, 806 MB/s
                                                                fio: write 800M...
                                                                ./1.sh: строка 11: fio: команда не найдена
                                                                sleep 10
                                                                4096+0 записей получено
                                                                4096+0 записей отправлено
                                                                4294967296 байт (4,3 GB, 4,0 GiB) скопирован, 5,19135 s, 827 MB/s
                                                                sleep 20
                                                                4096+0 записей получено
                                                                4096+0 записей отправлено
                                                                4294967296 байт (4,3 GB, 4,0 GiB) скопирован, 5,28124 s, 813 MB/s
                                                                sleep 30
                                                                4096+0 записей получено
                                                                4096+0 записей отправлено
                                                                4294967296 байт (4,3 GB, 4,0 GiB) скопирован, 5,39725 s, 796 MB/s
                                                                fio: write 4000M...
                                                                ./1.sh: строка 11: fio: команда не найдена
                                                                sleep 10
                                                                4096+0 записей получено
                                                                4096+0 записей отправлено
                                                                4294967296 байт (4,3 GB, 4,0 GiB) скопирован, 5,19901 s, 826 MB/s
                                                                sleep 20
                                                                4096+0 записей получено
                                                                4096+0 записей отправлено
                                                                4294967296 байт (4,3 GB, 4,0 GiB) скопирован, 5,32232 s, 807 MB/s
                                                                sleep 30
                                                                4096+0 записей получено
                                                                4096+0 записей отправлено
                                                                4294967296 байт (4,3 GB, 4,0 GiB) скопирован, 5,28964 s, 812 MB/s
                                                                sleep 3600

                                                                  0

                                                                  800Мб/с — ну очень мало. и у вас fio не стоит, без него нет смысла запускать скрипт.

                                                                    0
                                                                    Поставил fio.
                                                                    p.s — удивила странная работа перенаправления в файл, никогда такого не видел. Результаты остались в терминале, а в файл записались только паузы и fio.

                                                                    ./1.sh > result.txt
                                                                    ./1.sh > result.txt
                                                                    4096+0 записей получено
                                                                    4096+0 записей отправлено
                                                                    4294967296 байт (4,3 GB, 4,0 GiB) скопирован, 5,32284 s, 807 MB/s
                                                                    4096+0 записей получено
                                                                    4096+0 записей отправлено
                                                                    4294967296 байт (4,3 GB, 4,0 GiB) скопирован, 5,26583 s, 816 MB/s
                                                                    4096+0 записей получено
                                                                    4096+0 записей отправлено
                                                                    4294967296 байт (4,3 GB, 4,0 GiB) скопирован, 5,34693 s, 803 MB/s
                                                                    4096+0 записей получено
                                                                    4096+0 записей отправлено
                                                                    4294967296 байт (4,3 GB, 4,0 GiB) скопирован, 5,39388 s, 796 MB/s
                                                                    4096+0 записей получено
                                                                    4096+0 записей отправлено
                                                                    4294967296 байт (4,3 GB, 4,0 GiB) скопирован, 5,27483 s, 814 MB/s
                                                                    4096+0 записей получено
                                                                    4096+0 записей отправлено
                                                                    4294967296 байт (4,3 GB, 4,0 GiB) скопирован, 5,67319 s, 757 MB/s
                                                                    4096+0 записей получено
                                                                    4096+0 записей отправлено
                                                                    4294967296 байт (4,3 GB, 4,0 GiB) скопирован, 6,05745 s, 709 MB/s
                                                                    4096+0 записей получено
                                                                    4096+0 записей отправлено
                                                                    4294967296 байт (4,3 GB, 4,0 GiB) скопирован, 5,89485 s, 729 MB/s
                                                                    4096+0 записей получено
                                                                    4096+0 записей отправлено
                                                                    4294967296 байт (4,3 GB, 4,0 GiB) скопирован, 5,72409 s, 750 MB/s
                                                                    4096+0 записей получено
                                                                    4096+0 записей отправлено
                                                                    4294967296 байт (4,3 GB, 4,0 GiB) скопирован, 6,59454 s, 651 MB/s
                                                                    4096+0 записей получено
                                                                    4096+0 записей отправлено
                                                                    4294967296 байт (4,3 GB, 4,0 GiB) скопирован, 6,61636 s, 649 MB/s
                                                                    4096+0 записей получено
                                                                    4096+0 записей отправлено
                                                                    4294967296 байт (4,3 GB, 4,0 GiB) скопирован, 6,6462 s, 646 MB/s
                                                                    4096+0 записей получено
                                                                    4096+0 записей отправлено
                                                                    4294967296 байт (4,3 GB, 4,0 GiB) скопирован, 7,58384 s, 566 MB/s
                                                                    4096+0 записей получено
                                                                    4096+0 записей отправлено
                                                                    4294967296 байт (4,3 GB, 4,0 GiB) скопирован, 7,49087 s, 573 MB/s
                                                                    4096+0 записей получено
                                                                    4096+0 записей отправлено
                                                                    4294967296 байт (4,3 GB, 4,0 GiB) скопирован, 7,4826 s, 574 MB/s
                                                                    4096+0 записей получено
                                                                    4096+0 записей отправлено
                                                                    4294967296 байт (4,3 GB, 4,0 GiB) скопирован, 7,87835 s, 545 MB/s
                                                                    result.txt
                                                                    preparing…
                                                                    fio: write 50M…
                                                                    sleep 10
                                                                    sleep 20
                                                                    sleep 30
                                                                    fio: write 200M…
                                                                    sleep 10
                                                                    sleep 20
                                                                    sleep 30
                                                                    fio: write 800M…
                                                                    sleep 10
                                                                    sleep 20
                                                                    sleep 30
                                                                    fio: write 4000M…
                                                                    sleep 10
                                                                    sleep 20
                                                                    sleep 30
                                                                    sleep 3600

                                                                    Скорость, конечно…
                                                                      0
                                                                      Скорость, конечно…

                                                                      а просто dd if=/dev/nvme0n1 of=/dev/null bs=1M iflag=direct status=progress что показывает?

                                                                        0
                                                                        dd if=/dev/nvme0n1 of=/dev/null bs=1M iflag=direct status=progress
                                                                        216201691136 байт (216 GB, 201 GiB) скопирован, 100 s, 2,2 GB/s
                                                                        ^C
                                                                        206710+0 записей получено
                                                                        206709+0 записей отправлено
                                                                        216750096384 байт (217 GB, 202 GiB) скопирован, 100,275 s, 2,2 GB/s
                                                                          0

                                                                          тут нормально, а из fs очень медленно… чудеса.
                                                                          может быть у вас свободного места постоянно мало + активная запись?


                                                                          такая скорость держится до конца диска?

                                                                  0
                                                                  Чтобы эффект был максимальным нужно перед этим забить всё свободное место на диске файлами со случайными данными.

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

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

                                                                  На профессиональных SSD (Samsung PM1725, Oracle F640) очень большой объём скрытой области и очень мощный процессор, и поэтому там влияние будет меньше, даже при заполнении всего диска.
                                                                    0
                                                                    Дефрагментация SSD опасна, она в любом случае изнашивает вашу флэш-память, и в один «прекрасный» момент ваш SSD может тихо скончаться не издав ни звука. Так что лучше не рисковать повышая риск выхода какого-нибудь блока памяти из строя.
                                                                      0
                                                                      Я все понимаю, но это лишние телодвижения. Уже около пяти лет активно использую ssd и никаких «тормозов» вроде тех что бывают на hdd я не заметил.
                                                                        –1
                                                                        На своем опыте, делал дефрагментацию и плевался на все предосторожности, спустя год, смотрю фильм на ноуте и он просто погас, в итоге минус ссд
                                                                        делайте выводы…
                                                                          0
                                                                          Никогда не делал дефрагментацию и через полтора года компьютер не вышел утром из спящего режима, делайте выводы.
                                                                          А выводы такие: статистика так не собирается.
                                                                            0
                                                                            Какой полезный фидбек без указания названия ssd. Сейчас все включим свои пророческие возможности у знаем, что за дешманский ssd у тебя сдох.

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

                                                                          Самое читаемое