>> Говорят, что это позволяет контроллеру на ssd понять что вон те блоки
>> уже никому нафиг не нужны и можно заранее их erase'ануть. Это ...
> Да неужто? А зачем? Наверное, для того что бы в них можно было что-то записать?Да. Потому что в отличие от магнитного диска на флеше нельзя просто взять и перезаписать уже занятый данными произвольно выбранный сектор. У хардов все просто. Сказали перезаписать сектор? Ну он пошел, переместил головы в это место, нашел и перезаписал его. Правила игры флеша совсем иные. И если seek time у флеша близко к нулю и его можно вообще почти проигнорировать, то вот время erase обычно лежит в пределах скольких-то там миллисекунд и попасть на эту операцию в процессе записи данных - довольно нехорошо и ведет к сильной просадке скорости записи. Потому что сколько-то там миллисекунд вместо записи курили бамбук, ожидая пока блок сотрется и станет можно в него что-то записать. У арчеводов с их весьма дельной викой кстати на вике есть весьма доходчивые графики как все это выглядит не только в теории но и на практике - сравнение того что получается с trim и без оного ;)
> Мне еще рассказывали, в магнитных накопителях такой вот шпиндель заранее раскручивают.
Некорректная аналогия. В магнитном накопителе сектор можно записывать сразу, без какой-то выделенной процедуры предварительной подготовки оного, выполняемой как некая отдельная сущность в отдельный момент времени. И к тому же винчу не проблема перезаписать только вот эти 512 (или накрайняк 4096) байтов не трогая соседние. А вот ssd в силу своего устройства так не может чисто физически и эмулирует такое поведение крайне извращенскими и неоптимальными действиями. Провокации оного на эти действия следует максимально избегать, если волнует эффективность процесса. А поскольку истинной геометрии нам неизвестно - это избегание превращается в некую черную магию.
> Что диск жужжал, и человек мог понять, что он работает.
Какая чудная логика неандертальца ффтыкающего на микроволновку :)
[...]
> Не, товарищи производители должны были подождать, пока все разработчики напишут новый код
> под новую спецификацию интефейса SD00001BETA. А потом продавать. Через три-четыре года.
А что, MS как раз с удовольствием бы пошел барыжить новой системой с суперфичой :). Вообще, ATAPI же как-то внедрили, да? Ну потаскали некоторые системы некоторое время с собой кастомные драйвера cd-rom. А потом драйвера внедрили в все основные ОС и нужда в этом отпала. Не вижу никакой трагедии.
>> Ну просто мало меня интересуют кишки этой вашей FBSD
> Во первых, она такая же моя, как и товарища Петрова. Или ваша. Обчественное достояние.
Сами как-нибудь это ваше достояние юзайте. А для меня - поскольку я не собираюсь это использовать, то и детали его внутренней механики волнуют крайне слабо. Разве что как какое-то обобщенное знание, не более.
> Во вторых, ваше право чем-то не интересоваться. Чего писать об этом так уж?
Скорее, не совсем понятно на кой перец лезть с вашей bsd к линухоидам с их планировщиком. Хотя тут скорее больше в огород изена, этот вообще абстрактный теоретик. Флехи он судя по всему только на картинках в книжках видел :)
> В третьих, какая нахрен разница, код есть код.
Да просто не понятно какую самоценность он несет и что это по вашему мнению должно проиллюстрировать.
>> У упомянутых арчеводов есть довольно простой и забавный метод проверки работы trim
> "Ну просто мало меня интересуют кишки этоих ваших арчеводов" :)
Я это подозреваю, поэтому специально уточняю этот факт, предупреждая о том что эксперимент был опробован под вполне конкретную конфигурацию и работать в других так же не обязан а действия могут отличаться. Вам скорее всего придется напрячь мозг и как-то самому придумать эквивалентный по физическому смыслу набор действий для FBSD, если вдруг захочется повторить такой эксперимент.
>> через смотрение в каком секторе лежит файл, его стирание и смотрение
>> с тем что стало с этим сектором после sync.
> Угу. Через ATAPI интерфейс прям обращаясь к чипу EEPROM.
Во первых в флешовых носителях чипы не EEPROM а NAND-флеша. EEPROM где-то на совсем базовом уровне похож на "соседний" NOR-флеш, но в отличие от - может писаться хоть отдельными байтами в людском виде. Почему не юзают? Потому что плотность хранения данных никакая. Не надо никому носитель на несколько метров и по цене самолета.
Во вторых, набор команд у SSD вроде как ATA, а не ATAPI.
В третьих, нет, к сожалению напрямую обратиться в чип нельзя. Поэтому методика довольно хакерская и косвенная, продирающаяся через все эти костыли и слои абстракций к реальной физике.
> В каком секторе лежит файл. Сильная методика. Жажду ссылки.
Ага, сильная. Я тоже аж удивился. Правда извиняюсь, немного прогнал: ссылка на это у арчеводов, но сам эксперимент все-таки описан на другом сайте.
Арчеводовская вика по теме - https://wiki.archlinux.org/index.php/Solid_State_Drives и я бы сказал что это довольно дельный ресурс, независимо от используемой системы. В том плане что из него понятно в какую сторону и что можно крутить, а как это сделать в вашей системе - сами уже как-нибудь допирайте.
Статья на проверку поддержки TRIM в пингвине - http://techgage.com/article/enabling_and_testing_ssd_trim_su.../
(самое интересное, а именно проверка - на второй странице)
В меру моего понимания, эта проверка довольно сильно закладывается на механику работы файловых систем типа ext4 (как минимум, такой метод проверки имхо не прокатит для CoW файловых систем, а для остальных - в зависимости от того как они стирают файлы и требуют ли почистить при этом область занятую файлом через trim так или иначе) и допускает довольно характерную логику поведения контроллера в ssd, чего разумеется для произвольно взятого ssd никто не гарантирует. Тем не менее, упомянутая там механика и тест вполне работает на конфигурации отдаленно напоминающей авторскую. Ну то-есть, если все отработало как описано у авторов - TRIM определенно есть и работает "по факту", реально расчищая блоки когда об этом попросили.
