Pull to refresh
61
0
Иван Ванюшкин @Vanav

User

Send message

Есть три решения этой проблемы:

  1. Использовать ssh -J / ProxyJump, в этом случае не нужен SSH agent

  2. Использовать ключ ssh-add -c, в этом случае для каждого использования SSH ключа будет запрашиваться подтверждение

  3. Использовать ограничения для ключей (OpenSSH v8.9). Кстати, это умеет KeePass KeeAgent:

Смешные же тексты. Теперь читать уже незаконно?
Не у всех панель задач снизу. У меня, вот, слева.
Я создаю раздел в 80 гигабайт и забиваю его данными. После этого я все их удаляю и заливаю ещё 30 гигов.

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

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

У меня сработал способ с разделом внутри RAID. Но я не смог это объяснить, поскольку при синхронизации массива все диски будут записаны, кроме одного, надеюсь, что в комментариях прояснится.
настоятельная рекомендация про необходимость 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 ГБ. То есть не весь объём резервной области. Также из принципа работы видно, что совсем без свободных блоков диск бы не смог писать после полного заполнения.
Я не говорю, что этого не бывает. Я бы очень хотел верить, что какие-то диски сами анализируют файловую систему и очищают мусор, и вообще не заморачиваться с другими методами. Но я говорю, что:
— это приведёт к проблемам в RAID из-за того, что данные в читаемых секторах будут меняться в непредсказуемое время,
— нет адекватных тестов, которые покажут работу такого интеллектуального сборщика мусора. Пока все тесты показывают только обратное. Даже нет списка поддерживаемых таблиц разделов и файловых систем. Поддерживается ли GPT и HFS+, например?
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.
т. е. при каждом чтении виртуального сектора возвращаются разные данные.

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

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

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

Цитаты в комментарии выше большей частью про работающий TRIM: в этом случае сборщику мусора нужно проделать меньше работы, если данные сжаты DuraWrite. Тест без TRIM довольно сомнительный, особенно без указаний, какие файловые системы поддерживаются контроллером.
Протестируйте, работает ли 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.
Да, в работе утверждается, что 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» — это указывает на то, что самостоятельно диск не распознаёт и не очищает страницы.
Я не нашёл там новых фактов. Напишите модели, где теоретически или практически подтверждено, что они понимают файловые системы, и какие именно файловые системы.
Да, TRIM поддерживается, но обычно не включается по соображениям безопасности. Если включить TRIM, то на диске будет видно, какие страницы удалялись, будут очерчены контуры файлов и структур файловой системы. Также не стоит включать TRIM, если внутри контейнера есть второй скрытый контейнер (для plausible deniability), поскольку либо будут видны его очертания, либо он будет поверждён (в зависимости от реализации).
Windows Dynamic Disks и Storage Spaces скорее всего поддерживают TRIM, как и другие программные RAID сегодня.

Также поддержка TRIM есть и в Intel RST RAID 0 — только этот тип массива в качестве исключения. Для включения нужно убедиться, что драйвер Intel RST версии 11 и выше, и прошивка OROM (Legacy boot) или SataDriver (UEFI boot) версии 11 и выше, или старая версия, но пропатченная.
Samsung экспериментировал с поддержкой NTFS, но отказались из-за потерь данных. SandForce DuraWrite единственное что делает — это сжимает и дедуплицирует данные, стараясь, чтобы было меньше занято физических страниц. На сколько я могу судить, ни один из массовых SSD не понимает файловые системы.
Да, задача выглядит неплохо. Показало, что TRIM для sda должен работать.
Вам нужно либо добавить «discard» в /etc/fstab и перезагрузиться, либо запускать «fstrim» вручную или по крону. Это не сделано по-умолчанию из-за потенциальных проблем с производительностью или потерями данных у разных контроллеров.
Да, затирание работало для OCZ, но, скорее всего, не работает для других контроллеров, поскольку они расценивают любую запись как полезные данные, которые надо беречь.
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.
# 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, но это недостоверный способ: разные диски ведут себя по-разному.
Это не перевод, это я так выразился.

Information

Rating
Does not participate
Location
Россия
Registered
Activity