Pull to refresh

Comments 109

А теперь главное, о чём интел (по-крайней мере интел, думаю и у других вендоров так же) давным-давно твердит:

минимум 10, лучше 20% SSD НЕ СЛЕДУЕТ использовать. Причём не просто «не использовать», а сделать туды trim и больше не писать. То есть сделать secure-erase, а потом использовать раздел не больше 80-90% от размеров SSD.

Чем больше нетронутого места на SSD, тем меньше write-amplification, то есть тем дольше будет работать SSD, и тем быстрее она будет работать (на запись).
Проводил однажды тест под виндой на вендоре отличном от интел (OSZ) — действительно, чем больше места заполнено, тем существенней падает скорость и это становится заметно после 60-70%заполнения винта.
OCZ тоже рекомендует 10% неразбитыми оставлять на диске.
Так производитель давно же уже сам резервирует эти 10%? Или это не эти 10%?
Насколько мне известно, производитель резервирует 10% для восстановления убитых секторов. Что интересно, с разными версиями прошивки — резервируемое место (а следовательно место, доступное нам) может колебаться.
Ну то есть в любом случае, до того момента как эти 10% будут использоваться на замену трупов, можно же использовать их и для других целей?
Вообще да интересно потрогать эти ссд, все руки не дойдут купить. Контроллеры что-то все растут и растут, сами диски дешевеют и дешевеют, а ждать уже надоело совсем. Наверное куплю-таки на днях.
Увы, нельзя. Разве, кто-нибудь начал выпускать кастомные прошивки уже и для ССД. =)
Тоже хочу узнать по этому поводу. Конкретно интересует OCZ Vertex 3
Интел просто показал график write amplification в зависимости от overprovision. Интуитивно видимая точка перелома находилась в районе 10-20%. Делать его или нет — решает каждый сам.
UFO just landed and posted this here
Если рядом на этом SSD стоит Windows, то почему бы и Ubuntu рядом не поставить, тем более она относится к жесткому диску намного более щадяще, чем винда — не записывая туда все подряд каждую секунду. Все-равно, согласитесь, приятно, что через пару секунд после включения свободно можно открыть несколько достаточно крупных софтин — и радоваться жизни.
Тем более, что SSD дает еще пару дополнительных плюсов — вроде отсутствие шума, стойкости к механическим нагрузкам и продления времени работы от батареи (процентов на 30 — железно)
Автор, для полноты можно было бы осветить ещё правильное разбиение SSD на разделы.
Что именно? Вы, наверное, имеете в виду выравнивание разделов?
/ — SSD
/boot — SSD
/home/user — HDD
/var — HDD
/swap — HDD или SD

Скорее всего, такое разбиение имелось ввиду.
На SDD стоит минимизировать запись и разместить только те данные, которые пишут редко, читаю часто — это относиться больше к запуску программ и настройкам системы.
В идеале можно вообще сделать / (и /boot если он отдельным разделом) в ro, и монтировать на запись только если что-то надо обновить.
Если /var будет на HDD, то будет тормозить aptitude.
Вы считаете, что данная задача должна проводится ежедневно и максимально быстро?
Ну, я относительно часто устанавливаю/удаляю/обновляю программы, и одна из причин покупки SSD — не иметь тормозов. Цена вопроса, по сути, копеечная — ресурсная запись за SSD исчисляется петабайтами, что на фоне объёмов IO на системном диске есть эквивалент бесконечности.
Лично я бы в приоритет поставил скорость запуска/работы системы/программ и только.
Установка/удаление/обновление — это операции периодические с достаточно большими интервалами по отношению к запуску программы.
У Вас будет дольше обновления выкачиваться, чем ставиться, вероятнее всего, даже с /var на HDD.
М… У меня на SSD весь PV с VG с системными разделами, так что я точно знаю, что стало быстрее.

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

Да и остальных приложений, работающих с /var это тоже касается. От udev'а до mail'а.
В идеале еще и его.
Суть разбивки такова — оставляем на SSD редко изменяемые компоненты системы, все остальное переносим на HDD — получаем меньше запись на SSD = увеличенный срок жизни.
При такой разбивке, думаю, SSD хватит минимум до следующего апгрейда всей системы.
Какой прикол покупать SSD и беречь его как не знаю что?
Ради скорости.Низкого энергопотребления.
Всегда ради чего-то приходится чем-то жертвовать.

>/home/user — HDD
Вот здесь не согласен. В домашней директории пользователя довольно большое количество частоизменяемых файлов. Логичнее сделать /home/user на SSD, а на HDD симлинками кинуть большие и медленные директории типа ~/Video, ~/Music, и т.п.
Имненно! Если не выровнять разделы можно потерять в производительности и в сроке жизни.
Еще имхо следует добавить, что желательно создать tmpfs в пользовательском домике и завести туда кэш браузеров. Плюсов два — т.к. браузеры очень любят скидывать в кэш свои данные, до это тоже положительно скажется на здоровье SSD, и это ускорит работу браузера.

Автору вопрос — вы btrfs пробовали? Там, судя по всему, нативная поддержка и автодетект SSD есть, соотв. не нужно всяких тюнингов делать.
Не пробовал пока. Вроде она и создана с оглядкой на ССД, но пока находится на стадии тестирования. Если через месяц станет скучно — поэкспериментирую.

С кешом браузеров я поступил интересней — вставил в ноут SD-флеш на пару гигов, и всякий кеш закинул туда. Она и не торчит, и питания много не просит, стоит мало, да и, наконец, хоть какое-то применение нашел для этого слота — полгода там просто заглушка стояла.

Была мысль под Виндой перенести на эту флешку файл подкачки, но, думаю, это убивало бы ее за неделю
Я переносил на SD swap при 1 ГБ ОЗУ. swap стал плохо работать через год
я ядре уже давно присуствует — вроде больше года уже или двух, так что тут сложно сказать тестирование или нет.

Было много споров об эффективности (то как она место использует), но мне кажется в плане перспективности это очень и очень — тот же Copy On Write для SSD может быть очень полезен в плане сокращения операций записи.
Пробовал btrfs на SSD, дважды сыпалась fs. Причём последний раз её не удалось поднять с помощью fsck.btrfs.
А я уже давно сижу на btrfs на HDD и ни разу ничего не сыпалось. Хмм… =)
За неделю, я думаю, врядли SD-карта из современных помрет в таком режиме, полгода-год уж точно выдержит. В современных картах, насколько я знаю, ставят аналогичные используемым в SSD контроллеры, которые обеспечивает нечто вроде wear leveling.
Лишние 700 рублей на 2гб карточку раз в полгода найдется. А то без файла подкачки на нетбуке порой печально.
Пользуясь случаем — интересна была бы статья о необходимости ССД на нетбуке, и вообще ощущения от использования под разными ОС? Интернет полон описаниями, но обычно в качестве тестовых — топовые десктопные сборки.
Использую SSD (OCZ vertex 3) на большом ноуте — ощущения как под виндой так и под линуксом — все стало офигенно быстро. Загрузка в обоих случаях происходит практически мгновенно (буквально секунд 5-7), а приложения OpenOffice, например, запускаются меньше чем за секунду.
На нетбуке, имхо, SSD должны идти в штатной поставке, т.к. аппарат, если можно так сказать, более мобильный, и механика обычного HDD часто может быть повреждена.
Так и есть у Эппла. И пару раз видел версии нетбуков — специально для путешественников — чтобы при тряске или падении не повредить винт. Но это дороговато, да и ССД требует бережного обращения. Станет технология посовершенней — уверен, она вытеснит традиционные накопители.
Два годамназад ставил Убунту на свой нетбук. Поступил почти также, но все-таки делал файл подкачки на 2Гб.
Бук до сих пор живет и на плохое самочувствие не алуется.
Давайте на минутку переместимся в прошлое, и вспомним первые серии ёжиков (EEEpc) — многие из них были на ссд (который, кстати говоря, часто выпаивался и менялся на обычный 2.5винт) — и все до сих пор живы-здоровы.
Но все равно возникает вопрос — откуда на каждом шагу посты про скорую смерть ссд, про потери скорости и т.д.?
Буду рад, если обьяснят =)
Подтверждаю. Причём у меня материнская плата треснула от механических нагрузок (носил _всегда_везде_), а SSD жив-здоров.
Ага, у меня тоже eeePC 901 валяется, один из первых — оба SSD там еще живы. Хотя аппарат выдержал не один десяток перестановок и полных апдейтов системы, установок разных версий линукса и откатов на штатную XP, и даже несколько раз с макосью там экспериментировал.
Мне кажется что по умолчанию подкачка в большинстве дистрибутивов линукса работает ужасно. ИМХО, лучше отключить и потом когда-нибудь создать обычный файл для свопа если будет _очень_ надо.
> Мне кажется что по умолчанию подкачка в большинстве дистрибутивов линукса работает ужасно.

vm.swappiness is a tunable kernel parameter that controls how much the kernel favors swap over RAM. At the source code level, it’s also defined as the tendency to steal mapped memory. A high swappiness value means that the kernel will be more apt to unmap mapped pages. A low swappiness value means the opposite, the kernel will be less apt to unmap mapped pages. In other words, the higher the vm.swappiness value, the more the system will swap.

www.linuxvox.com/2009/10/what-is-the-linux-kernel-parameter-vm-swappiness/

Дефолтное значение vm.swappiness = 60, имхо это достаточно эффективно в плане выдавливания в своп только того что реально зря висит в памяти бОльшую часть времени.
Эх, если б всё было так просто… Могу сказать только что многократно наблюдал как система виснет почти намертво если потребление памяти становится больше, чем доступно физической памяти. И хорошо если через минут 20 упадут иксы и заберут с собой запущенные процессы, а иначе всё что можно сделать — нажать reset.
Я подобное тоже наблюдал несколько раз, но при весьма специфическом наборе условий (высокая «взрывная» IO активность, в результате которой происходит очень быстрое заполнение памяти при невозможности быстро «выдавить» данные в своп), и OOM killer просто не успевал сработать до наступления фактического OOM.
Но это, повторюсь, очень редкое явление. И сдается мне, такие ситуации можно предотвратить грамотным тюнингом vm.
И хорошо если через минут 20 упадут иксы и заберут с собой запущенные процессы, а иначе всё что можно сделать — нажать reset.
RAlt+SysRq+K
UFO just landed and posted this here
Спасибо за статью, очень информативно!
> наш никс очень любит вести разнообразные логи
Я ожидал что скажите про /var/log
Что скажете о нем про перенос в tmpfs?
Держу /var/log в tmpfs. Недостаток только один — если в результате экспериментов система зависает, то невозможно без дополнительного оборудования узнать причину.
Рад что помог!=)
Да, можно и его перенести. Главное — сам принцип переноса все в ОЗУ.

какая-то у вас путаница

> tune2fs -O ^has_journal /dev/sda1
ну, журнала нет, вообще. и толку? предлагается делать полный fsck после каждого упса?

> Также не стоит отключать журнал, добавляя параметр «writeback» в конфигурацию fstab
опция mode=writeback не выключает журнал, а без журнала вообще бессмысленна.
У ноутбуков упс не случается. На десктопе — журнал можно оставить. Я, в принципе и на нетбуке оставил его — пусть живет.
«опция mode=writeback не выключает журнал, а без журнала вообще бессмысленна.»
Суть в том, что она этот журнал оптимизирует-записываются не все метаданные. Но с ней возникают проблемы при запуске.
Те вы начисто отвергаете мысль о том, что ноут можно выключить долгим нажатием кнопки питания?
У меня было пару ситуаций когда reisub не помогал.
Не отвергаю, и сам использую. Но все равно такая ситуация достаточно редка.
резюмируя
man tune2fs до просветления
UFO just landed and posted this here
Отличная статья, как раз пол года назад собирал подобную инструкцию по кусочкам, единственное хотеться дополнить, что поддержка TRIM идет с Linux 2.6.33 ядра. Из собственного опыта в нетбуке Acer One B110 после 4 лет использования умер встроенный SSD от Intel на 8Гб, перепаял на 2.5' SSD KINGSTON 32Гб скорость загрузки существенно возросла как и общая отзывчивость системы. Мое мнение устанавливать SSD в нетбук однозначно стоит!
Спасибо!) У меня на SSD гарантия — 3 года. Я ничем не рискую — умрет раньше — заменю по гарантии.
Это был самый первый SSD от интела, очень медленный. Сейчас я думаю SSD шагнули далеко вперед и думаю 4 года при правильном использовании для них совсем не предел!
А вдруг они вперёд шагнули за счёт долговечности?
не только. со скоростями чтения/записи у ранних ссд было все плохо. С чем всегда было хорошо — так это со временем доступа
Все это, конечно, замчательно, только вы со своей статьей опоздали года на два. Большая часть всех этих «пугалок» уже неактуальна для современных SSD.
Будь у меня лишние деньги — обязательно бы провел бы краш тест ссд-носителя=)
Уверен, вы и покупая автомобиль обязательно разбиваете перед этим один-два. Ведь дураку ясно, что призводители все врут, втюхивая свой залежалый товар покупателям, верить можно только своим собственным результатам испытаний.
=)

Нет, винт я бы протестил только ради спортивного интереса. С чем-то другим так поступать не хочется.
Как показывает практика, не все производители такие сволочи. Многие дают вполне достоверные данные о своей продукции, понимая что врать потребителю — себе дороже.

Просто у кого-то винт живет 2 месяца, у кого-то 2 года. И хочется все-таки достать актуальную и достоверную на текущий момент информацию, например — о длительности работы в максимальной нагрузке.
Информация к размышлению: Совсем не любой отказ SSD вызывается пресловутым «исчерпанием ресурса записи в ячейках flash».
Более того, есть мнение, что эта причина в отказах SSD в меньшинстве.
Кстати да, большинство нашумевших отказов SSD вызваны сыростью прошивки и аппаратной части.
Спасибо, отличная статья.
Единственное чего не понял — почему ubuntu вынесено в название статьи. Данные советы подходят для любого linux дистрибутива.
Видимо из-за того, что автор не проводил тестирование способа на других дистрибутивах.
Да, вы правы — все мои эксперименты проводились в убунте, хотя, думаю — все это подходит к практическу любому Линукс-дистрибутиву.
Да сейчас вообще интересное время: если надо что-то погуглить, связанное с линуксом, то в 70% случаев запрос «how to *** ubuntu» будет выдавать больше и более простые для понимания результаты, чем «how to *** linux» =)
В заголовке скорее «Оптимизация Ubuntu под SSD»
Однозначно. Автор, поправьте пожалуйста.
> За это время файл подкачки не понадобился ни разу…
> Если Ваш сценарий использования системы подобен моему… файл подкачки не нужен.
>… своп-раздел — однозначно зло, сжирающее как ограниченные циклы перезаписи

Что-то тут не так… :)
Не понимаю, почему нельзя просто использовать SSD, всесте с логами, свопом и т.п.?
Сломается — поменять на новый. Или у них гарантия как-то ограничена?
Жалко данные терять, да и некоторое время на обмен потеряется.
Я лично после установки SSD в качестве системного диска настроил еженедельный полный бэкап данных с него, просто на всякий случай.
Гарантия ограничена. Точно не скажу-но вроде должно быть не более 20гб записи каждый день, и тогда винт проработает 3 обещанных года. Посмотреть статистику чтения-записи очень легко. Если увидят в СЦ, что вы за месяц записали пару терабайт- то, в обмене откажут. Вопрос в том — станут ли смотреть?..
Посмотрел — да, действительно, в новых дисках Intel гарантия сокращается, если «Media Wear-out Indicator» в SMART падает до 1.

У меня за год около 2TB записи, индикатор упал на 1%. Так что суть дела не меняется.

Если интересно, время жизни дисков в TB:
www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm
Я так и сделал. Кроме темпов и свопов еще проект гигантский с сотнями маленьких файлов. При компиляции которого делается уйма всякого временного. Записано у меня 1.5 Tb за полгода. Утилитка пишет что жить ему еще 8 лет при такой нагрузке. Но как по мне — даже если через 2 года помрет, то все равно уже апгрейд надо будет делать. И цены тогда будут другие, я думаю.
Никак не умаляя полезности советов относительно экономии батареи на ноутбуках, хочу таки заметить что мо нашему опыту необходимость «оптимизации» циклов записи сильно преувеличена. Мы используем ССД в некоторых серверах, где на них данные пишутся несколько тыс раз в секунду. Все диски до сих пор живы. Кроме того нам известен опыт fastpic.ru, где часть «быстрых» данных хранится на ССД. Количество циклов записи там конечно меньше, в основном чтение, но тем не менее это в сотни раз больше бытовых приложений. Отказы ССД дисков если и были — то от перегрева, либо от «кривизны» модели (например 3.5-дюймвые ocz отказались работать под нагрузкой). В гражданских компьютерах «выбракованные» на серверах ссд-шки живут до сих пор.
О, а расскажите плиз поподробнее.
— Сколько времени уже используете SSD,
— Какой объем данных пишется на них в секунду,
— Какие модели используете,
— Мониторите ли состояние дисков (в смысле работоспособных ячеек), и если да — с какой скоростью деградация ячеек происходит.
Что касается фастпика — то там все новые картинки льются на ссд, по мере забивания добавляются новые диски, и лишь впоследствии, редко используемые картинки кладутся потом переносятся на сас диски.
Сответственно 50-60 тыс картинок ежедневно пишутся на диск, пока он не кончится, потом нагрузка на запись падает, остается только на чтение, причем практически 100-процентная.

Насчет моделей — там зоопарк, т.е Кингстоны, ОСЗ, А-Дата и т.п. Принципиальной разницы по скорости насколько я понял нету, по надежности — писал выше. Дисков всего около 30 штук.

На рто используются несколько PCI-X плат OCZ с SSD маленького обьема, на них лежат особо критичные к скорости БД. Работают около года, отказов пока не было. Оказались в разы быстрей ( и в разы же дешевле) SAS кеш-контроллеров с 15к винтами. Как раз их и дубасят запросами на запись и чтение круглосуточно. Насчет мониторинга — спрошу у программеров, сам не знаю :)
Т.е. фактически, активная запись на диск ведется до тех пор пока он не заполнится, а потом в основном идет чтение.
Ясно, спасибо за инфу.
Написали же что это на сервисе с картинками такая ситуация, а на rutracker'е активная запись ведется постоянно. Про статистику деградации в этом случае было бы очень интерестно узнать, если мониторинг ведется…
А вот мне кажется, что такая опция должна быть встроена в дистрибутивы, вам не кажется?
хорошая статья и буду сейчас проверять инфу о ТРИМ, но почему вы не уделили внимание выравниванию разделов?
Кстати, нашел еще пару вещей по сабжевому поводу:

1. Насчет реальной полезности не уверен, но мысль интересная:

none /var/cache unionfs dirs=/tmp:/var/cache=ro 0 0

2. A important point is the scheduler wich should be noop. You can set this scheduler via kernelparameter elevator=noop or via a entry echo noop > /sys/block/sda/queue/scheduler in you rc.local.

И по поводу выравнивания:

wiki.archlinux.org/index.php/SSD#Partition_Alignment
>> Если вы исправили fstab, перезагрузились, но трим не активировался — ищите ошибки в неверном отключении журналирования.

То есть, если я не отключил журнал, то не увижу нули? А трим работает в этом случае?
Только что почистил место на венике, перенёс пару гигов на внешний диск. И эти сектора обнулись. Видимо работает, но с задержкой.
Увидите.не увидите, если неверно его отключите.
Очередные вредные советы на хабре, ей богу, ну кто только такое из песочницы пропускает?
Во первых:
Если говорите людям отключить журнал по команде tune2fs -O ^has_journal /dev/sda1 для ext4, то вы просто обязаны предупредить людей, что опция discard при монтировании работать не будет, т.е. TRIM не функционирует!
и во вторых:
самое главное, это как можно меньше писать на диск. Да, журналы пишутся часто, но что еще пишется очень часто? Правильно, всякая фигня в /tmp (и других директориях), но т.к. /tmp (и некоторые другие иногда) очищается при ребуте, то незачем вообще хранить эту информацию на диске, надо смонтировать его на рамдиск. в fstab:
tmpfs /tmp tmpfs mode=1777
Ну и самое главное — это выровнять разделы так, чтобы контроллеру при перезаписи одной ячейки не приходилось перечитывать две ячейки памяти. Подробности есть в интернетах.
Да, признаю, ошибка есть. Про выравнивание, к счастью, в комментариях ссылку дали.
>> Если говорите людям отключить журнал по команде tune2fs -O ^has_journal /dev/sda1 для ext4, то вы просто обязаны предупредить людей, что опция discard при монтировании работать не будет, т.е. TRIM не функционирует!
Пруфлинк?

>> незачем вообще хранить эту информацию на диске, надо смонтировать его на рамдиск. в fstab:
Вы пост читали? Там это есть.

>> Ну и самое главное — это выровнять разделы так, чтобы контроллеру при перезаписи одной ячейки не приходилось перечитывать две ячейки памяти.
А вот это автор действительно забыл.
какой еще пруфлинк?
можете сами проверить, можете нагуглить, можете код в ядре посмотреть как работает опция discard. без журнала она ничего не сделает.

что касается того, что написано в статье, то вот это лишнее:
tmpfs /var/tmp tmpfs defaults 0 0
т.к. после перезагрузки все оттуда сотрется, а не должно.
>> можете сами проверить, можете нагуглить, можете код в ядре посмотреть как работает опция discard. без журнала она ничего не сделает.
Да, похоже на правду.

>> tmpfs /var/tmp tmpfs defaults 0 0
А штож там полезного такого? Как бы год уже работаю с этой опцией. Ничего не поменялось.
ну может у вас софт туда не пишет ничего для себя полезного, но по стандарту FHS эти файлы не должны удалятся при ребуте и нужны будут софту всегда. ничего критичного, вероятно, т.к. все равно это временные файлы.
Автор, по возможности, объедините, пожалуйста, все положительные моменты, услышанные в комментариях, как продлить срок службы SSD. Получится мануал по переходу на SSD для всех на Linux, который предостережет от частых ошибок и позволит максимально оптимально использовать устройство.
Адовая подстава.
Дважды натыкался что в топике discard написано с русской «С».
Sign up to leave a comment.

Articles