В общем, взял я вот этот - PLEXTOR PX-128M5S
Систему уже поставил начерно, сделал всякие типовые настройки - локаль, часы, груб, просто чтоб загружалась система.
Статья в вики про SSD годная, всё толково разжёвано, и что приятно, русская версия практически синхронна английской.
Вот что я сделал. Потом поругайте, что не так.
Разметил SSD - сначала идёт выровненный раздел на 124Г под корень и дом, а в конце 4Г под swap на всякий случай.
Каждый из двух магнитных HDD разделил пополам так, что первые разделы объединяются в страйп raid0 - (md0), а вторые два в зеркало raid1 - (md1) соответственно. Оба эти раздела форматировал в ext4 (как и на SSD) и смонтировал через fstab по UUID в /home/ftp (raid0) и /home/arc (raid1) соответственно. Последний видимо будет для всяких шибко важных данных, проектов, исходников и т.д., которые очень боязно терять. Первый будет содержать всякое восполнимое барахло типа кино и музыки, которое ещё будет видно через ftp наружу в локалку.
Теперь вот какой момент… рассуждаю как бы…
Наверное, нужно вынести весь /var куда-то, желательно в raid0 для скорости. Но пока получается как-то оно костыльно. Т.е. нужно создать каталог /home/ftp/var, который потом будет монтироваться в /var (или надо делать bind?). Сейчас в /var (который пока что на SSD) всякая чепуха, что положена после нормальной установки, кэши всякие, логи и т.д. Можно ли всё это содержимое тупо перекинуть в /home/ftp/var, а потом в fstab прописать точку монтирования для /var, которая указывает не на раздел, а на каталог? (bind?) Записи в fstab вообще по порядку обрабатываются? Нужно ведь, чтобы оно срабатывало уже после монтирования рэйдов. Или не парить мозги себе и окружающим и под /var (да и под /tmp до кучи) сделать отдельный раздел. Вопрос опять же какого размера… Ээх… неохота плодить разделы без жизненной необходимости.

gluk
SSD сейчас умирают из-за контроллера, а не из-за износа ячеек.
/tmp в памяти можно держать, а для крупных пакетов запускать yaourt как написано в man:
--tmp <dir>
     Use <dir> as temporary folder. default to /tmp
Ну… это одно с другим связано наверное. Скорее, ячейки изнашиваются по вине не шибко мудрого контроллера. Чтоб прямо так железо дохло… очень редко такое встречал, это уже скорее в облась брака можно отнести. Типа, радиатор плохо наклеили, перегрев и т.д.
За tmp и yaourt - спасибо за наводку. Это хороший вариант. Больших пакетов, которые не лезут при сборке в оперативку, считанные единицы.
sleepycat
не знаю, зеркальный массив у меня ассоциируется с бекапом. Но может дейсвительно я слегка приукрасил словцом. По поводу снапшота, я рекомендую если все таки бекап нужен инкрементный и частый осилить бакулу, а не этот инструмент. Как говорил известный персонаж, “меня терзают смутные соменния”, но это имхо.
Меня вот они тоже просто затерзали :))) Почитал форумы, поглядел тесты - выходит как бы так, что даже один SSD, даже на SATA2 будет в разы быстрее моего рейда, который сам по себе - спящий катаклизм. При таком подсознании трудно успокоиться и уже начать заниматься делами. Осознание, что плоды этих “делов” могут в одночасье помахать ручкой, просто парализует.
С бэкапами буду разбираться, спасибо за “тычки” в нужном направлении.

gluk
Crucial M4 - один из лучших, проверено временем. Это однозначно хороший вариант.
Плекстор - быстрое гугление говорит что он на марвеловском контроллере. Скорее всего тоже будет долго работать, много больше чем год.

Я бы для успокоения поискал в других магазинах M4 на 128ГБ.

/tmp у меня в оперативной памяти, при перезагрузке стирается.
Они вроде как на одинаковых контроллерах сделаны, но в плексторе какая-то “toggle nand” стоит. Говорят, что служит дольше (слухи), да и чуток побыстрее он. По надёжности вроде как на оба отзывы хорошие, хотя этот Crucial М4 конечно по массовым опросам явный фаворит.
Осталось разобраться что конкретно надо держать на SSD, а что выносить на HDD. Тут как-то тоже не всё понятно.
/tmp в оперативку мне нельзя выносить, у меня только 4G памяти (DDR2 1066). Как-то был там у меня /tmp, так крупные пакеты не собирались.
Ну и… например кэш пакмана держать на SSD смысла нет. Логи всякие тоже. Наверняка всё это проработано и описано до мелочей, в арч-вики есть статья, например. Думаю, разберусь, хотя советы внимательно слушаю :)
sleepycat
не знаю, зеркальный массив у меня ассоциируется с бекапом. Но может дейсвительно я слегка приукрасил словцом. По поводу снапшота, я рекомендую если все таки бекап нужен инкрементный и частый осилить бакулу, а не этот инструмент. Как говорил известный персонаж, “меня терзают смутные соменния”, но это имхо.
Меня вот они тоже просто затерзали :))) Почитал форумы, поглядел тесты - выходит как бы так, что даже один SSD, даже на SATA2 будет в разы быстрее моего рейда, который сам по себе - спящий катаклизм. При таком подсознании трудно успокоиться и уже начать заниматься делами. Осознание, что плоды этих “делов” могут в одночасье помахать ручкой, просто парализует.
С бэкапами буду разбираться, спасибо за “тычки” в нужном направлении.

gluk
Crucial M4 - один из лучших, проверено временем. Это однозначно хороший вариант.
Плекстор - быстрое гугление говорит что он на марвеловском контроллере. Скорее всего тоже будет долго работать, много больше чем год.

Я бы для успокоения поискал в других магазинах M4 на 128ГБ.

/tmp у меня в оперативной памяти, при перезагрузке стирается.
Они вроде как на одинаковых контроллерах сделаны, но в плексторе какая-то “toggle nand” стоит. Говорят, что служит дольше (слухи), да и чуток побыстрее он. По надёжности вроде как на оба отзывы хорошие, хотя этот Crucial М4 конечно по массовым опросам явный фаворит.
Осталось разобраться что конкретно надо держать на SSD, а что выносить на HDD. Тут как-то тоже не всё понятно.
/tmp в оперативку мне нельзя выносить, у меня только 4G памяти (DDR2 1066). Как-то был там у меня /tmp, так крупные пакеты не собирались.
Ну и… например кэш пакмана держать на SSD смысла нет. Логи всякие тоже. Наверняка всё это проработано и описано до мелочей, в арч-вики есть статья, например. Думаю, разберусь, хотя советы внимательно слушаю :)
Да уж… что-то сомнения меня терзают всё больше и больше. Просто чисто подсознательно очень страшно полностью переезжать со своими ценными, а также бесценными данными на массив рэйд0. Несмотря на то, что система работает, что-то в моей голове отчаянно протестует…
Предположим, всё-таки поставлю я SSD под систему… а два диска в рэйд1 под всё остальное. Какая-то должна быть особенная стратегия разбивки и монтирования разделов? Понятно, корень надо на SSD. Наверное, /home тоже, а иначе смысл теряется. /var /tmp наверное, надо выносить куда-то на внешний магнитный HDD. Что-то ещё надо… в гугле умных мыслей, вероятно.
Потом, выбрать правильный SSD тоже вроде как непросто.
После непродолжительного поиска, чтения отзывов и faq-ов остановился на двух моделях (просто ещё в добавок ко всему они есть в данный момент в ближайшем Ситилинке):
CRUCIAL M4 CT064M4SSD2, 64Гб
PLEXTOR PX-128M5S, 128Гб
Это “правильные” SSD? Второй, наверное, несколько избыточен, но на вырост (если не сдохнет как обычно через год) был бы неплох, к тому же ведь и /home предполагается на него пихать…
Спасибо, очень интересный комментарий…
Есть некоторая тревога конечно. Данные всё-таки планируется далеко не пятиминутные держать. С другой стороны, сколько ни было за всю жизнь у меня дисков - ни один из них не подох физически так чтоб вообще ничего вытащить нельзя было. Намного чаще встречались проблемы рассыпания самой файловой системы либо от потери питания, либо от софтовых зависаний. Один из дисков моего рэйда (Хитачи 7K3000 2Тб) проработал больше года без каких-то проблем (тьфу три раза), второй такой же проработал намного меньше, но… в общем, видно будет. UPS у меня стоит, правда, батарея уже не очень…
Насчёт fakeraid в гугле пишут, что по сути оно тоже использует CPU в той же степени, что и mdadm. Просто при fakeraid в биосе на уровне прерывания 13 этот рэйд обрабатывается, что даёт возможность его видеть даже в DOS. А так, чисто софтовый вариант по сути. Плюс, как Вы правильно заметили, иногда не работает NCQ, что очень преочень важно. Разница на однодисковой конфигурации просто разительная. При включенном NCQ в загрузке grub вообще стоит указать elevator=noop, т.к. в самом HDD упорядочивание делается, да и центральный процессор ещё немного разгружается.
Над бэкапами надо думать… Я не сисадмин и далёк от этих премудростей. Обычно просто копирую важные файлы, проекты всякие, фотки и прочее личное в укромное место (на внешний диск), а какой-то регулярной системы восстановления не использую. В принципе, ведь для восстановления системы нужны только список установленных пакетов, да и файлы настроек из /etc и домашнего каталога, и ещё по мелочи. Это не большой объём. Наверняка можно как-то автоматизировать такие бекапы. Вот утеря собственных наработок, что невосполнимы по сути, очень болезненна… Её надо исключить. Тут-то raid0 уверенности совсем не прибавляет…
В общем, что-то наверное не то я сделал… Наверное, надо было просто ограничиться только страйпом на корень, а остальное либо зазеркалить, либо вообще вывести из рэйда. Или как советовали для скорости докупить небольшой SSD, который всяко будет быстрее того, что у меня сейчас.
kurych
alexdsp
сначала swap 4Г, потом 64Г под корень, 512Г /home, и примерно 1.5Г на всё остальное (архивы, локальный ftp и т.д.) Соответственно, при объединении в рейд, размеры разделов будут удваиваться.
Раз уж все равно бъете диски на разделы, то почему же не сделать рутовый раздел на RAID1? Если один из дисков навернется, то, хотя бы, останется рабочая система на одном из зеркал. А для root-раздела 64Гига на 100 лет хватит. Зачем еще удваивать?
Дело в том, что ценность этого раздела очень невелика по сравнению с утраченными данными в /home и прочих архивных местах. Хотя, конечно, систему восстанавливать проще. Ну и фактор скорости… Для корневого раздела, где лежат все программы, это актуально. Ради скорости всё это и затевалось (из того, что имелось в наличии).
gluk
SATA2 и 300+МБ/с это как? Все что свыше 300 - погрешность или результат работы кеширования. Ибо не 3ГБит, а 300 МБайт. Ну да неважно.

Когда закончите настройку системы - не забудьте отписаться есть ли существенный прирост скорости.
3+3 Гбит/сек, или чуть меньше чем 300Мбайт/сек + 300Мбайт/сек = 600Мбайт/сек - суммарный предел пропускной способности двух каналов SATA2.
Никаких парадоксов. Два жёстких диска на разных каналах. На каждом канале скорость линейного чтения примерно 165 Мбайт/сек.
Естественно, всё измерялось на некешированном разделе прямо после загрузки системы. md0 - раздел свопа, который находится в самом начале диска. Прирост скорости получается двукратный.
В общем, запустил я софтовый RAID0 через mdadm. С dmraid и всякими биосовыми штучками связываться не стал. Компьютер грузится и работает, начальные настройки по вики сделал, но остальное требует всяческой доработки. Пишу с другого компьютера.

GRUB2 нормально грузит прямо с raid0 раздела! Никаких /boot разделов на raid1 делать не надо. Грузит прямо с корня.
Главное, как написано тут - http://travishegner.com/2012/02/boot-arch-linux-from-an-mdadm-array/
надо перед первым разделом каждого из дисков рэйда зарезервировать хотя бы пару мегабайт пустого места. Туда вроде как grub будет что-то полезное для загрузки записывать. В остальном, делал всё по вики.
На каждом диске сделал четыре первичных раздела с типом “авто рэйд” (создал на одном диске, потом при помощи dd скопировал MBR на второй диск, так как разделы должны быть идентичными).
Сделал как-то так: сначала swap 4Г, потом 64Г под корень, 512Г /home, и примерно 1.5Г на всё остальное (архивы, локальный ftp и т.д.) Соответственно, при объединении в рейд, размеры разделов будут удваиваться.
Померил скорость при помощи “dd if=/dev/md0 of=/dev/null bs=1G count=1” - получилось чуть более 320 Мб/сек.
Но как-то оно страшненько чисто подсознательно…
Надо читать systemd, очень всё неудобно стало. Где логи, почему квадраты в русской консоли? В общем, материться и ковырять до посинения.
Тут вот ещё что… На моей материнке только SATA 3Gb/s. Современные SSD будут буксовать… Посмотрел цифры тестов на блоки 4К - действительно скорость на порядок выше, чем у среднего диска. У дорогих моделей SSD может быть и на два порядка. Но такой режим - это всё-таки не слишком типовой режим работы. Запуск крупного приложения, обработка всяких фоток, стриминг видео, звукозапись - это обычно либо вообще линейное чтение-запись, либо более менее таковое. Думаю, всё же оставлю я покупку SSD на потом, когда будет апгрейд системы. А будет он скорее всего довольно таки нескоро. Да и в корпус у меня оно просто не полезет. Сейчас там установлены 2Тб(Arch) + 1Тб(WinXP). Если поставить туда второй 2Тб, да ещё и SSD впридачу… то ставить придётся в нештатные места, либо вообще оставлять лежать на дне корпуса… Это как-то не тру…
В принципе и один HDD удовлетворяет моим запросам, просто их у меня два одинаковых и хочется из того что уже есть получить более менее оптимальную конфигурацию. Просто JBOD - как-то оно не очень тру тоже…
Вот, кстати, циферки с моего одиночного диска.
# dd if=/dev/sda of=/dev/null bs=1G count=1
1+0 записей получено
1+0 записей отправлено
скопировано 1073741824 байта (1,1 GB), 6,54628 c, 164 MB/c

За ссылку на e4rat спасибо. Посмотрим что это, хотя к таким штучкам у меня есть предубеждение. Я когда-то давно пробовал preload и оно у меня со временем как-то довольно сильно заглючило, и я отказался от этого. Может, это годится для более менее статичной системы, а у меня постоянно что-то устанавливается, собирается пересобирается и т.д. В общем, я за относительную ванильность.
gluk
gluk ~ $ sudo dd if=/dev/sda of=/dev/null bs=1G count=1
[sudo] password for gluk:
1+0 записей получено
1+0 записей отправлено
 скопировано 1073741824 байта (1,1 GB), 5,86606 c, 183 MB/c
Всего-то 180 МБ/с, правда уныло как для SSD? Я ради интереса смотрел как оно под виндой работает. Холодный старт фотошопа 1-2 секунды. С винта на 7200 оборотов 20+ секунд.
Оспаривать не буду, но что-то всё же не верится… Скорость линейного чтения имеет огромное значение, не меньшее, чем время доступа. Ясное дело, всё зависит от пропорции мелких и больших файлов, от степени фрагментации HDD, но как-то сомнительно, чтобы SSD с 183 Мб/сек могло обогнать HDD RAID0 со скоростью 320 Мб/сек. На мелких файлах вероятно и обгонит, а вот на запуске крупных приложений, где файлы далеко не мелкие… не думаю… Опять же технология NCQ для мелких файлов ощутимо сокращает это преимущество.
Ну и всё-таки диски - они уже у меня есть, а SSD нет… На фоне этого не особо хочется что-то ещё покупать.
Кстати, при включении NCQ у 7K3000 был очень похожий эффект с запуском firefox. Время старта сократилось разительно, секунд с 5 до примерно 1.5 сек, но том же железе. Вот меня и беспокоит как оно себя поведёт в рэйде, который в биосе. Хотя, конечно, на чисто софтовый рэйд через mdadm это никак повлиять не может.