> Но речь была об оценке функционирования файловых систем, а не аппаратуры.Если кто еще не понял: на SSD и HDD соотношения разные! Как раз по линии железа. То что хорошо для HDD не обязательно хорошо для SSD, и наоборот. Поэтому то что ФС хорошо работает на HDD - ничего не говорит о том что она на SSD будет хорошо работать. Ну вот например, SSD бывают *ОЧЕНЬ* быстрыми. Настолько, что все может упереться в работу с метаданными по части ... проца. На HDD до этого момента добраться довольно сложно, разве что на многодисковой хранилке какой, в большинстве конфиг оно во что-нибудь другое быстрее упрется(скорость записи или seek-ов).
Рад файлух завели себе опции монтирования спецом под SSD, они хинтят файлухе что надо поменять логику работы. И таки это по сути 2 разных режима. Интересно, тот эксперт вообще юзал эти опции монтирования?
В общем, тесты на HDD ничего не говорят о работе ФС на SSD. Это 2 совершенно разных случая, где лохи и победители могут перетасоваться местами как делать нефиг.
> SSD _нельзя_ научно тестировать
Научно изучать можно абсолютно любой обьект. А если "ученый" вместо изучения свойств объекта сыкует и предлагает изучить что-нибудь другое... хаха, фееричный демарш :D :D :D.
> (что такое «тестить», анон? Что-то связанное и тестикулами?),
Бедный дедушка, походу у него проблемы.
> поскольку проприетарные контроллеры SSD и их фирмвари — терра инкогнита.
Поэтому давайте не будем ее изучать? Лол!
> Ты никогда даже в общем приближении не знаешь, как именно оно
> работает с ячейками и что конкретно делает.
Говоря за свои девайсы - я таки могу прикинуть чем они занимаются. А так у винчей тоже фирмварь будь здоров. И она тоже может делать море всего, начиная от фоновых тестов до ремапа бэдов.
> Ты даже не знаешь, сколько на самом деле ячеек внутри.
Ты тоже не знаешь истинную емкость блинов диска. И истинную геометрию не знаешь - фирмварь наружу абстрактные сектора, а какие там дорожки и головы она сама разбирается. К тому же на разных треках разное число секторов, из-за чего внешние треки и читаются быстрее - за оборот больше секторов пролетает.
Часть блинов занята "блинварью", сектора которой накопитель стандартными командами вообще не отдаст. И есть резервные сектора. И что в каждом секторе на самом деле не 512 или 4096 байтов все наверное тоже уже догадались - там еще область ECC есть. Которую наружу никогда не отгружают. И прочие сервометки и т.п. чтобы вообще сектора искать.
Немного даже наверх вывешено. Как насчет HPA и DCO? Я даже встречал пару особо ушлых BIOS, тихо откусывающих себе кусочек от винча этими чудесами для складирования какого-то блоба (бэкапа биоса, чтоли). Заметить это не так то просто, кстати.
В общем, примерно как в SSD - у тех даже попроще местами.
> Твой максимум — верить рекламе производителя.
Ну так и у HDD как-то так же. На внутренних треках он будет раза в три медленнее чем на внешних, так что результат бенча тоже сильно зависит что куда попало.
> Даже что делает trim — ты тоже не знаешь. ;) Да и не
> имеет оно отношения к файловым системам.
Можно подумать, ты знаешь как винч транслирует линейные сектора в истинную геометрию.
> программные интерфейсы к потрохам (S.M.A.R.T.). Ничего такого для SSD нет: что
> написано в рекламном буклете, тому верить на слово.
У SSD тоже есть SMART, внезапно. И тоже есть измеримые свойства. Ну например скорость записи на pre-erased накопитель штука относительно стабильная и предсказуемая. Поэтому и предлагается trim по всей площади сделать, чтобы поставить все ФС в равные стартовые условия.
Иначе будет не честно когда один на pre-erased поверхности заскипал стирание, а второй туповэйтил. Второй ФС в результате подсунули более плохие стартовые условия чем первой.
