[Решено] Как бы правильно сделать зеркало SSD на HDD (unionfs/aufs???)

Решил собрать новый комп, не удержался, заказал в числе прочего SSD на 60 Гб для ускорения. И вот только теперь изучаю вопрос.

Так-то всё хорошо. Как распределять каталоги по разделам и дискам, как выбрать ФС, что держать в оперативе - много где обсуждается, это не вопрос.

А смущает меня, собственно, надёжность всего решения. Нет, что пишут люди, я уже прочитал (типа, как не убить сразу SSD постоянной перезаписью). Я бэкап хочу на HDD - если сдохнет SSD, ну, значит сдохнет, пересобирать потом всё чтобы не пришлось.

Один вопрос я сейчас не понимаю. Итак, принципиально я решил использовать SSD не для кэширования HDD, а для хранения раздела с программами, чтобы повысить скорость их запуска. (С кэшированием-то всё просто было бы.)

Но хочется в то же время для надёжности держать копию этих данных на жёстком диске - что-то вроде программного зеркала типа RAID, но так, чтобы сохранить производительность SSD. Т.е., чтобы всё работало с SSD, а изменения копировались на HDD в фоновом режиме (или наоборот?). Т.е. предполагаю иметь раздел на SSD и раздел такого же размера на HDD, просто как резервное хранилище. Как их скорешить, пока не понимаю.

Путь прямолинейный - простой бэкап:
- собрать всё на HDD;
- сделать копию на SSD;
- использовать в работе SSD;
- периодически делать бэкап на HDD.
Нет в таком решении прозрачности, которая есть при использовании обычного RAID.

Все постоянно пишут про использование unionfs/aufs для таких вещей, но никак не соображу, как прикрутить её в данном контексте. Как я понимаю unionfs (она ведь не для того, что мне нужно, создавалась), изменения будут сохраняться на файловой системе с большим приоритетом. Можно сделать, допустим, так:
- собрать всё на HDD;
- потом системный раздел скопировать на SSD;
- смонтировать оба раздела с помощью unionfs (приоритет - у SSD);
- пользоваться;
- время от времени скидывать изменения обратно на HDD (через cron).

Это же ерунда получается - unionfs тут не нужен, это такой же бэкап. Хочется, чтобы последний шаг выполнялся сам в фоне и не время от времени, а постоянно при изменениях, т.е., прямо, как в RAID, но без ущерба производительности.

Или же можно так:
- SSD под unionfs на только чтение;
- HDD - чтение-запись;
- и периодически скидывать изменения на SSD.

Но тогда запись будет медленная на HDD. С другой стороны, там будет храниться только система (неизменяемые при обычной работе файлы), а я обновляю её раз в 2 месяца (по календарю). В промежутках лишь ставлю отдельные программы при необходимости. portage пусть всё собирает в tmpfs (оперативы у меня дохрена - она сейчас относительно остального дешёвая), а на hdd записывается только результат.

Может, я не пропустил какое-нибудь изящное решение вместо всех этих костылей?

PS. HDD у меня уже две штуки параллельно в RAID для надёжности. А рабочие (т.е. /home) данные будут храниться только на HDD и периодически rsync'ом копироваться на NAS, но это не столько для надёжности, сколько для синхронизации с ноутами, как "неотключаемый никогда общий репозиторий" (хотя надёжность тогда будет параноидальная - там тоже RAID из двух дисков; лишь бы молния в сеть не шибанула, но это отдельная история).

=========== Результат размышлений ===========
В результате, по крайней мере, для себя, я решил следующее.
1) Использовать SSD, как большой кэш HDD неэффективно.
2) Наилучшее решение - использовать SSD для хранения системы (программ).
3) autofs/unionfs - от лукавого (т.е. из EEEPC/Xandros, где поверх SSD с помощью unionfs монтировался ramdisk, чтобы пореже на SSD писать; если хранить на SSD только систему, файлы будут меняться редко и SSD не убьётся за разумное время)
4) Как лучше разбить на каталоги - варианты есть разные, более менее систематизированно описано здесь:
http://en.gentoo-wiki.com/wiki/Solid_State_Disk#HDD.2FSSD_combination
Но в этом деле нужен более творческий подход.
5) Какие использовать файловые системы - это вопрос до конца не устаканившийся, пока могу дать ссылку:
http://hakushka.wordpress.com/2011/08/13/ssd-disk-trim/
Тут хотя бы аргументировано объяснена позиция (хотя я сделаю по-другому, наверное)
6) TRIM - нужен (прощай, reiserfs! ты верно служил мне все эти годы ;).
Практически нужно в fstab добавить опцию discard, работает для ext3 и btrfs.
7) Ещё нужно добавить флаг noatime.
8) Данные на SSD убиться не должны, но я предполагаю делать бэкап с помощью rsync на раздел HDD того же объёма.
9) В случае проблем с SSD я просто буду грузиться с backup-раздела HDD (абсолютный минимум действий).