Износ SSD

Вообще всякие неактивные 100 лет программы должны уползать в своп большей частью, а место в памяти освобождать для файловых кешей и прочего. Особенно учитывая юз-кейс некоторых товарищей использовать 1000 вкладок, из которых 990 они открыли неделю назад и с тех пор не притрагивались, зачем им место в памяти занимать?

В макоси хорошо сделано - если не жать cmd-Q, то программа будет висеть в памяти/свопе и при необходимости её повторного использования будет доступна очень быстро.

3. noatime ставить НЕ НУЖНО, ибо может послужить УВЕЛИЧЕНИЕМ износа, а не уменьшением.

а теперь пересмотри свой вывод, учтя, что запись в ssd ведется блоками от 128кб http://en.wikipedia.org/wiki/Write_amplification

Что бы вы могли порекомендовать для увеличения срока службы SSD? Какие подводные камни могут быть в этих моих линуксах?

Не париться по этому вопросу. Когда твой SSD начнёт дохнуть, купишь новый, который сильно подешевеет к тому времени, если корейцы бузить не будут. И вообще скорее всего он не сдохнет в обозримом будущем.

У меня вопрос, тем кто в теме: если подключить SATA SSD к PATA интерфейсу через конвертер, будет ли оно работать? Будет ли работать TRIM (хотяб с помошью костылей)?

Что бы вы могли порекомендовать для увеличения срока службы SSD?

Взять диск большей емкости, например на 256.

Какие подводные камни могут быть в этих моих линуксах?

Что-то мне подсказывает, что износ будет сравним с виндовсным.
постоянное насилование /var и кэшами браузеров. Единственное, что обновления в этих твоих линуксах выходят по три раза в неделю и пачками по 50-100мб. Так что нехилый оферхед будет.
Скачать 60мб, развернуть на диске, еще раз переписать на место старых файлов, потом удалить.

Насколько я знаю, на каждую флешку есть вполне фиксорованный срок data retention столько-то лет. Да, это приведет к лишним стиранием, но если не сделать такого рефреша, можно потерять данные. Но это актуально только для длительного хранения (10+ лет), судя по шит-о-датам.

Угу, тут на прошлой неделе товарищ стонал по поводу нвидиевского контроллера, который сата2, но не АНСI

Когда твой SSD начнёт дохнуть

По слухам, они сдыхают очень внезапно, даже не успеваешь мяукнуть сделать бекапы... Или это уже в далеком прошлом и счас есть средства диагностики, чтобы мониторить железку и предотвратить потерю данных?

Я не соглашусь здесь. У меня рабочие ветки ядер, убутов и openwrt под разные железки занимают почти 500GiB на венике, и при сборке как раз насилуется носитель записью очень основательно.

HDD для особо длительного хранения не годятся, так как лежа в отключенном состоянии на полке могут накрыться тихо и мирно вместе с данными. Флеш в этом плане лучше, а так как скорость особая не нужна, можно тупо взять вариант, где куча нандов на одном интерфейсе разными чип селектами.

Ну это все буферизуется. Сначала в ядре линуха, потом в контроллере SSD. Там емнип кеши и по 64 и 128 метров сейчас бывают.

smart?

В винде винда саспендится в hiberfill.sys, и своппится в pagefile.sys. И это решение гавно, если честно, так как при этом возникают проблемы фрагментации этих файлов.

Юзаю 8 месяцев Vertex 3. Все работает безупречно, десктоп - ракета, не жалею ничуть. Кстати, виртуальные винчестеры тоже туда сложил, прирост отзывчивости тоже более чем ощутимый.

В винде винда саспендится в hiberfill.sys, и своппится в pagefile.sys. И это решение гавно, если честно, так как при этом возникают проблемы фрагментации этих файлов.

Почему фрагментация это проблема?

Потому что последовательное вычитывание быстрее. Емнип даже на SSD/NAND в некоторых случаях (зависит от того, как у последних устроен DMA). В эмбеддеде видел пару контроллеров, которые с нанда могут последовательно хоть сотню мегабайт одним DMA запросом прокачать, а на мелкие куски надо каждый раз программировать, ждать прерывания. Для HDD это более критично.

Потому что уменьшает скорость работы? :)
Да, SSD не касается, да и линукс тут тем более ни при чем.

см. комментарий выше. Зависит от устройства SSD, хотя если там не откровенный говноинженеринг - пренебрежимо мало.

HDD для особо длительного хранения не годятся, так как лежа в отключенном состоянии

Мы с тобоф о разных методиках говорим судя по всему. Я имел ввиду схему, когда медиаархив постоянно доступен, то бишь винты воткнуты в сторадж-сервер (или что-то ему аналогичное).

Если оперативно меняемых данных 500GB, то тут SSD не помощник, согласен - но скорей по причине цены, поскольку такая конфигурация за рамки разумного бюджета вылазит (поскольку их основная ориентаци таки много чтения, а не много записи, и для вменяемой надежности ему надо примерно 50% свободного пространства, так что надо расчитывать терабайтное хранилище).

Понял. Значит про TRIM в этом случае можно забыть :)

Тогда интересует другой вопрос: насколько сильно проседает скорость если не делать TRIM?

Ну речь про десктопные SSD вроде, с HDD всё понятно. SSD же вообще перемапливает блоки куда ему заблагорассудится, какое последовательное чтение тут может быть?

понятно что буфферизуется и параллелится, ибо скорость стирания/записи катастрофически низкая, в десятах а то и сотнях мс измеряется.

НЕЛЬЗЯ!!!

Почему?

потому-что В ПРИНЦИПЕ нельзя выяснить, кому давать память, а кому не давать. Это как акции МММ, которых намного больше, чем активов этой самой МММ. Ты понимаешь, почему МММ неустойчива принципиально? Вот с памятью та же самая история - у тебя есть 1Гб физической памяти, а выделено 10Гб виртуальной. Из которой ты используешь скажем 600Мб. И это не баг, а фича. Теперь подумай, что произойдёт, когда ты используешь последний байт из своих (как ты думаешь) 10Гб(хотя у тебя их всего 1Гб)? Можешь какое-нибудь решение предложить? Предлагай, я слушаю. Линус тоже на тебя надеется и на предложенное тобой чудо. Точно также ждут и надеются спецы из мысы и огрызочники. Яви!

Да, если его отключить, система всё равно работает, но МЕНЕЕ УСТОЙЧИВЕЕ.

Пруфы пожалуйста

я уже говорил - полные матана пруфы ищи в «Искусстве Программирования» Д. Кнута. Это азы. Противопоставить матану можно только магию, если математик говорит нам, что 2×2==4, то это так. Я - сирый и убогий и магией не владею. За 50 лет тоже никто так не смог. Будешь первым.

Какие параметры smart`a в SSD позволяют судить о степени изношенности кроме количества записей-перезаписей?

На самом деле, у меня давно есть шальная идея попробовать запилить оверлей через unionfs, чтобы сырцы были на SSD, желателнно на фс с компрессией, а продукты сборки писались на HDD, но все никак не доходят руки.

А-а-а, ясно, бубунтухейтер, можешь пруфы не предоставлять

эти советы просто лежат на том форуме. В OS Ubuntu таких «оптимизаций» НЕТ. Система тут не причём, Марк Шаттлворд к этим советам НЕ ИМЕЕТ ОТНОШЕНИЯ.

И да, раз такого уродства Марк в своей системе не сделал по дефолту, значит так надо. Если для тебя авторитет - Марк, не делай так.

SSD же вообще перемапливает блоки куда ему заблагорассудится, какое последовательное чтение тут может быть?

ну если постараться (например записать весь объем случайной записью по 4к), то в одном блоке на чтение из ssd (128к) может быть только один сектор полезных данных (4к)

с того, что перемапливает внутри и хост об этом вообще ничего не знает. С точки зрения OS это блок девайс. И далее все упирается в работу DMA на твоем SATA контроллере, и как часто он будет долбать проц прерываниями. Т.е. либо ты один раз запрограммировал DMAшку (читать от 0 и до 100500 блока, либо 100500 раз), соответственно и прерывание приедет тебе либо 1 раз, либо 100500 раз. Хотя на самом деле тут еще целая куча других факторов.
Из опыта могу сказать, что последовательное чтение на некоторых NAND контроллерах быстрее.
Кстати, к слову сказать, в DDR2/3 последовательное чтение/запись тоже быстрее, так как там время тратится на открытие/закрытие банки.

Точнее, проблема возникнет у той, для которой память ещё фактически не распределена. Если остальные программы уже alloc'нулись и уже попользовали страницы, а потом «эта» аллокнулась и начала обращаться, проблемы будут именно у неё.

а она виновата, что вся память засрана? Очевидно - нет. Вся её проблема только в том, что она куда-то там пару байт записать посмела. А быдлокод засравший все гигабайты - не при чём.

Тогда интересует другой вопрос: насколько сильно проседает скорость если не делать TRIM?

В том же треде смотри,
у него прямо классика случилась.
58МБ/с показывало :)

с того, что перемапливает внутри и хост об этом вообще ничего не знает. С точки зрения OS это блок девайс. И далее все упирается в работу DMA на твоем SATA контроллере, и как часто он будет долбать проц прерываниями. Т.е. либо ты один раз запрограммировал DMAшку (читать от 0 и до 100500 блока, либо 100500 раз), соответственно и прерывание приедет тебе либо 1 раз, либо 100500 раз.

И какая скорость обработки прерываний? По-моему со скоростью чтения с диска она не сравнима и при относительно разумном фрагментировании файла заметной разницы из за этого фактора не должно быть.

Сильно зависит от задач. Но вообще, память в любом случае быстрее.

ты не совсем прав: во многих практических случаях, скорость входит в «дано». Т.е. тебе просто не нужно читать «как можно быстрее», обычно тебе ещё надо обсчитывать и/или отправлять свои байтики. HDD очень часто является узким местом, а вот SSD возможно исправит ситуацию (тормозить будет уже что-то другое, и потому замена SSD на память уже ничего не исправит).

Хотя конечно это далеко не всегда так.

В макоси хорошо сделано - если не жать cmd-Q, то программа будет висеть в памяти/свопе и при необходимости её повторного использования будет доступна очень быстро.

в Linux сделано точно так же. Только cmd-q надо самостоятельно костылять (если надо). Попробуй очистить кеш, и удивись.

Нет, я имею в виду, что тот же браузер запущен, инициализирован и т.д., просто окон у него не открыто. Если я в хроме закрою все окна, то и процесс хрома завершится. То же в случае с текстовым редактором, текстовым процессором, гимпом и т.д. То, что однажды прочитанные файлы в кеше лежат это понятно и это ускоряет запуск, но если программа уже запущена, это ещё лучше.

Чтобы в линуксе было так же, надо переписывать линуксовые программы, чтобы процесс оставался висеть в памяти, когда все документы закрыты. Но при этом нужен визуальный доступ к процессу без окон, в маке это главное меню, которое отделено от окна, в линуксе такой концепции нет.

потому-что В ПРИНЦИПЕ нельзя выяснить, кому давать память, а кому не давать. Это как акции МММ, которых намного больше, чем активов этой самой МММ. Ты понимаешь, почему МММ неустойчива принципиально? Вот с памятью та же самая история - у тебя есть 1Гб физической памяти, а выделено 10Гб виртуальной. Из которой ты используешь скажем 600Мб. И это не баг, а фича. Теперь подумай, что произойдёт, когда ты используешь последний байт из своих (как ты думаешь) 10Гб(хотя у тебя их всего 1Гб)? Можешь какое-нибудь решение предложить? Предлагай, я слушаю. Линус тоже на тебя надеется и на предложенное тобой чудо. Точно также ждут и надеются спецы из мысы и огрызочники. Яви!

Майн Гот!!! Вы же натягиваете примеры на свои доводы не задумываясь о потенциально-различных железных реалиях у пользователя.

Ну хорошо, вот тогда тоже натянутый пример: Представьте, на вашем ПК, ОЗУ > НЖМД (SSD) на который установлена ваша ОС. Какой должен быть СВОП?

3. noatime ставить НЕ НУЖНО, ибо может послужить УВЕЛИЧЕНИЕМ износа, а не уменьшением.

а теперь пересмотри свой вывод, учтя, что запись в ssd ведется блоками от 128кб http://en.wikipedia.org/wiki/Write_amplification

я прекрасно это знаю. Пересматривать нужно тебе. В SSD СТИРАНИЕ идёт блоками, типа как 128кб, а вовсе не запись. Запись осуществляется маленькими блоками, например 4К. Т.е. в один остров 128к ты можешь записывать одну и ту же страничку в 4К 32 раза. получая «грязный» блок (в котором всего 4К используется, а остальное не нужно). Т.е. представь себе, что у тебя всего один остров с 32я страничками. Ты можешь очень быстро 31 раз переписать эту свою страничку, и лишь на 32й раз тебе придётся ждать, пока блок сотрётся. Очевидно, что GC просто должен искать такие блоки в фоне, и их стирать. IRL он уже ищет и стирает. Потому всё работает, и работает хорошо (я о таких перезаписываниях одной странички). Оно конечно ест ресурс, но ОЧЕНЬ медленно. А вот переписывания кешей лишний раз - это плохо, ибо файлы в среднем куда как больше 4К. Всё это усугубляется тем, что программы обычно не проверяют, запретил ты atime, или нет. А даже если и проверяют, что им теперь, свою БД подымать для статистики?

Короче - практика доказывает, что современные SSD нормально с atime справляются, хотя вот во флешках эта проблема есть, и там нужно ставить noatime.

Не париться по этому вопросу. Когда твой SSD начнёт дохнуть, купишь новый, который сильно подешевеет к тому времени, если корейцы бузить не будут. И вообще скорее всего он не сдохнет в обозримом будущем.

+много. Хотя discard включить имеет смысл. Оно увеличивает скорость записи. Точнее - МОЖЕТ увеличивать в некоторых ситуациях.

да, cmd+w/cmd+q удобно юзать

У меня вопрос, тем кто в теме: если подключить SATA SSD к PATA интерфейсу через конвертер, будет ли оно работать? Будет ли работать TRIM (хотяб с помошью костылей)?

а какая разница-то? И там и там ATA. ИМХО будет всё работать (ессно медленнее). Про TRIM не пробовал, но оно входит в ATA спецификацию, а вовсе не в SATA. Т.е. должно работать и в IDE.

а, это приведет к лишним стиранием, но если не сделать такого рефреша, можно потерять данные.

что-то мне подсказывает, что потери будут и с рефрешем. Надо инфу для восстановления хранить, man WinRAR или par2. А рефрешать толку мало ИМХО

Ну так да, ssd решает много проблем. Поэтому у нас все, кроме больших полок, на ssd.

А это уже зависит от того какая архитектура, какая OS и что в этом прерывании делается. Тебе считай чтобы прыгнуть нужно в стек скинуть стопку ругистров, записать новое значение PC, пройтись через кусок линухового ядра, общего для всех прерываний...

Или это уже в далеком прошлом и счас есть средства диагностики, чтобы мониторить железку и предотвратить потерю данных?

да. Есть SMART.

нет. тебе даташит гарантирует дата ретеншн допустим десять лет. И после этого если рефреша не сделать количество фейлов будет расти очень быстро, так что никакой winrar/par2 не спасет. При этом носитель хороший, и стирание/запись эти ошибки уберет.

Почему фрагментация это проблема?

скорость падает. И на SSD тоже, кстати. Там падает скорость записи(на HDD и чтения тоже)

Тогда интересует другой вопрос: насколько сильно проседает скорость если не делать TRIM?

на этот вопрос сможет ответить только тестирование твоих юз-кейсов. Может никак не просядет, а может - очень сильно. Зависит и от девайса и от задач.

Ну речь про десктопные SSD вроде, с HDD всё понятно. SSD же вообще перемапливает блоки куда ему заблагорассудится, какое последовательное чтение тут может быть?

дык SSD не просто так перелопачивает, если будет рандомно раскидывать, то у него все острова будут грязными. SSD старается пачкать один и тот же остров (если это возможно, и если это не сильно скорость портит). если у тебя есть 100 файлов, раскиданных по 100 островов, то если ты один файл сотрёшь, получится 100 островов, куда ты не сможешь писать (писать можно только один раз), т.е. тебе придётся один из островов освобождать - перекидывать данные по другим островам, а потом его стирать. Это и есть «деградация записи». А вот если каждый файл на своём острове, ничего перекидывать не нужно, просто стираешь остров, и все дела. А если есть TRIM, то он даже сам сотрёться в фоне.

На самом деле, у меня давно есть шальная идея попробовать запилить оверлей через unionfs, чтобы сырцы были на SSD, желателнно на фс с компрессией, а продукты сборки писались на HDD, но все никак не доходят руки.

вон мегабакс тут давеча скрипт написал. Говорит - быстро теперь собирается.

ну если постараться (например записать весь объем случайной записью по 4к), то в одном блоке на чтение из ssd (128к) может быть только один сектор полезных данных (4к)

ты забыл о том, что будет один сектор нужный, и ещё 31 ненужный, куда писать НЕЛЬЗЯ. И стереть тоже нельзя, ибо один нужный. Вилы. Но если контроллер угадает, и засунет в один остров один файл, то этого не произойдёт.

Нет, я имею в виду, что тот же браузер запущен, инициализирован и т.д., просто окон у него не открыто. Если я в хроме закрою все окна, то и процесс хрома завершится.

процесс завершиться, но данные так в памяти и останутся. У меня сейчас так занято 3Гб из 4х.

но если программа уже запущена, это ещё лучше.

ну не закрывай программу, в чём проблема-то?

Чтобы в линуксе было так же, надо переписывать линуксовые программы, чтобы процесс оставался висеть в памяти, когда все документы закрыты. Но при этом нужен визуальный доступ к процессу без окон, в маке это главное меню, которое отделено от окна, в линуксе такой концепции нет.

это ты хочешь сделать гуёвый CTRL+Z что-ли? Ну сделай, кто мешает-то? Отправь ему SIGTSTP, и будет тебе счастье. Можешь ещё и гуй напитонить, что-бы видеть, кого ты туда отправил.

Майн Гот!!! Вы же натягиваете примеры на свои доводы не задумываясь о потенциально-различных железных реалиях у пользователя.

это вам так кажется.

Ну хорошо, вот тогда тоже натянутый пример: Представьте, на вашем ПК, ОЗУ > НЖМД (SSD) на который установлена ваша ОС. Какой должен быть СВОП?

я разве говорил про РАЗМЕР свопа? Я говорил, что он НУЖЕН, но не говорил какой именно. Очевидно, для стабильности размер свопа достаточно сделать небольшим, т.е. делать его размером с ОЗУ НЕ нужно!

Вы так и не поняли идеи: не существует способа, что-бы гарантированно всё работало при исчерпании памяти. Можно на это просто забить, как сделали в Windows™. А можно придумать костыль, начисляющий скор всем приложениям, и прибивать то приложение, которое и виновато в утечке. Ведь если памяти не хватило, то возможны только две причины:

1. администратор дебил и/или нищеброд. Это не лечится

2. какая-то программа работает неправильно. Ошибка в программе, или просто так сложилось. Это _можно_ исправить, причём не нужно для этого всё ломать. Достаточно собрать статистику, и убить виноватого. Проблема в том, что если память кончалась ВНЕЗАПНО, собирать статистику будет некому, и не где. Компьютер превратится в тыкву. Если у тебя есть своп, то системе будет куда зарыться, а у OOM будет полно времени для составления статистики и выявления виновника проблемы.