Почему по мере заполнения SSD падает скорость записи в RAID, или зачем нужен TRIM

    Эта проблема наиболее актуальна для аппаратных RAID или firmware RAID (таких как Intel RST RAID 1/10/5/6) с непромышленными SSD.

    Особенность SSD


    SSD пишут и читают данные страницами, записать можно только на очищенные страницы, а очистить страницы можно только большими блоками. Например, у диска размер страницы 8 КБ, в блоке находится 128 страниц, таким образом, размер блока — 1024 КБ (здесь и далее, если не указано иного, КБ и МБ двоичные).

    Например, если изменить 40 КБ в одном файле, то на физическом уровне это будет выглядеть так:



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

    Чтобы скрыть физическую реализацию, диск поддерживает карту соответствия логических и физических номеров страниц (Flash Translation Layer).

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

    Чтобы решить это проблему, была добавлена команда ATA TRIM (wiki). Операционная система посылает её диску с указанием секторов, которые могут быть очищены. Аналоги этой команды — SCSI UNMAP и CF ERASE. К сожалению, в некоторых случаях нет возможности послать её диску:
    — если диск находится в RAID с аппаратным контроллером (LSI, Adaptec и т. п.),
    — если диски находится в firmware-RAID, в частности, Intel RST RAID 1/10/5/6,
    — если диск подключен по USB (ограничение протокола),
    — если диск зашифрован программно через TrueCrypt, dm-crypt, GELI и т.п. (может поддерживаться, но обычно не включается по соображениям безопасности).

    Если в результате тестирования выясняется, что диск не получает команду TRIM, то вскоре для записи может остаться совсем мало свободных страниц. Но они будут: каждый диск содержит некоторую зарезервированную область, которая служит как запас свободных страниц и запас блоков на замену полностью изношенным. Чтобы узнать размер этой области нужно посмотреть, какой физический объём памяти установлен на диске и сколько LBA указано в документации.

    Например, Samsung SSD 840 Pro 512 GB имеет 512 ГБ памяти, при этом доступно 1000215216 LBA секторов. Резерв составляет: 512 × 1024 × 1024 × 1024 — 1000215216 × 512 = 35 ГБ или 6,85 %. Доступная ёмкость диска при этом составляет (512 — 35) × 1024 × 1024 × 1024 = 512 × 10^9 = 512 ГБ, уже десятичных. Samsung SSD 850 Pro 128 ГБ имеет на борту 129 ГБ, пользователю доступно 128 ГБ десятичных, резерв — 7,6 %.

    Итак, если мы заполним весь диск, потом удалим все файлы, то без поддержки TRIM диск сможет писать только на какую-то часть от 6,85 % объёма диска. Часть, потому что этот резервный объём будет частично состоять из не полностью пустых блоков из-за фрагментации. Наличие этой области позволяет хоть как-то продолжать перезапись файлов на диске.

    Пример худшей ситуации: писать некуда, хотя объём занятых страниц не превышает доступный пользователю без резерва.



    В этом случае одновременно с записью работает сборщик мусора, который будет читать блок в оперативную память, стирать блок на диске (долгая операция, стирание занимает 3000 мкс в сравнении с 900 мкс записи в пустую страницу) и записывать блок из оперативной памяти. Задержка происходит также из-за роста Write Amplification — на одну логическую операцию записи приходится 5-10 физических операций записи.

    Поэтому чем больше у диска есть свободного места для манёвров, тем выше скорость записи. Сборщик мусора в фоне занимается не только очисткой и дефрагментацией блоков, но и равномерным распределением циклов записи/очистки (P/E) по блокам, чтобы они изнашивались одинаково.

    Есть популярный миф, что у современных дисков настолько хороший сборщик мусора, что им не нужен TRIM. Это совершенно не так, сборщик мусора и TRIM решают разные задачи.

    Промышленные диски часто имеют 50% и больше резервной области, поэтому для них отсутствие TRIM не критично. Остальные диски чаще всего вообще не имеют явно заявленной резервной области, или она недостаточна. Тесты показывают, что хороший эффект имеет объём over-provisioning 25-29 % от общего объёма физической памяти (включая резервную область). Поэтому если у диска недостаточный объём резервной области, то нужно сделать over-provisioning самостоятельно.

    Есть три способа:
    — разметить диск таким образом, чтобы оставить некоторую часть неразмеченной области, после создания RAID,
    — использовать команду ATA для создания Host protected area (howto), до создания RAID,
    — настроить RAID контроллер, чтобы он использовал только часть объёма диска.



    Прежде чем выделить свободную область, нужно дать знать диску, что эта область ничем не занята, одним из двух способов:
    — подключить диск к другому контроллеру и послать команду ATA TRIM (или при помощи O&O Defrag — есть cli интерфейс, Windows 8 встроенный оптимизатор дисков или Anvil's Storage Utilities),
    — сделать полную очистку таблицы FTL, послав команду ATA Secure Erase.

    Есть версия, что также можно заставить диск понять, что блоки не используются, если туда записать 0x00 или 0xFF (так называемый метод «Tony TRIM»). Возможно, для каких-то контроллеров это работает, но мои тесты не показали изменений.

    На практике


    У меня есть два диска Samsung SSD 540 Pro 512 GB в Intel RST RAID 1, на которых установлена Windows 8.1. После года работы я измерил производительность и был неприятно удивлён. После проверки TRIM я увидел, что он не работает.

    Проверка TRIM под Windows,
    — Проверка TRIM под Linux:
    # lsblk -D
    
    Колонки DISC-GRAN и DISC-MAX обе должны быть больше 0 для всех участвующих компонентов.

    Альтернативный вариант:
    # dd if=/dev/urandom of=tempfile bs=1M count=3
    # hdparm --fibmap tempfile
    # hdparm --read-sector [ADDRESS] /dev/sda
    # rm tempfile && sync && sleep 120
    # hdparm --read-sector [ADDRESS] /dev/sda
    
    После удаления файла на диске должны быть 0x00 или 0xFF, но это недостоверный способ: разные диски ведут себя по-разному.

    TRIM в реальном времени включается опцией «discard» при монтировании диска:
    # grep -i discard /etc/fstab
    # mount | grep -i discard
    

    TRIM для файловых систем на одиночных дисках и LVM поддерживается с ядра Linux 2.6.33. TRIM для mdraid поддерживается с ядра Linux 3.7. Но может быть портирован и на старые версии ядра, например, поддерживается в CentOS 6.

    По-умолчанию Ubuntu делает TRIM по расписанию раз в неделю при помощи fstrim, но только для одиночных дисков (не mdraid) следующих производителей: Intel, Samsung, OCZ, SanDisk и Patriot и если установлен «hdparm».

    — Проверка TRIM в FreeBSD:
    ZFS по-умолчанию поддерживает TRIM начиная с версии FreeBSD 9.2:
    # sysctl -a | grep -i 'zfs.*trim'
    

    GEOM RAID gmirror поддерживает TRIM с FreeBSD 9.1:
    gstat -d
    
    колонка «d/s» — BIO_DELETE/second.

    Intel RST RAID поддерживает TRIM только для типа RAID 1, как исключение: для включения нужно убедиться, что драйвер Intel RST версии 11 и выше, и прошивка OROM (Legacy boot) или SataDriver (UEFI boot) версии 11 и выше, или старая версия, но пропатченная. TRIM поддерживается в Intel RSTe RAID 0/1/10 начиная с версии 3.7.0.1093.

    Я решил создать неразмеченный раздел диска для over-provisioning.
    1. При помощи Acronis Backup я снял образ диска. Также сохранил таблицу разделов (важно иметь первый сектор, последний сектор, GPT тип раздела, GPT уникальный идентификатор, имя раздела).

    2. Перезагрузился в BIOS и сделал SSD Secure Erase. Если этого пункта нет в BIOS, то можно выполнить команду при помощи hdparam (или здесь и здесь, есть под Windows), HDDErase или HDAT2.

    3. Собрал RAID 1 на двух дисках.

    Здесь нужно сделать важное замечание: при инициализации массива RAID-контроллер считывает каждый сектор с одного диска и записывает его на второй. Теоретически это должно помешать всей нашей затее, и на одном диске не будет over-provisioning. Но тесты показали, что этот метод почему-то работает. У меня этому нет объяснений.

    4. Загрузился с LiveCD и при помощи GPT fdisk создал нужную таблицу разделов: последний раздел на 104 ГБ меньше, чем раньше. Разделы нужно выравнивать (partition align) по размеру страницы диска, а не по размеру блока.

    5. Восстановил из резервной копии каждый раздел.

    После этого я полностью заполнил диск и запустил тесты. Это должно показать худший случай. Кеш Windows включён, регулярная запись кеша выключена, Inter RST write-back выключен, все тесты используют область диска фиксированного размера в 40 ГБ. Тестировать диски непросто, поскольку показатели могут меняться во времени. Ниже сведены показатели установившегося состояния.

    Я сравню три состояния:
    — Один диск без RAID, полностью заполненный, стандартная скрытая резервная область 6,58 %.
    — Один диск без RAID, после запуска на нём TRIM свободного места.
    — Два диска в RAID 1, полностью заполненные, стандартная скрытая резервная область 6,58 %.
    — Два диска в RAID 1, полностью заполненные, over-provisioning 27,24 % (включая скрытую резервную область).


    Латентность и стандартное отклонение

    Таблица


    Анализ результатов:
    — чтение с RAID 1 оказывается быстрее, чем с одного диска, невзирая на то, что у нас всего лишь firmware RAID.
    — запись тем быстрее, чем больше нераспределенного пространства: на первом месте TRIM, на втором — наш самодельный over-provisioning.

    Установившееся состояние не всегда достигается быстро. Посмотрим тест последней конфигурации (over-provisioning 27,24 %) в динамике и увидим худший случай:





    Любопытный процесс идёт первые 400 секунд, после чего производительность возрастает и стабилизируется. Я думаю, параллельно с записью работает сборщик мусора, который дефрагментирует блоки и подготавливает их для записи. Такое поведение наблюдается не каждый раз, а время от времени. Видно, что последовательная запись проседает до 70 МБ/с, случайная запись — до 18000 IOPS. Эти показатели всё равно в два раза лучше, чем без over-provisioning (32 МБ/с и 7139 IOPS соответственно). Чтобы убедиться, что установившееся состояние на самом деле имеет такую высокую производительность, я также выполнил тест в течении 30 минут, при этом было записано на диск 490 ГБ со средним 69721 IOPS.

    Можно сравнить наши результаты с коллегами и выбрать оптимальный размер over-provisioning:

    Кратко


    — Если диск получает ATA TRIM от ОС, то беспокоиться не о чем, достаточно оставлять часть места на диске свободным.
    — Если используются дорогие промышленные диски, то проверьте объём встроенной резервной области, если он достаточен, то проблем с записью не будет.
    — В остальных случаях нужно оставить не размеченную область, чем больше её размер, тем меньше будет стандартное отклонение латентности записи.
    — Иногда сборщик мусора не успевает подготовить чистые блоки и скорость записи может просесть и быть непостоянной.
    — После over-provisioning установившаяся максимальная скорость записи повысилась с 7000 до 68000 IOPS, а средняя минимальная — с 6000 IOPS до 19000 IOPS.

    Метки:
    Поделиться публикацией
    Реклама помогает поддерживать и развивать наши сервисы

    Подробнее
    Реклама
    Комментарии 73
    • 0
      Когда покупал Crucial mx100, спросил на у производителя, требуется ли трим (OS X), на что он ответил, что встроенный сборщик мусора неплохо и сам справляется. Но на всякий случай установил Трим(уже на Yosemite) пропатчил kext, встроенные тесты от Cindori, показывали слабые результаты, в то время как Blackmagic показывал 480 и 500 с лишним, затем после включения трима, результаты Синдори резко оказались наверху, BlackmagicDisk также показывал неплохие результыты, кому тут верить? Стоит ли вообще доверять кому то, прошивать kextы…
      • +1
        Решение самостоятельно оставить неиспользуемую область диска — интересное. Спасибо :)
        • +3
          Так его форсят с самого появления SSD же. Просто многие сразу начинали говорить, что это бред сивой кобылы и совсем не помогает.
          • 0
            > Просто многие сразу начинали говорить, что это бред сивой кобылы и совсем не помогает.

            Ага, и потом стоны и плач по форумам о тормозных SSD.
        • 0
          А почему контроллер диска не запускает «сборщик мусора» не только в момент записи, а в «свободное» время?
          • 0
            Экономит электроэнергию. Серьёзно. Кроме этого, вероятно, экономит ресурс: зачем стирать блок, если он свободный сейчас никому не нужен? Вдруг не потребуется будет стирать этот полупустой, потому что какой-то другой уже по-честному TRIMнет ОС?
            • 0
              Логика работы сборщика мусора — загадка и нигде не описана. По одним только данным тестов очень сложно сделать reverse engineering. Я думаю, что кроме паттерна «случайная запись блоками по 4 КБ и QD 32» есть и другие, более популярные паттерны, и сборщик мусора больше ориентируется на них. Также, согласен с комментарием выше.
            • 0
              Есть популярный миф, что у современных дисков настолько хороший сборщик мусора, что им не нужен TRIM.

              plextor m5m и остальная 5 серия — легендарны как раз из-за отличного сборщика мусора без команды трим. Так что это не миф — просто надо знать места рыбные. www.overclockers.ru/lab/53541_6/Testiruem_Plextor_M5M_skazhi_kategoricheskoe_net_lishnim_provodam_v_sistemnom_bloke.html#13
              В 6 серии со сборщиком пока проблемы, возможно починят новыми прошивками.
              • 0
                Без команды TRIM диск никогда не узнает, что страница освободилась, и сборщик мусора будет бесконечно её копировать. У Plextor M5M на борту 256 ГБ двоичных, пользователю доступны 256 ГБ десятичных, соответственно размер резервной области примерно 6,87%. Это очень мало для высокой скорости записи: полностью заполненный диск даёт максимум 6000 IOPS, если сделать 25% over-provisioning, то получим 25000 IOPS.
                • +1
                  Без команды TRIM диск никогда не узнает, что страница освободилась, и сборщик мусора будет бесконечно её копировать


                  Производители уже давно интегрировали парсеры файловых систем в «сборщики мусора».
                  • 0
                    Samsung экспериментировал с поддержкой NTFS, но отказались из-за потерь данных. SandForce DuraWrite единственное что делает — это сжимает и дедуплицирует данные, стараясь, чтобы было меньше занято физических страниц. На сколько я могу судить, ни один из массовых SSD не понимает файловые системы.
                    • 0
                      По ссылкам не ходили?
                      • 0
                        Я не нашёл там новых фактов. Напишите модели, где теоретически или практически подтверждено, что они понимают файловые системы, и какие именно файловые системы.
                        • 0
                          Corsair P64 SSD, NTFS (подтверждается здесь, ссылки на страницы давать не буду, т. к. статья целиком посвящена обсуждаемой проблеме).
                        • 0
                          Еще рекомендую посмотреть вот это видео (1:40-2:40) и полистать вот эти слайды (обратите внимание на слайд №6). Контроллеры SSD имели поддержку обработки структур файловых систем еще в 2008 году! Когда Samsung объявил о поддержке NTFS? Когда задокументировали поддержку NTFS у накопителей Corsair? Годы спустя.
                          • 0
                            Да, в работе утверждается, что Corsair P64 самостоятельно очищает NTFS после Quick Format под Windows XP. В первом эксперименте после Quick Format диск начал очищаться после 300 секунд анализа, было очищено 100%. Во втором эксперименте после Quick Format диск подключили по USB (блокируя TRIM), было очищено 0,06%. В третьем эксперименте диску дали дополнительно постоять 20 минут, было очищено 18,74%. Авторы остались в недоумении.

                            Вообще, Quick Format посылает команду TRIM, но Windows XP не поддерживает TRIM. С другой стороны, Windows XP не блокирует команду TRIM, и её может посылать сам драйвер или специальная утилита. Поэтому нельзя исключать, что в процессе Quick Format диску был послан TRIM, и дальше сборщик мусора ждал idle чтобы приступить к очистке.

                            Corsair P64 использует контроллер Samsung, если предположить, что это из тех ранних серий, когда экспериментировали с распознаванием NTFS, то непонятно, почему в обновлённой прошивке добавляется поддержка именно "Windows 7 Trim Support on NTFS-formatted SSDs". Современные контроллеры Samsung, по моим тестам, самостоятельно не очищают блоки. Кстати, что бы сказал RAID контроллер на то, что во время очередной проверки дисков он бы увидел несовпадающие данные (RAID 1) или некорректную контрольную сумму (RAID 6), если сборщики мусора каждого диска будут работать каждый сам по себе?

                            На слайде 6 сказано: «Some SSDs have tried to work around lack of Trim by trying to interpret and understand the file system format such that they can free blocks when a file is marked deleted. Works for FAT since it’s a published spec. Does not work well for NTFS: NTFS structures are much more complex than FAT, NTFS structures are not published and will change in the future.» — что можно понять как не реализовано для NTFS. И вообще большие проблемы с этим подходом, ведь не NTFS единым…

                            Также есть слайды про DuraWrite, где про пользовательский раздел для over-provisioning сказано: «During initial setup and formatting, allocate a smaller partition (don’t use the full space). SSD must be either “Fresh Out of Box” (FOB) or secure erased. Leave the extra space unallocated. The SSD controller automatically uses this as additional dynamic OP» — это указывает на то, что самостоятельно диск не распознаёт и не очищает страницы.
                            • 0
                              Кстати, что бы сказал RAID контроллер на то, что во время очередной проверки дисков он бы увидел несовпадающие данные (RAID 1) или некорректную контрольную сумму (RAID 6), если сборщики мусора каждого диска будут работать каждый сам по себе?


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

                              что можно понять как не реализовано для NTFS. И вообще большие проблемы с этим подходом, ведь не NTFS единым…


                              Да, есть еще и FAT. А про FAT на слайде явно сказано, что реализовано. Кроме того, есть еще видео от известного специалиста (ссылку давал ранее), хотя там и не указан тип файловой системы, но все дело происходило до появления Trim или Intel SSD Toolbox.

                              Также есть слайды про DuraWrite, где про пользовательский раздел для over-provisioning сказано


                              Авторы из Kingston в своей статье, ссылку на которую я давал ранее, проводят грань между DuraWrite, Trim и Garbage Collection. DuraWrite – сжатие данных, Garbage Collection – высвобождение удаленных данных без Trim.
                              • 0
                                Авторы из Kingston в своей статье, ссылку на которую я давал ранее, проводят грань между DuraWrite, Trim и Garbage Collection. DuraWrite – сжатие данных, Garbage Collection – высвобождение удаленных данных без Trim.


                                Вот:
                                Kingston SSDs incorporating LSI® SandForce® controllers incorporate technology called DuraWrite® that performs data reduction; for the purposes of this paper, let’s equate DuraWrite to Data Compression. Most Client workloads (operating system files, Microsoft Outlook, documents, web browsing, security software, etc.) can be compressed, resulting in data reduction that shrinks the data’s footprint on the SSD. The smaller footprint translates to lower GC activity as fewer storage blocks need to be garbage collected when files are deleted and automatically increases the free space (over provisioning); both result in more stable and better GC performance.


                                +

                                This total process of recycling previously deleted garbage data into reusable free space is called Garbage Collection.


                                +

                                For the purpose of this document, we will call data deleted by the OS but still residing on the storage
                                device “garbage data”


                                +

                                Garbage Collection is often confused with the support of the TRIM command by Operating System (OS)

                                While TRIM commands help SSDs with Garbage Collection, we will show in our testing below that GC is much more than having TRIM enabled on a Client system. We will also show the worst-case scenario on a system where there is no TRIM support, demonstrating the KC300’s ability to efficiently conduct GC in the absence of TRIMs.
                                • 0
                                  т. е. при каждом чтении виртуального сектора возвращаются разные данные.

                                  Из-за этого не сойдётся контрольная сумма и RAID контроллер выкинет диск из массива, или будет восстанавливать. Чтобы этого избежать, каждый диск сообщает, что он поддерживает Deterministic Trim. В одном из его вариантов, запрос на чтение в любой сектор после TRIM должен вернуть 0x00, даже если сборщик мусора ещё этот сектор не трогал. Но это всё будет работать, только если все диски массива получат команду TRIM одновременно, без команды TRIM каждый будет очищать секторы в произвольное время.

                                  DualWrite – сжатие данных, Garbage Collection – высвобождение данных без Trim.

                                  Слайды показывают, что без TRIM помогает именно DuraWrite (слайд 13), сжимая и дедуплицируя. Каких-то подтверждений, что Garbage Collection самостоятельно очищает «занятые» секторы, я не нашёл.

                                  Цитаты в комментарии выше большей частью про работающий TRIM: в этом случае сборщику мусора нужно проделать меньше работы, если данные сжаты DuraWrite. Тест без TRIM довольно сомнительный, особенно без указаний, какие файловые системы поддерживаются контроллером.
                                  • 0
                                    Чтобы этого избежать, каждый диск сообщает, что он поддерживает Deterministic Trim


                                    К моему случаю Trim никак не относится. Контроллер получает команду на чтение логического участка данных, но т. к. в этот участок запись еще не производилась, то в таблице трансляции нет соответствия для указанного логического участка, в результате контроллер возвращает хосту содержимое команды чтения. Почему так происходит? Загадка. Но и такое бывает.

                                    Цитаты в комментарии выше большей частью про работающий TRIM: в этом случае сборщику мусора нужно проделать меньше работы, если данные сжаты DuraWrite. Тест без TRIM довольно сомнительный, особенно без указаний, какие файловые системы поддерживаются контроллером.


                                    «demonstrating the KC300’s ability to efficiently conduct GC in the absence of TRIMs»
                                    Я не думаю, что производитель здесь врет (как и работник Microsoft или другой авторитетный специалист). Все необходимые ссылки на свою точку зрения я привел, на этом можно закончить. С аргументом «не верю и все» я дел не имею.
                                    • –1
                                      Я не говорю, что этого не бывает. Я бы очень хотел верить, что какие-то диски сами анализируют файловую систему и очищают мусор, и вообще не заморачиваться с другими методами. Но я говорю, что:
                                      — это приведёт к проблемам в RAID из-за того, что данные в читаемых секторах будут меняться в непредсказуемое время,
                                      — нет адекватных тестов, которые покажут работу такого интеллектуального сборщика мусора. Пока все тесты показывают только обратное. Даже нет списка поддерживаемых таблиц разделов и файловых систем. Поддерживается ли GPT и HFS+, например?
                                      • 0
                                        Я бы очень хотел верить, что какие-то диски сами анализируют файловую систему и очищают мусор, и вообще не заморачиваться с другими методами


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

                                        Я бы очень хотел верить, что специалист из Microsoft, который указал на обработку структур FAT контроллером накопителя, ошибался.

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

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

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

                                        Слишком много «я бы очень хотел». Не буду с Вами больше спорить, подобное обсуждение уже поднималось в 2009 году на специализированном ресурсе и привело только к срачу.
                          • 0
                            SandForce DuraWrite


                            И еще. Не нужно путать DuraWrite и Garbage Collection. По ссылке, что я привел ранее, эти термины различаются.
                    • –1
                      Пока мы видим только один путь, которым физическая страница...

                      Вы действительно так говорите или это перевод?
                      • +2
                        Это не перевод, это я так выразился.
                      • 0
                        УЖас, кошмар, катастрофа!!!
                        Статья классная!
                        Но что значтит «TRIM не работет»?! Как жить-то теперь?! Я, кстати, серьёзно.
                        • +1
                          Кстати, пользуясь случаем хочу спросить, как на Ubuntu достоверно убедиться, что трим включен и работает?
                          Потому как запуская трим руками, я получаю вывод, что очищено примерно 13 ГБ
                          • +2
                            # lsblk -D
                            

                            Колонки DISC-GRAN и DISC-MAX обе должны быть больше 0 для всех участвующих компонентов.

                            Альтернативный вариант:
                            # dd if=/dev/urandom of=tempfile bs=1M count=3
                            # hdparm --fibmap tempfile
                            # hdparm --read-sector [ADDRESS] /dev/sda
                            # rm tempfile && sync && sleep 120
                            # hdparm --read-sector [ADDRESS] /dev/sda
                            

                            После удаления файла на диске должны быть 0x00 или 0xFF, но это недостоверный способ: разные диски ведут себя по-разному.
                            • 0
                              Извините за моё нубство, выходит что на SSD (sda) трим работает?

                              NAME   DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
                              sda           0      512B       2G         0
                              ├─sda1        0      512B       2G         0
                              ├─sda2        0      512B       2G         0
                              └─sda3        0      512B       2G         0
                              sdb           0        0B       0B         0
                              ├─sdb1        0        0B       0B         0
                              └─sdb2        0        0B       0B         0
                              sdc           0        0B       0B         0
                              └─sdc1        0        0B       0B         0
                              
                              


                              Возможно вы знаете, я правильно понимаю, что на убунту трим запускается раз в неделю по крону?
                              • 0
                                Не совсем правильно. На ext4 TRIM запускается при удалении блока в ФС (если монтировали с discard, см. man mount). Как только ФС решила, что эта область ей больше не нужна, она сообщает об этом диску командой TRIM. Именно драйвер ФС командует. А уже FTL, если весь блок пометился ненужный, стирает его, подготавливая к повторной записи.
                                Другие ФС могут работать по-другому, в том числе — по крону.

                                UPD: посмотрел, в мане также написано, что аналогично discard работает для FAT и XFS.
                                • 0
                                  А если монтировал разделы при установке убунты из под убунты. И она вот такое намонтировала

                                  # / was on /dev/sda2 during installation
                                  UUID=9095f1b8-bd34-4335-bc4c-332975e18192 /               ext4    errors=remount-ro 0       1
                                  # /home was on /dev/sda3 during installation
                                  UUID=a8778b8f-38bc-4e47-a1d2-3052c43ddc2c /home           ext4    defaults        0       2
                                  # swap was on /dev/sda1 during installation
                                  UUID=72836eaa-8221-452b-b4b4-377d30b2aa5d none            swap    sw              0       0
                                  


                                  Как видно тут параметра discard нет. Читал, что от этого параметра отказались, так как типа тормозила что-то где-то.
                                • 0
                                  TRIM в реальном времени включается опцией «discard» при монтировании диска:
                                  # grep -i discard /etc/fstab
                                  # mount | grep -i discard
                                  

                                  TRIM для файловых систем и одиночных дисков поддерживается с ядра Linux 2.6.33. TRIM для mdraid поддерживается с ядра Linux 3.7. Но может быть портирован и на старые версии ядра, например, поддерживается в CentOS 6.

                                  По-умолчанию Ubuntu делает TRIM раз в неделю при помощи fstrim только для следующих производителей: Intel, Samsung, OCZ, SanDisk и Patriot.
                                  • 0
                                    а если Plextor у меня?
                                    • +1
                                      Вам нужно либо добавить «discard» в /etc/fstab и перезагрузиться, либо запускать «fstrim» вручную или по крону. Это не сделано по-умолчанию из-за потенциальных проблем с производительностью или потерями данных у разных контроллеров.
                                      • 0
                                        В cron.weekly есть задача с таким кодом:
                                        #!/bin/sh
                                        # trim all mounted file systems which support it
                                        /sbin/fstrim --all || true
                                        


                                        Правильно понял, что этого достаточно? Раз в неделю запускаем и спим спокойно?

                                        А что тогда показало:
                                        Колонки DISC-GRAN и DISC-MAX обе должны быть больше 0 для всех участвующих компонентов.
                                        ?
                                        • 0
                                          Да, задача выглядит неплохо. Показало, что TRIM для sda должен работать.
                                • 0
                                  А если у меня две ОС? Каждая чистит только сама себя?
                              • 0
                                Проверить поддержку TRIM:

                                # hdparm -I /dev/sda | grep TRIM
                                • 0
                                  Извините, тыкнул не в ту кнопку, теперь плюс не горит :( Компенсировал в профиле.
                                • –1
                                  Я пытался экспериментировать как-то с этим года 3 назад. Где-то прочитал, что записывать надо не нули, а FF, чтобы диск «прочухал» неиспользуемые секторы (якобы в SSD чистая ячейка выглядит не как 00, а как FF, и TRIM как раз заполняет биты единичками). Вроде бы и правда это увеличило скорость. Я с тех пор слабо понимаю, зачем вообще производители придумали этот TRIM как отдельную команду интерфейса, когда можно было бы просто FF-ами затирать на программном уровне.
                                  • 0
                                    Да, затирание работало для OCZ, но, скорее всего, не работает для других контроллеров, поскольку они расценивают любую запись как полезные данные, которые надо беречь.
                                    • 0
                                      А как котнроллера узнает — это действительно свободный сектор или там и правда 0xFF? А если у меня файл с 0xFF, а контроллер его, использует для записи блоков другого файла? Оно, конечно, реализуемо всё, но появляется некий шаманизм.
                                      • 0
                                        Ну, вообще-то, пометка о том, что сектор пуст (= состоит из всех FF), занимает 1 бит в таблице секторов. Не так и сложно при попытке чтения этого сектора не лезть в память, а выдать сплошь FF. В общем, просто это.
                                        • 0
                                          Это да, но если сектор пуст, то в него можно писать — так? Чувствуете проблему?
                                          • 0
                                            Да не вижу я тут особой проблемы… Есть физические секторы, есть таблица маппинга логических адресов на физические секторы. Клиент имеет дело только с логической адресацией, а контроллер выполняет трансляцию логического адреса в физический с дополнительной логикой и хранением того, какие физические блоки заняты, а какие — свободны.
                                            1. Когда в какой-то логический сектор записывают сплошь FF, то у логического сектора взводится бит «это одни FF», а физический сектор помечается как свободный.
                                            2. При чтении логического сектора с взведенным битом просто читаются все FF, не обращаясь к физическому носителю.
                                            3. При записи в логический сектор, у которого взведен бит, из пула свободных физических секторов выделяется новый, на него мапится логический сектор, у него сбрасывается бит и производится туда запись.
                                      • +2
                                        Все просто: одна-единственная команда TRIM передается куда быстрее, чем целая страница единичных битов.
                                      • –1
                                        Долго думал, почему у меня не работает TRIM.
                                        Наконец вспомнил, что внутренняя паранойа уже с пол года как заставила меня за трукриптить системный раздел.
                                        Блин, теперь надо всё куда-то сОБРАЗить, Secure-Erase-нуть, разбить с запасом места, залить всё обратно. ух!
                                        • 0
                                          Скажите, Vanav
                                          — Что по поводу софтварных редов?
                                          Например динамические диски Windows или storage spaces?

                                          — Предполагается ли, что появятся аппаратные контроллеры, которые будут передавать дискам команду TRIM самостоятельно?
                                          Про свободное место они могут узнавать с помощью спец.драйвера

                                          — Интересно, что с этим у СХД?
                                          Всякие NetApp и т.д.
                                          Призываю track и bbk
                                          • 0
                                            Windows Dynamic Disks и Storage Spaces скорее всего поддерживают TRIM, как и другие программные RAID сегодня.

                                            Также поддержка TRIM есть и в Intel RST RAID 0 — только этот тип массива в качестве исключения. Для включения нужно убедиться, что драйвер Intel RST версии 11 и выше, и прошивка OROM (Legacy boot) или SataDriver (UEFI boot) версии 11 и выше, или старая версия, но пропатченная.
                                            • 0
                                              Пардон промахнулся с ответом, хотел ответить «чуть выше» Ghool
                                              Кстати в новых системах FlashRay, точно по той же причине отсутствует поддержка TRIM, несмотря на то, что в системе используются диски «потребительского» или как я выразился ранее «юзерского уровня».
                                            • 0
                                              NetApp не использует Trim, так как это фича для жестких дисков «юзерского» уровня. Выполнение очистки от мусора у нетапа выполняется на уровне прошивки диска, а не на уровне ОС.
                                              • 0
                                                В документации написано, что dm-crypt поддерживает TRIM.
                                                • +3
                                                  Да, TRIM поддерживается, но обычно не включается по соображениям безопасности. Если включить TRIM, то на диске будет видно, какие страницы удалялись, будут очерчены контуры файлов и структур файловой системы. Также не стоит включать TRIM, если внутри контейнера есть второй скрытый контейнер (для plausible deniability), поскольку либо будут видны его очертания, либо он будет поверждён (в зависимости от реализации).
                                                • 0
                                                  если диск подключен по USB (ограничение протокола),

                                                  SSD во внешнем usb-боксе плохая идея?
                                                  • 0
                                                    Нет, но лучше добавить свободного места.
                                                    • 0
                                                      Протестируйте, работает ли TRIM. Если нет, то попробуйте запустить его вручную (возможно, контроллер в боксе поддерживает SCSI ATA PASS-THROUGH). Если нет, то сделайте Secure Erase и раздел для over-provisioning.

                                                      USB 2.0 BOT (Bulk Only Transport) по стандарту не поддерживает команды ATA. Но у каждого контроллера есть свои расширения стандартов, поэтому есть возможность добыть, скажем, данные S.M.A.R.T.

                                                      USB 3.0 UAS (USB Attached SCSI) позволят посылать команды SCSI и поддерживает TRIM и NCQ.

                                                      ОС посылает SCSI UNMAP, которая должна транслироваться USB контроллером в боксе в ATA TRIM. И также контроллер должен сообщить ОС, что он поддерживает UNMAP. Обычно это не реализовано контроллером.

                                                      Контроллер также поддерживает SCSI команду ATA PASS THROUGH (которую также использует hdparm -I), которая может быть использована для передачи диску ATA TRIM. Но ОС часто не умеет так делать, а общается с диском как с SCSI устройством (посылает UNMAP). В этом случае можно посылать TRIM самостоятельно программно, например, при помощи hdparm --trim-sectors.
                                                    • 0
                                                      Кто-нибудь знает как обстоят дела с TRIM в ZFS?
                                                    • 0
                                                      >Если диск получает ATA TRIM от ОС, то беспокоиться не о чем, достаточно оставлять часть места на диске свободным.

                                                      Замечательно… То есть настоятельная рекомендация про необходимость 10-15% свободного места на SSD (да даже на обычных HDD), известная с «прошлого века» и эффект доказанный уже даже не десятки раз.

                                                      Спасибо Кэп :D

                                                      > каждый диск содержит некоторую зарезервированную область, которая служит как запас свободных страниц и запас блоков на замену полностью изношенным. Чтобы узнать размер этой области нужно посмотреть, какой физический объём памяти установлен на диске и сколько LBA указано в документации.
                                                      > Итак, если мы заполним весь диск, потом удалим все файлы, то без поддержки TRIM диск сможет писать только на какую-то часть от 6,85 % объёма диска

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

                                                      Или я всё перепутал?
                                                      • –1
                                                        настоятельная рекомендация про необходимость 10-15% свободного места на SSD

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

                                                        точный объём «микросхем флеш-памяти» не равен заявленному, а больше. Так же, резервная область диска вообще не может использоваться, кроме как для замены «сбойных участков»

                                                        Я смотрю микросхемы памяти, на диске в моём примере напаяно 8 микросхем K9PHGY8U7A-CCK0 по 512 Гбит каждая, это составляет 512,00 ГБ. Может ли в микросхеме K9PHGY8U7A-CCK0 быть больше 512 Гбит? Не могу сказать достоверно, я не встречал data sheet на неё. В спецификации указано: User-Addressable Sectors: 1,000,215,216. То есть на каждый указанный сектор можно записать данные. Один сектор LBA — это 512 байт, соответственно доступно пользователю 476,94 ГБ. Получается недоступный пользователю резерв в 35,06 ГБ.

                                                        Я не называю этот резерв over-provisioning, потому что скорее всего часть из него используется как подменный фонд для изношенных ячеек. В тесте на износ видно, что при 3500 переназначенных секторах использовано 40% резерва блоков. Если предположить, что под сектором здесь подразумевается один блок (1 МБ), то общий объём блоков, которые контроллер может переназначить — 8,54 ГБ. То есть не весь объём резервной области. Также из принципа работы видно, что совсем без свободных блоков диск бы не смог писать после полного заполнения.
                                                        • 0
                                                          >Об этих случаях и статья.
                                                          Ну да, это понятно, просто в очередной раз подтвердилась старинная рекомендация, хотя не совсем по теме статьи. Не упрёк же ;).

                                                          > Не могу сказать достоверно, я не встречал data sheet на неё.
                                                          Да, я сам в общем-то только по чужим словам это знаю, но инфа от человеков, которым я доверяю в этом плане. Сам не сильно понимаю все тонкости, но судя по понятому, реальный объем этих «флешек» немногим более, для нивелирования огрехов в «печати» или что-то в этом роде.

                                                          В общем-то у нас, с теми человеками, разговор начался с моего желания разобраться с, как вы удачно выразились, «подменный фонд для изношенных ячеек», а случилось это, когда нужно было вытащить инфу с нескольких умерших SSD. И когда высчитавалась разница в нём между дисками с объемом 120 и 128 гигабайт, по идее, «подменный фонд» на дисках на 120 гигабайт должен был быть (ну, если в лоб брать цифры) больше на те самые 8 гигабайт, а на деле получалось немного больше. Вот из ответа на вопрос я понял, что приплюсовалась та самая дополнительная «служебная» память из микрушек.

                                                          > Также из принципа работы видно, что совсем без свободных блоков диск бы не смог писать после полного заполнения.
                                                          Вот примерно эти же слова и говорили мне, про то что на диск пожно продолжать писать даже, казалось бы при полностью заполненном пространстве.

                                                          Вообще, не моя это тема, ой не моя… В общем, случившееся прошу считать мыслями вслух и не обращать внимание. Или опровергнуть, чтоб мой текст не вводил в заблуждение никого, кто однажды сможет прочитать эту статью и комментарии :D.
                                                      • 0
                                                        А как в случае с dmraid?

                                                        $ sudo dmraid -r
                                                        /dev/sdd: isw, "isw_cjcaidejcb", GROUP, ok, 500118190 sectors, data@ 0
                                                        /dev/sdc: isw, "isw_cjcaidejcb", GROUP, ok, 500118190 sectors, data@ 0
                                                        
                                                        $ sudo hdparm -I /dev/sdc | grep TRIM
                                                        	   *	Data Set Management TRIM supported (limit 8 blocks)
                                                        $ sudo hdparm -I /dev/sdd | grep TRIM
                                                        	   *	Data Set Management TRIM supported (limit 8 blocks)
                                                        
                                                        $ sudo fstrim -v  /
                                                        /: 9 MiB (9441280 bytes) trimmed
                                                        $ sudo fstrim -v  /
                                                        /: 96,4 MiB (101044224 bytes) trimmed
                                                        $ sudo fstrim -v  /
                                                        /: 0 B (0 bytes) trimmed
                                                        

                                                        В кроне fstrim есть. Мне беспокоиться больше не надо?
                                                        • 0
                                                          Я, всё-таки не понял:
                                                          Скажем, у меня пара дисков на 100 гигов в рейде-зеркале.
                                                          Трим не работает.
                                                          Я создаю раздел в 80 гигабайт и забиваю его данными.
                                                          После этого я все их удаляю и заливаю ещё 30 гигов.

                                                          Сначала винчестер пишет, используя запас — свободные 20 гигов.
                                                          Потом использую внутренние резервы (те самые 6.х%)

                                                          А дальше-то как? Если он не знает, что удалённые с рэйда данные удалены?

                                                          PS Второй вопрос: В случае рейда надо оставлять область не размеченной каким методом: не включать в рейд или можно уже внутри рэйда создавать партицию на часть диска?
                                                          • 0
                                                            1. Но ведь новые 30 гигов записываются на тот же раздел, где были старые 80. Таким образом, диск знает, что по крайней мере 30 гигов места он может использовать повторно. Да, без TRIM про остальные 50 он так и не узнает.

                                                            2. Зависит от рейда. Если используется простое зеркалирование (RAID1) — то сойдет любой из этих способов. В случае RAID0/RAID10 — если создать две партиции внутри (с «дыркой» посередине) — то потеряется все удобство RAID0/RAID10. В случае более сложных рейдов попросту проще неразмеченную область не включать в рейд, чем высчитывать, сколько надо откусить от рейда.
                                                            • 0
                                                              1) То есть в этом «худшем» случае — файловая система считает, что мы пишем данные на пустое место, и говорит винчестеру сектора, а винчестер считает, что мы пишем поверх старых данных на этом месте и запись занимает намного дольше времени (но всё равно данные пишутся) — так?

                                                              И именно по этим адресам секторов сборщик мусора узнаёт, что какие-то секторы уже можно подчистить и дефрагментировать — но только после того, как забъёт на винте данными весь размер партиции, и начнёт использовать over-provisioning?

                                                              Мне-то сперва показалось, что можно так забить винт без TRIM, что писать станет вообще некуда, хотя для ФС место есть *)

                                                              2) то есть главное — что бы бы файловая система никогда не говорила винту «пиши вот на эти секторы»?
                                                              • 0
                                                                1) Да, так, но сборщик мусора может начать работать и раньше, over-provisioning тут ни при чем. Точнее, в данном случае (запись 30 гигов при запасе в 20) — он начнет работать позже, когда даже дополнительная область тоже закончится (у него попросту не будет времени отработать раньше).

                                                                2) Да, именно это и главное.
                                                                • 0
                                                                  сборщик мусора начнёт работу раньше — это дефраг страниц, но не зачистка секторов с «удалёнными» данными — ведь про удалённые он не узнает из-за RAID?

                                                                  А если запись была потоковой, то фрагментации страниц по сути не будет, верно понимаю?

                                                                  Простите за банальные вопросы, хочу чётко понимать *)
                                                                  • 0
                                                                    Сборщик мусора узнает по 10 гигов удаленных данных, когда первые 10 гигов будут записаны. Если приостановить процесс записи на диск, то сборщик мусора их успешно почистит.
                                                          • 0
                                                            Я создаю раздел в 80 гигабайт и забиваю его данными. После этого я все их удаляю и заливаю ещё 30 гигов.

                                                            30 ГБ заливаются в те же самые секторы, где раньше лежали 80 ГБ. Таким образом контроллер понимает, что раз в тот же сектор пишут второй раз, то его можно стереть. В результате на диске будет 30 ГБ нужных данных, 50 ГБ ненужных данных, но про них контроллер не знает, что можно стереть, и будет сохранять, и 20 ГБ свободного места.

                                                            В случае рейда надо оставлять область не размеченной каким методом: не включать в рейд или можно уже внутри рэйда создавать партицию на часть диска?

                                                            У меня сработал способ с разделом внутри RAID. Но я не смог это объяснить, поскольку при синхронизации массива все диски будут записаны, кроме одного, надеюсь, что в комментариях прояснится.
                                                            • 0
                                                              Любопытно. Нечасто встретишь полезную программу, например как упомянутую trimcheck, написанную на языке D.

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