Исправление bonta, (текущая версия) :
Народ, помните (в той ветке где я писал про необычность поведения SSD на удаленной машине, ну что у него SMART имел плохие показатели а потом хоба и он как новорожденный)...
Сейчас случайно узнал что тот SSD, домашний и древний, который я хвалил тоже имеет странности.
Я изучал кое-что отностельно струтур Ф.С. и для этого гулял по дискам в режиме шестнадцатеричного редактора.
И обратил внимание на следующее
На новом SSD, который был выпущен несколько лет назад на рынок (KINGSTON SA400S37120G) TRIM работает. Это подверждается и тем что видно в шестнадцатеричном редакторе (куча нулей на диске) и специальными тестерами (https://github.com/CyberShadow/trimcheck)
Т.е. буквально удаляешь файл и через какое-то время, допустим секунд 20 SSD очищает блоки которые принадлежали файлу.
А вот на моём старом SSD (KINGSTON SNVP325S2128GB), который согласно спецификациям поддерживает TRIM:
https://smarthdd.com/database/KINGSTON-SNVP325S2128GB/AGYA0202/
в шестнадцатеричном редакторе картина была такой что как будто-бы это жесткий диск а не HDD, нулей вообще нету нигде, везде где свободные кластеры файловой системы - то на уровне секторов SSD лежал мусор от старых данных.
При этом Windows (да речь об оффтопике, но думаю в оффтопике поддержка TRIM как минимум не хуже чем в Linux, и скорее всего даже появилась раньше) на запрос fsutil behavior query DisableDeleteNotify - естественно говорит что TRIM включен, к тому же на другом SSD он работает, а в Windows нет такого (на сколько мне известно) чтобы на каком-то диске включить а на каком-то выключить - если включено или выключено то для всех сразу
Ну и всякие утилиты проверки, типа SSD-Z, Hard Disk Sentinel, Aida64 тоже говорят что TRIM включен (очевидно они просто запрашивают поддерживаемые диском опции - и согласно ним делают вывод)
Но вот если смотреть по факту через шестнадцатеричный редактор то видно что TRIM не работает, так же об этом и говорит утилита-тестер trimcheck.
Гуглежка ничего не говорит - похоже у людей не бывало проблем что TRIM заявлен но по факту не работает.
Кстати говоря даже не смотря на его неработоспособность - скорость записи (я запустил «sdelete -z» чтобы заполнить весь диск нулями) всеравно стабильная для SSD что тоже удивительно - где-то около 140-180Мб/C (не запомнил точно).
Итак вопросы: 1. Как думаете почему не работает TRIM (проблема в контроллере диска или может быть глюк Винды, но это 10ка, чтобы она глючила на SSD? Ладно бы если это WinXP была в последних своих реинкарнациях, когда SSD только появлялись...)
2. TRIM влияет только на производительность записи данных, или же как-то способствует снижению износа носителя? Я вот точно знаю что на скорость положительно влияет, а вот на ресурс не могу прийти к выводу - с одной сторону он заставляет диск больше записывать здесь и сейчас (без трима будет запись только когда от ф.с. запрос пришел), а с другой стороны вроде бы как затрименные секторы позволяют накопителю балансировать износ и маневрировать ради это с переназначением секторов.
3. Принудительное зануление всей свободной области нулями из софта, например sdelete -z - равнозначно ТРИМу по итоговому результату или нет? Ну т.е. TRIM это команда ATА интерфейса которая сообщает прошивке SSD диска что такие-то блоки свободные - их можно занулять и делать с ними что хочешь. А зануление из софта - оно же ничего не говорит для SSD есть ли данные в этих областях или нет, возможно эти нули и есть ценные данные для пользователя, или это не так - и если нули то программно-аппаратное обеспечение контроллера SSD как-то понимает что это свободное пространство, и соответственну принудительно из софта зануленные секторы на SSD для него тоже самое что если бы их софт не занулял но послал ATA команду TRIM?
Исправление bonta, :
Народ, помните (в той ветке где я писал про необычность поведения SSD на удаленной машине, ну что у него SMART имел плохие показатели а потом хоба и он как новорожденный)...
Сейчас случайно узнал что тот SSD, домашний и древний, который я хвалил тоже имеет странности.
Я изучал кое-что отностельно струтур Ф.С. и для этого гулял по дискам в режиме шестнадцатеричного редактора.
И обратил внимание на следующее
На новом SSD, который был выпущен несколько лет назад на рынок (KINGSTON SA400S37120G) TRIM работает. Это подверждается и тем что видно в шестнадцатеричном редакторе (куча нулей на диске) и специальными тестерами (https://github.com/CyberShadow/trimcheck)
Т.е. буквально удаляешь файл и через какое-то время, допустим секунд 20 SSD очищает блоки которые принадлежали файлу.
А вот на моём старом SSD (KINGSTON SNVP325S2128GB), который согласно спецификациям поддерживает TRIM:
https://smarthdd.com/database/KINGSTON-SNVP325S2128GB/AGYA0202/
в шестнадцатеричном редакторе картина была такой что как будто-бы это жесткий диск а не HDD, нулей вообще нету нигде, везде где свободные кластеры файловой системы - то на уровне секторов SSD лежал мусор от старых данных.
При этом Windows (да речь об оффтопике, но думаю в оффтопике поддержка TRIM как минимум не хуже чем в Linux, и скорее всего даже появилась раньше) на запрос fsutil behavior query DisableDeleteNotify - естественно говорит что TRIM включен, к тому же на другом SSD он работает, а в Windows нет такого (на сколько мне известно) чтобы на каком-то диске включить а на каком-то выключить - если включено или выключено то для всех сразу
Ну и всякие утилиты проверки, типа SSD-Z, Hard Disk Sentinel, Aida64 тоже говорят что TRIM включен (очевидно они просто запрашивают поддерживаемые диском опции - и согласно ним делают вывод)
Но вот если смотреть по факту через шестнадцатеричный редактор то видно что TRIM не работает, так же об этом и говорит утилита-тестер trimcheck.
Гуглежка ничего не говорит - похоже у людей не бывало проблем что TRIM заявлен но по факту не работает.
Кстати говоря даже не смотря на его неработоспособность - скорость записи (я запустил «sdelete -z» чтобы заполнить весь диск нулями) всеравно стабильная для SSD что тоже удивительно - где-то около 140-180Мб/C (не запомнил точно).
Итак вопросы: 1. Как думаете почему не работает TRIM (проблема в контроллере диска или может быть глюк Винды, но это 10ка, чтобы она глючила на SSD? Ладно бы если это WinXP была в последних своих реинкарнациях, когда SSD только появлялись...)
2. TRIM влияет только на производительность записи данных, или же как-то способствует снижению износа носителя? Я вот точно знаю что на скорость положительно влияет, а вот на ресурс не могу прийти к выводу - с одной сторону он заставляет диск больше записывать здесь и сейчас (без трима будет запись только когда от ф.с. запрос пришел), а с другой стороны вроде бы как затрименные секторы позволяют накопителю балансировать износ и маневрировать ради это с переназначением секторов.
3. Принудительное зануление всей свободной области нулями из софта, например sdelete -z - равнозначно ТРИМу по итоговому результату или нет? Ну т.е. TRIM это команда ATА интерфейса которая сообщает прошивке SSD диска что такие-то блоки свободные - их можно занулять и делать с ними что хочешь. А зануление из софта - оно же ничего не говорит для SSD есть ли данные в этих областях или нет, возможно эти нули и есть ценные данные для пользователя, или это не так - и если нули то программно-аппаратное обеспечение контроллера SSD как-то понимает что это свободное пространство, и соответственну принудительно из софта зануленные секторы на SSD для него тоже самое что если бы их софт не занулял но послала ATA команду TRIM?
Исходная версия bonta, :
Народ, помните (в той ветке где я писал про необычность поведения SSD на удаленной машине, ну что у него SMART имел плохие показатели а потом хоба и он как новорожденный)...
Сейчас случайно узнал что тот SSD, домашний и древний, который я хвалил тоже имеет странности.
Я изучал кое-что отностельно струтур Ф.С. и для этого гулял по дискам в режиме шестнадцатеричного редактора.
И обратил внимание на следующее
На новом SSD, который был выпущен несколько лет назад на рынок (KINGSTON SA400S37120G) TRIM работает. Это подверждается и тем что видно в шестнадцатеричном редакторе (куча нулей на диске) и специальными тестерами (https://github.com/CyberShadow/trimcheck)
Т.е. буквально удаляешь файл и через какое-то время, допустим секунд 20 SSD очищает блоки которые принадлежали файлу.
А вот на моём старом SSD (KINGSTON SNVP325S2128GB), который согласно спецификациям поддерживает TRIM:
https://smarthdd.com/database/KINGSTON-SNVP325S2128GB/AGYA0202/
в шестнадцатеричном редакторе картина была такой что как будто-бы это жесткий диск а не HDD, нулей вообще нету нигде, везде где свободные кластеры файловой системы - то на уровне секторов SSD лежал мусор от старых данных.
При этом Windows (да речь об оффтопике, но думаю в оффтопике поддержка TRIM как минимум не хуже чем в Linux, и скорее всего даже появилась раньше) на запрос fsutil behavior query DisableDeleteNotify - естественно говорит что TRIM включен, к тому же на другом SSD он работает, а в Windows нет такого (на сколько мне известно) чтобы на каком-то диске включить а на каком-то выключить - если включено или выключено то для всех сразу
Ну и всякие утилиты проверки, типа SSD-Z, Hard Disk Sentinel, Aida64 тоже говорят что TRIM включен (очевидно они просто запрашивают поддерживаемые диском опции - и согласно ним делают вывод)
Но вот если смотреть по факту через шестнадцатеричный редактор то видно что TRIM не работает, так же об этом и говорит утилита-тестер trimcheck.
Гуглежка ничего не говорит - похоже у людей не бывало проблем что TRIM заявлен но по факту не работает.
Кстати говоря даже не смотря на его неработоспособность - скорость записи (я запустил «sdelete -z» чтобы заполнить весь диск нулями) всеравно стабильная для SSD что тоже удивительно - где-то около 140-180Мб/C (не запомнил точно).
Итак вопросы: 1. Как думаете почему не работает TRIM (проблема в контроллере диска или может быть глюк Винды, но это 10ка, чтобы она глючила на SSD? Ладно бы если это WinXP была в последних своих реинкарнациях, когда SSD только появлялись...)
2. TRIM влияет только на производительность записи данных, или же как-то способствует снижению износа носителя? Я вот точно знаю что на скорость положительно влияет, а вот на ресурс не могу прийти к выводу - с одной сторону он заставляет диск больше записывать здесь и сейчас (без трима будет запись только когда от ф.с. запрос пришел), а с другой стороны вроде бы как затрименные секторы позволяют накопителю балансировать износ и маневрировать ради это с переназначением секторов.
3. Принудительное зануление всей свободной области нулями из софта, например sdelete -z - равнозначно ТРИМу по итоговому результату или нет? Ну т.е. TRIM это команда ATА интерфейса которая сообщает прошивке SSD диска что такие-то блоки свободные - их можно занулять и делать с ними что хочешь. А зануление из софта - оно же ничего не говорит для SSD есть ли данные в этих областях или нет, возможно эти нули и есть ценные данные для пользователя, или это не так - и если нули то программно-аппаратное обеспечение контроллера SSD как-то понимает что это свободное пространство?