Первоначально я спрашивал об этом суперпользователя, но мне кажется, что это скорее тема сервера.
Я только что купил 6-ядерный Phenom с 16 ГБ оперативной памяти. Я использую его в первую очередь для компиляции и кодирования видео (а иногда и для Интернета / БД). Я обнаружил, что все действия привязаны к диску, и я просто не могу поддерживать все 6 ядер. Я покупаю SSD raid, чтобы он сидел между HDD и tmpfs.
Я хочу настроить "многоуровневую" файловую систему, в которой операции чтения кэшируются в tmpfs, а записи безопасно проходят на SSD. Я хочу, чтобы файлы (или блоки), которые в последнее время не читались на SSD, затем были записаны обратно на жесткий диск с использованием сжатой файловой системы или уровня блоков.
В основном это гласит: - Проверить tmpfs - Проверить SSD - Проверить HD
И пишет: - Прямо на SSD (для безопасности), потом tmpfs (для скорости)
И периодически, или когда места становится мало: - Перемещайте наименее часто используемые файлы на один уровень ниже.
Я видел несколько интересных проектов. CacheFS, cachefsd, bcache кажутся довольно близкими, но мне сложно определить, какие из них практичны. bcache кажется немного рискованным (раннее внедрение), cachefs кажется привязанным к определенным сетевым файловым системам.
Существуют «объединяющие» проекты unionfs и aufs, которые позволяют монтировать файловые системы друг над другом (обычно USB-устройство поверх DVD), но оба распространяются в виде патча, и у меня сложилось впечатление, что такое «прозрачное» монтирование должно было стать ядром. функция, а не FS.
Я знаю, что ядро имеет встроенный дисковый кеш, но, похоже, оно плохо работает с компиляцией. Я вижу 20-кратное увеличение скорости при перемещении исходных файлов в tmpfs. Я думаю, это потому, что стандартные буферы предназначены для определенного процесса, а компиляция создает и уничтожает тысячи процессов во время сборки (просто догадываюсь). Похоже, я действительно хочу, чтобы эти файлы были предварительно кэшированы.
Я читал, что tmpfs может использовать виртуальную память. В таком случае целесообразно ли создавать гигантские tmpfs с подкачкой на SSD?
Мне не нужно загружать получившуюся многоуровневую файловую систему. При необходимости я могу загрузить grub, ядро и initrd откуда угодно.
Я склоняюсь к использованию ZFS с l2arc и zil на SSD и сжатии zfs и дедупликации на физических жестких дисках.
Итак, это предыстория. Думаю, у вопроса есть несколько компонентов:
* Recommended FS and/or block layer for the SSD and compressed HDD.
* Recommended mkfs parameters (block size, options etc...)
* Recommended cache/mount technology to bind the layers transparently
* Required mount parameters
* Required kernel options / patches, etc..
Компиляция: какой смысл записывать на диск что-либо, кроме двоичных файлов? Для этого полностью используйте tmpfs, а затем переместите скомпилированные файлы на свой диск.
Кодирование видео: я бы предложил использовать rsync (в режиме, который передает частичные различия файлов) для передачи файлов во время кодирования на диск. например в фоновом цикле, который завершается, когда одно видео было сделано. Кодирование также может происходить в tmpfs.
Кстати: какой дистрибутив вы используете? SuSE и RedHat поставляются с смонтированным / dev / shm (по умолчанию: половина вашей оперативной памяти с tmpfs).