Comments 74
Когда покупал Crucial mx100, спросил на у производителя, требуется ли трим (OS X), на что он ответил, что встроенный сборщик мусора неплохо и сам справляется. Но на всякий случай установил Трим(уже на Yosemite) пропатчил kext, встроенные тесты от Cindori, показывали слабые результаты, в то время как Blackmagic показывал 480 и 500 с лишним, затем после включения трима, результаты Синдори резко оказались наверху, BlackmagicDisk также показывал неплохие результыты, кому тут верить? Стоит ли вообще доверять кому то, прошивать kextы…
Решение самостоятельно оставить неиспользуемую область диска — интересное. Спасибо :)
А почему контроллер диска не запускает «сборщик мусора» не только в момент записи, а в «свободное» время?
Экономит электроэнергию. Серьёзно. Кроме этого, вероятно, экономит ресурс: зачем стирать блок, если он свободный сейчас никому не нужен? Вдруг не потребуется будет стирать этот полупустой, потому что какой-то другой уже по-честному TRIMнет ОС?
Логика работы сборщика мусора — загадка и нигде не описана. По одним только данным тестов очень сложно сделать reverse engineering. Я думаю, что кроме паттерна «случайная запись блоками по 4 КБ и QD 32» есть и другие, более популярные паттерны, и сборщик мусора больше ориентируется на них. Также, согласен с комментарием выше.
Есть популярный миф, что у современных дисков настолько хороший сборщик мусора, что им не нужен TRIM.
plextor m5m и остальная 5 серия — легендарны как раз из-за отличного сборщика мусора без команды трим. Так что это не миф — просто надо знать места рыбные. www.overclockers.ru/lab/53541_6/Testiruem_Plextor_M5M_skazhi_kategoricheskoe_net_lishnim_provodam_v_sistemnom_bloke.html#13
В 6 серии со сборщиком пока проблемы, возможно починят новыми прошивками.
Без команды TRIM диск никогда не узнает, что страница освободилась, и сборщик мусора будет бесконечно её копировать. У Plextor M5M на борту 256 ГБ двоичных, пользователю доступны 256 ГБ десятичных, соответственно размер резервной области примерно 6,87%. Это очень мало для высокой скорости записи: полностью заполненный диск даёт максимум 6000 IOPS, если сделать 25% over-provisioning, то получим 25000 IOPS.
Samsung экспериментировал с поддержкой NTFS, но отказались из-за потерь данных. SandForce DuraWrite единственное что делает — это сжимает и дедуплицирует данные, стараясь, чтобы было меньше занято физических страниц. На сколько я могу судить, ни один из массовых SSD не понимает файловые системы.
По ссылкам не ходили?
Я не нашёл там новых фактов. Напишите модели, где теоретически или практически подтверждено, что они понимают файловые системы, и какие именно файловые системы.
Corsair P64 SSD, NTFS (подтверждается здесь, ссылки на страницы давать не буду, т. к. статья целиком посвящена обсуждаемой проблеме).
Еще рекомендую посмотреть вот это видео (1:40-2:40) и полистать вот эти слайды (обратите внимание на слайд №6). Контроллеры SSD имели поддержку обработки структур файловых систем еще в 2008 году! Когда Samsung объявил о поддержке NTFS? Когда задокументировали поддержку NTFS у накопителей Corsair? Годы спустя.
Да, в работе утверждается, что 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» — это указывает на то, что самостоятельно диск не распознаёт и не очищает страницы.
Вообще, 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» — это указывает на то, что самостоятельно диск не распознаёт и не очищает страницы.
Кстати, что бы сказал 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.
Авторы из 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.
т. е. при каждом чтении виртуального сектора возвращаются разные данные.
Из-за этого не сойдётся контрольная сумма и RAID контроллер выкинет диск из массива, или будет восстанавливать. Чтобы этого избежать, каждый диск сообщает, что он поддерживает Deterministic Trim. В одном из его вариантов, запрос на чтение в любой сектор после TRIM должен вернуть 0x00, даже если сборщик мусора ещё этот сектор не трогал. Но это всё будет работать, только если все диски массива получат команду TRIM одновременно, без команды TRIM каждый будет очищать секторы в произвольное время.
DualWrite – сжатие данных, Garbage Collection – высвобождение данных без Trim.
Слайды показывают, что без TRIM помогает именно DuraWrite (слайд 13), сжимая и дедуплицируя. Каких-то подтверждений, что Garbage Collection самостоятельно очищает «занятые» секторы, я не нашёл.
Цитаты в комментарии выше большей частью про работающий TRIM: в этом случае сборщику мусора нужно проделать меньше работы, если данные сжаты DuraWrite. Тест без TRIM довольно сомнительный, особенно без указаний, какие файловые системы поддерживаются контроллером.
Чтобы этого избежать, каждый диск сообщает, что он поддерживает Deterministic Trim
К моему случаю Trim никак не относится. Контроллер получает команду на чтение логического участка данных, но т. к. в этот участок запись еще не производилась, то в таблице трансляции нет соответствия для указанного логического участка, в результате контроллер возвращает хосту содержимое команды чтения. Почему так происходит? Загадка. Но и такое бывает.
Цитаты в комментарии выше большей частью про работающий TRIM: в этом случае сборщику мусора нужно проделать меньше работы, если данные сжаты DuraWrite. Тест без TRIM довольно сомнительный, особенно без указаний, какие файловые системы поддерживаются контроллером.
«demonstrating the KC300’s ability to efficiently conduct GC in the absence of TRIMs»
Я не думаю, что производитель здесь врет (как и работник Microsoft или другой авторитетный специалист). Все необходимые ссылки на свою точку зрения я привел, на этом можно закончить. С аргументом «не верю и все» я дел не имею.
Я не говорю, что этого не бывает. Я бы очень хотел верить, что какие-то диски сами анализируют файловую систему и очищают мусор, и вообще не заморачиваться с другими методами. Но я говорю, что:
— это приведёт к проблемам в RAID из-за того, что данные в читаемых секторах будут меняться в непредсказуемое время,
— нет адекватных тестов, которые покажут работу такого интеллектуального сборщика мусора. Пока все тесты показывают только обратное. Даже нет списка поддерживаемых таблиц разделов и файловых систем. Поддерживается ли GPT и HFS+, например?
— это приведёт к проблемам в RAID из-за того, что данные в читаемых секторах будут меняться в непредсказуемое время,
— нет адекватных тестов, которые покажут работу такого интеллектуального сборщика мусора. Пока все тесты показывают только обратное. Даже нет списка поддерживаемых таблиц разделов и файловых систем. Поддерживается ли GPT и HFS+, например?
Я бы очень хотел верить, что какие-то диски сами анализируют файловую систему и очищают мусор, и вообще не заморачиваться с другими методами
Я бы очень хотел верить, что до появления Trim производители SSD не сталкивались с проблемой оптимизации износа и не пытались ее решить.
Я бы очень хотел верить, что специалист из Microsoft, который указал на обработку структур FAT контроллером накопителя, ошибался.
Я бы очень хотел верить, что известный специалист в области восстановления данных на самом деле самостоятельно перезаписал нулевыми байтами удаленные файлы для украшения своей лекции.
Я бы очень хотел верить, что в Kingston работают идиоты, которые видят несуществующие свойства в своей продукции и в продукции нескольких конкурентов.
Я бы очень хотел верить, что специалисты, проводившие тесты SSD от Corsair, допустили ошибку в самой основе методики тестирования.
Слишком много «я бы очень хотел». Не буду с Вами больше спорить, подобное обсуждение уже поднималось в 2009 году на специализированном ресурсе и привело только к срачу.
SandForce DuraWrite
И еще. Не нужно путать DuraWrite и Garbage Collection. По ссылке, что я привел ранее, эти термины различаются.
Пока мы видим только один путь, которым физическая страница...
Вы действительно так говорите или это перевод?
УЖас, кошмар, катастрофа!!!
Статья классная!
Но что значтит «TRIM не работет»?! Как жить-то теперь?! Я, кстати, серьёзно.
Статья классная!
Но что значтит «TRIM не работет»?! Как жить-то теперь?! Я, кстати, серьёзно.
Кстати, пользуясь случаем хочу спросить, как на Ubuntu достоверно убедиться, что трим включен и работает?
Потому как запуская трим руками, я получаю вывод, что очищено примерно 13 ГБ
Потому как запуская трим руками, я получаю вывод, что очищено примерно 13 ГБ
# 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, но это недостоверный способ: разные диски ведут себя по-разному.
Извините за моё нубство, выходит что на 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
Возможно вы знаете, я правильно понимаю, что на убунту трим запускается раз в неделю по крону?
Не совсем правильно. На ext4 TRIM запускается при удалении блока в ФС (если монтировали с discard, см. man mount). Как только ФС решила, что эта область ей больше не нужна, она сообщает об этом диску командой TRIM. Именно драйвер ФС командует. А уже FTL, если весь блок пометился ненужный, стирает его, подготавливая к повторной записи.
Другие ФС могут работать по-другому, в том числе — по крону.
UPD: посмотрел, в мане также написано, что аналогично discard работает для FAT и XFS.
Другие ФС могут работать по-другому, в том числе — по крону.
UPD: посмотрел, в мане также написано, что аналогично discard работает для FAT и XFS.
А если монтировал разделы при установке убунты из под убунты. И она вот такое намонтировала
Как видно тут параметра discard нет. Читал, что от этого параметра отказались, так как типа тормозила что-то где-то.
# / 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 нет. Читал, что от этого параметра отказались, так как типа тормозила что-то где-то.
TRIM в реальном времени включается опцией «discard» при монтировании диска:
TRIM для файловых систем и одиночных дисков поддерживается с ядра Linux 2.6.33. TRIM для mdraid поддерживается с ядра Linux 3.7. Но может быть портирован и на старые версии ядра, например, поддерживается в CentOS 6.
По-умолчанию Ubuntu делает TRIM раз в неделю при помощи fstrim только для следующих производителей: Intel, Samsung, OCZ, SanDisk и Patriot.
# 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.
а если Plextor у меня?
Вам нужно либо добавить «discard» в /etc/fstab и перезагрузиться, либо запускать «fstrim» вручную или по крону. Это не сделано по-умолчанию из-за потенциальных проблем с производительностью или потерями данных у разных контроллеров.
В cron.weekly есть задача с таким кодом:
Правильно понял, что этого достаточно? Раз в неделю запускаем и спим спокойно?
А что тогда показало:
#!/bin/sh
# trim all mounted file systems which support it
/sbin/fstrim --all || true
Правильно понял, что этого достаточно? Раз в неделю запускаем и спим спокойно?
А что тогда показало:
Колонки DISC-GRAN и DISC-MAX обе должны быть больше 0 для всех участвующих компонентов.?
А если у меня две ОС? Каждая чистит только сама себя?
Проверить поддержку TRIM:
# hdparm -I /dev/sda | grep TRIM
# hdparm -I /dev/sda | grep TRIM
Я пытался экспериментировать как-то с этим года 3 назад. Где-то прочитал, что записывать надо не нули, а FF, чтобы диск «прочухал» неиспользуемые секторы (якобы в SSD чистая ячейка выглядит не как 00, а как FF, и TRIM как раз заполняет биты единичками). Вроде бы и правда это увеличило скорость. Я с тех пор слабо понимаю, зачем вообще производители придумали этот TRIM как отдельную команду интерфейса, когда можно было бы просто FF-ами затирать на программном уровне.
Да, затирание работало для OCZ, но, скорее всего, не работает для других контроллеров, поскольку они расценивают любую запись как полезные данные, которые надо беречь.
А как котнроллера узнает — это действительно свободный сектор или там и правда 0xFF? А если у меня файл с 0xFF, а контроллер его, использует для записи блоков другого файла? Оно, конечно, реализуемо всё, но появляется некий шаманизм.
Ну, вообще-то, пометка о том, что сектор пуст (= состоит из всех FF), занимает 1 бит в таблице секторов. Не так и сложно при попытке чтения этого сектора не лезть в память, а выдать сплошь FF. В общем, просто это.
Это да, но если сектор пуст, то в него можно писать — так? Чувствуете проблему?
Да не вижу я тут особой проблемы… Есть физические секторы, есть таблица маппинга логических адресов на физические секторы. Клиент имеет дело только с логической адресацией, а контроллер выполняет трансляцию логического адреса в физический с дополнительной логикой и хранением того, какие физические блоки заняты, а какие — свободны.
1. Когда в какой-то логический сектор записывают сплошь FF, то у логического сектора взводится бит «это одни FF», а физический сектор помечается как свободный.
2. При чтении логического сектора с взведенным битом просто читаются все FF, не обращаясь к физическому носителю.
3. При записи в логический сектор, у которого взведен бит, из пула свободных физических секторов выделяется новый, на него мапится логический сектор, у него сбрасывается бит и производится туда запись.
1. Когда в какой-то логический сектор записывают сплошь FF, то у логического сектора взводится бит «это одни FF», а физический сектор помечается как свободный.
2. При чтении логического сектора с взведенным битом просто читаются все FF, не обращаясь к физическому носителю.
3. При записи в логический сектор, у которого взведен бит, из пула свободных физических секторов выделяется новый, на него мапится логический сектор, у него сбрасывается бит и производится туда запись.
Все просто: одна-единственная команда TRIM передается куда быстрее, чем целая страница единичных битов.
Долго думал, почему у меня не работает TRIM.
Наконец вспомнил, что внутренняя паранойа уже с пол года как заставила меня за трукриптить системный раздел.
Блин, теперь надо всё куда-то сОБРАЗить, Secure-Erase-нуть, разбить с запасом места, залить всё обратно. ух!
Наконец вспомнил, что внутренняя паранойа уже с пол года как заставила меня за трукриптить системный раздел.
Блин, теперь надо всё куда-то сОБРАЗить, Secure-Erase-нуть, разбить с запасом места, залить всё обратно. ух!
Скажите, Vanav
— Что по поводу софтварных редов?
Например динамические диски Windows или storage spaces?
— Предполагается ли, что появятся аппаратные контроллеры, которые будут передавать дискам команду TRIM самостоятельно?
Про свободное место они могут узнавать с помощью спец.драйвера
— Интересно, что с этим у СХД?
Всякие NetApp и т.д.
Призываю track и bbk
— Что по поводу софтварных редов?
Например динамические диски Windows или storage spaces?
— Предполагается ли, что появятся аппаратные контроллеры, которые будут передавать дискам команду TRIM самостоятельно?
Про свободное место они могут узнавать с помощью спец.драйвера
— Интересно, что с этим у СХД?
Всякие NetApp и т.д.
Призываю track и bbk
Windows Dynamic Disks и Storage Spaces скорее всего поддерживают TRIM, как и другие программные RAID сегодня.
Также поддержка TRIM есть и в Intel RST RAID 0 — только этот тип массива в качестве исключения. Для включения нужно убедиться, что драйвер Intel RST версии 11 и выше, и прошивка OROM (Legacy boot) или SataDriver (UEFI boot) версии 11 и выше, или старая версия, но пропатченная.
Также поддержка TRIM есть и в Intel RST RAID 0 — только этот тип массива в качестве исключения. Для включения нужно убедиться, что драйвер Intel RST версии 11 и выше, и прошивка OROM (Legacy boot) или SataDriver (UEFI boot) версии 11 и выше, или старая версия, но пропатченная.
Пардон промахнулся с ответом, хотел ответить «чуть выше» Ghool
Кстати в новых системах FlashRay, точно по той же причине отсутствует поддержка TRIM, несмотря на то, что в системе используются диски «потребительского» или как я выразился ранее «юзерского уровня».
Кстати в новых системах FlashRay, точно по той же причине отсутствует поддержка TRIM, несмотря на то, что в системе используются диски «потребительского» или как я выразился ранее «юзерского уровня».
NetApp не использует Trim, так как это фича для жестких дисков «юзерского» уровня. Выполнение очистки от мусора у нетапа выполняется на уровне прошивки диска, а не на уровне ОС.
В документации написано, что dm-crypt поддерживает TRIM.
Да, TRIM поддерживается, но обычно не включается по соображениям безопасности. Если включить TRIM, то на диске будет видно, какие страницы удалялись, будут очерчены контуры файлов и структур файловой системы. Также не стоит включать TRIM, если внутри контейнера есть второй скрытый контейнер (для plausible deniability), поскольку либо будут видны его очертания, либо он будет поверждён (в зависимости от реализации).
если диск подключен по USB (ограничение протокола),
SSD во внешнем usb-боксе плохая идея?
Нет, но лучше добавить свободного места.
Протестируйте, работает ли 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 (которую также использует
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.
Кто-нибудь знает как обстоят дела с TRIM в ZFS?
ZFS по-умолчанию поддерживает TRIM начиная с версии FreeBSD 9.2:
GEOM RAID gmirror поддерживает TRIM с FreeBSD 9.1:
# sysctl -a | grep -i 'zfs.*trim'
GEOM RAID gmirror поддерживает TRIM с FreeBSD 9.1:
gstat -d
ZFS on Linux ещё не поддерживает, но собирается портировать доработки из FreeBSD.
>Если диск получает ATA TRIM от ОС, то беспокоиться не о чем, достаточно оставлять часть места на диске свободным.
Замечательно… То есть настоятельная рекомендация про необходимость 10-15% свободного места на SSD (да даже на обычных HDD), известная с «прошлого века» и эффект доказанный уже даже не десятки раз.
Спасибо Кэп :D
> каждый диск содержит некоторую зарезервированную область, которая служит как запас свободных страниц и запас блоков на замену полностью изношенным. Чтобы узнать размер этой области нужно посмотреть, какой физический объём памяти установлен на диске и сколько LBA указано в документации.
> Итак, если мы заполним весь диск, потом удалим все файлы, то без поддержки TRIM диск сможет писать только на какую-то часть от 6,85 % объёма диска
Если мне не изменяет склероз, то точный объём «микросхем флеш-памяти» не равен заявленному, а больше. Так же, резервная область диска вообще не может использоваться, кроме как для замены «сбойных участков», в соответствии с таблицей трансляции, которая во власти микропрограммы (хотя может командами доступна, врать не буду, не помню).
Или я всё перепутал?
Замечательно… То есть настоятельная рекомендация про необходимость 10-15% свободного места на SSD (да даже на обычных HDD), известная с «прошлого века» и эффект доказанный уже даже не десятки раз.
Спасибо Кэп :D
> каждый диск содержит некоторую зарезервированную область, которая служит как запас свободных страниц и запас блоков на замену полностью изношенным. Чтобы узнать размер этой области нужно посмотреть, какой физический объём памяти установлен на диске и сколько LBA указано в документации.
> Итак, если мы заполним весь диск, потом удалим все файлы, то без поддержки TRIM диск сможет писать только на какую-то часть от 6,85 % объёма диска
Если мне не изменяет склероз, то точный объём «микросхем флеш-памяти» не равен заявленному, а больше. Так же, резервная область диска вообще не может использоваться, кроме как для замены «сбойных участков», в соответствии с таблицей трансляции, которая во власти микропрограммы (хотя может командами доступна, врать не буду, не помню).
Или я всё перепутал?
настоятельная рекомендация про необходимость 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 ГБ. То есть не весь объём резервной области. Также из принципа работы видно, что совсем без свободных блоков диск бы не смог писать после полного заполнения.
>Об этих случаях и статья.
Ну да, это понятно, просто в очередной раз подтвердилась старинная рекомендация, хотя не совсем по теме статьи. Не упрёк же ;).
> Не могу сказать достоверно, я не встречал data sheet на неё.
Да, я сам в общем-то только по чужим словам это знаю, но инфа от человеков, которым я доверяю в этом плане. Сам не сильно понимаю все тонкости, но судя по понятому, реальный объем этих «флешек» немногим более, для нивелирования огрехов в «печати» или что-то в этом роде.
В общем-то у нас, с теми человеками, разговор начался с моего желания разобраться с, как вы удачно выразились, «подменный фонд для изношенных ячеек», а случилось это, когда нужно было вытащить инфу с нескольких умерших SSD. И когда высчитавалась разница в нём между дисками с объемом 120 и 128 гигабайт, по идее, «подменный фонд» на дисках на 120 гигабайт должен был быть (ну, если в лоб брать цифры) больше на те самые 8 гигабайт, а на деле получалось немного больше. Вот из ответа на вопрос я понял, что приплюсовалась та самая дополнительная «служебная» память из микрушек.
> Также из принципа работы видно, что совсем без свободных блоков диск бы не смог писать после полного заполнения.
Вот примерно эти же слова и говорили мне, про то что на диск пожно продолжать писать даже, казалось бы при полностью заполненном пространстве.
Вообще, не моя это тема, ой не моя… В общем, случившееся прошу считать мыслями вслух и не обращать внимание. Или опровергнуть, чтоб мой текст не вводил в заблуждение никого, кто однажды сможет прочитать эту статью и комментарии :D.
Ну да, это понятно, просто в очередной раз подтвердилась старинная рекомендация, хотя не совсем по теме статьи. Не упрёк же ;).
> Не могу сказать достоверно, я не встречал data sheet на неё.
Да, я сам в общем-то только по чужим словам это знаю, но инфа от человеков, которым я доверяю в этом плане. Сам не сильно понимаю все тонкости, но судя по понятому, реальный объем этих «флешек» немногим более, для нивелирования огрехов в «печати» или что-то в этом роде.
В общем-то у нас, с теми человеками, разговор начался с моего желания разобраться с, как вы удачно выразились, «подменный фонд для изношенных ячеек», а случилось это, когда нужно было вытащить инфу с нескольких умерших SSD. И когда высчитавалась разница в нём между дисками с объемом 120 и 128 гигабайт, по идее, «подменный фонд» на дисках на 120 гигабайт должен был быть (ну, если в лоб брать цифры) больше на те самые 8 гигабайт, а на деле получалось немного больше. Вот из ответа на вопрос я понял, что приплюсовалась та самая дополнительная «служебная» память из микрушек.
> Также из принципа работы видно, что совсем без свободных блоков диск бы не смог писать после полного заполнения.
Вот примерно эти же слова и говорили мне, про то что на диск пожно продолжать писать даже, казалось бы при полностью заполненном пространстве.
Вообще, не моя это тема, ой не моя… В общем, случившееся прошу считать мыслями вслух и не обращать внимание. Или опровергнуть, чтоб мой текст не вводил в заблуждение никого, кто однажды сможет прочитать эту статью и комментарии :D.
А как в случае с dmraid?
В кроне fstrim есть. Мне беспокоиться больше не надо?
$ 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 есть. Мне беспокоиться больше не надо?
Я, всё-таки не понял:
Скажем, у меня пара дисков на 100 гигов в рейде-зеркале.
Трим не работает.
Я создаю раздел в 80 гигабайт и забиваю его данными.
После этого я все их удаляю и заливаю ещё 30 гигов.
Сначала винчестер пишет, используя запас — свободные 20 гигов.
Потом использую внутренние резервы (те самые 6.х%)
А дальше-то как? Если он не знает, что удалённые с рэйда данные удалены?
PS Второй вопрос: В случае рейда надо оставлять область не размеченной каким методом: не включать в рейд или можно уже внутри рэйда создавать партицию на часть диска?
Скажем, у меня пара дисков на 100 гигов в рейде-зеркале.
Трим не работает.
Я создаю раздел в 80 гигабайт и забиваю его данными.
После этого я все их удаляю и заливаю ещё 30 гигов.
Сначала винчестер пишет, используя запас — свободные 20 гигов.
Потом использую внутренние резервы (те самые 6.х%)
А дальше-то как? Если он не знает, что удалённые с рэйда данные удалены?
PS Второй вопрос: В случае рейда надо оставлять область не размеченной каким методом: не включать в рейд или можно уже внутри рэйда создавать партицию на часть диска?
1. Но ведь новые 30 гигов записываются на тот же раздел, где были старые 80. Таким образом, диск знает, что по крайней мере 30 гигов места он может использовать повторно. Да, без TRIM про остальные 50 он так и не узнает.
2. Зависит от рейда. Если используется простое зеркалирование (RAID1) — то сойдет любой из этих способов. В случае RAID0/RAID10 — если создать две партиции внутри (с «дыркой» посередине) — то потеряется все удобство RAID0/RAID10. В случае более сложных рейдов попросту проще неразмеченную область не включать в рейд, чем высчитывать, сколько надо откусить от рейда.
2. Зависит от рейда. Если используется простое зеркалирование (RAID1) — то сойдет любой из этих способов. В случае RAID0/RAID10 — если создать две партиции внутри (с «дыркой» посередине) — то потеряется все удобство RAID0/RAID10. В случае более сложных рейдов попросту проще неразмеченную область не включать в рейд, чем высчитывать, сколько надо откусить от рейда.
1) То есть в этом «худшем» случае — файловая система считает, что мы пишем данные на пустое место, и говорит винчестеру сектора, а винчестер считает, что мы пишем поверх старых данных на этом месте и запись занимает намного дольше времени (но всё равно данные пишутся) — так?
И именно по этим адресам секторов сборщик мусора узнаёт, что какие-то секторы уже можно подчистить и дефрагментировать — но только после того, как забъёт на винте данными весь размер партиции, и начнёт использовать over-provisioning?
Мне-то сперва показалось, что можно так забить винт без TRIM, что писать станет вообще некуда, хотя для ФС место есть *)
2) то есть главное — что бы бы файловая система никогда не говорила винту «пиши вот на эти секторы»?
И именно по этим адресам секторов сборщик мусора узнаёт, что какие-то секторы уже можно подчистить и дефрагментировать — но только после того, как забъёт на винте данными весь размер партиции, и начнёт использовать over-provisioning?
Мне-то сперва показалось, что можно так забить винт без TRIM, что писать станет вообще некуда, хотя для ФС место есть *)
2) то есть главное — что бы бы файловая система никогда не говорила винту «пиши вот на эти секторы»?
1) Да, так, но сборщик мусора может начать работать и раньше, over-provisioning тут ни при чем. Точнее, в данном случае (запись 30 гигов при запасе в 20) — он начнет работать позже, когда даже дополнительная область тоже закончится (у него попросту не будет времени отработать раньше).
2) Да, именно это и главное.
2) Да, именно это и главное.
Я создаю раздел в 80 гигабайт и забиваю его данными. После этого я все их удаляю и заливаю ещё 30 гигов.
30 ГБ заливаются в те же самые секторы, где раньше лежали 80 ГБ. Таким образом контроллер понимает, что раз в тот же сектор пишут второй раз, то его можно стереть. В результате на диске будет 30 ГБ нужных данных, 50 ГБ ненужных данных, но про них контроллер не знает, что можно стереть, и будет сохранять, и 20 ГБ свободного места.
В случае рейда надо оставлять область не размеченной каким методом: не включать в рейд или можно уже внутри рэйда создавать партицию на часть диска?
У меня сработал способ с разделом внутри RAID. Но я не смог это объяснить, поскольку при синхронизации массива все диски будут записаны, кроме одного, надеюсь, что в комментариях прояснится.
Любопытно. Нечасто встретишь полезную программу, например как упомянутую trimcheck, написанную на языке D.
Sign up to leave a comment.
Почему по мере заполнения SSD падает скорость записи в RAID, или зачем нужен TRIM