Перенос журнала ФС на другой диск

PadoNak · 25 мая 2012, 15:47:41

Здравствуйте! Я начинающий "пользователь" Debian. И у меня ситуация такая...
Есть компьютер, который собираюсь использовать в качестве сервера, на него хочу поставить Debian (по этому поводу прочитал множество статей в интернете).
В компьютере есть 1 SSD и несколько HDD. На SSD собираюсь поставить корень, /boot, /usr, /opt (ext4), а на HDD вынести /var, /tmp, /home, /var/www (ext4, ReiserFS).
Что бы продлить срок службы SSD, журнал разделов, установленных на нём, хочу вынести на HDD.
И вот меня интересует как это можно сделать!? И когда? При установке Debian, или же после установки (предварительно выделив место на HDD для журнала) переместить журнал ФС с SSD на HDD?

Brainey · 25 мая 2012, 17:07:46

В описании Reiserfs встречал описание возможности переноса журнала на другое устройство, а вот насчет ext4 - не помню.

PadoNak · 25 мая 2012, 17:14:14

Поиск в интернете мне выдал что в ext3 есть такая возможность (только не нашёл как её реализовать). Думаю в ext4 тоже должна быть такая возможность, т.к. родственные ФС.

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

BULATUS · 25 мая 2012, 17:15:31

А для чего сервер? Какие задачи? У меня был нетбук с ssd, не помню точно, но три года по сей день он пашет. На нем кстати множество раз ставились с нуля различные дистрибутивы, ext4 всегда с журналом.

Сообщение объединено: 25 мая 2012, 17:17:21

Если так сомневаетесь, и как я понял установка еще не произведена, смело ставьте на hdd...

Brainey · 25 мая 2012, 17:30:47

Цитата: BULATUS от 25 мая 2012, 17:15:31ext4 всегда с журналом

Журнал на SSD не есть хорошо. Здесь небольшая статья по оптимизации фс и системы для SSD.

BULATUS · 25 мая 2012, 17:34:20

Я тоже был уверен что, не есть хорошо.... но блин работает. Нетбук устарел весь сам раньше, чем предсказываемая скорая смерть ssd....

Однако да, Brainey прав. Скорее всего мой случай исключение из правил, тупо повезло. Ведь в сети масса статей говорящих о недолговечности ssd, а как нам известно, нет дыма без огня.

PadoNak · 25 мая 2012, 17:42:35

Домашний сервер, хочу поставить веб (много сайтов), фтп, торрент, онлайн радио, может ещё что, пока ещё сам точно не знаю. Систему хочу поставить на SSD что бы получить выигрыш в скорости работы и загрузки приложений. Причём SSD далеко не новый и юзали его не один год до меня, поэтому не знаю как много у него осталось циклов записи/стирания, пока ячейки не станут битыми. Вследствие чего на SSD я хочу поставить только статичные и редко изменяемые файлы системы и минимизировать какую либо запись на него путём выноса журнала, а динамичные вынести на HDD. Можно конечно отказаться от журналируемой ФС, но за неимением UPS это не рационально.

Brainey · 25 мая 2012, 17:44:57

Документация ext4 на kernel.org.

PadoNak · 25 мая 2012, 17:48:36

Всё бы хорошо, да только с энглишом я на Вы

rayanAyar · 25 мая 2012, 18:52:06

немножко офтоп

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

[свернуть]

PadoNak · 25 мая 2012, 19:05:30

Ну т.к. этот "сервер" будет расположен у меня дома, то он будет использоваться и в домашних целях (как-никак комп мне тоже нужен)))). А насчёт баз данных - хорошая штука! Надо будет реализовать

saveriy · 26 мая 2012, 08:48:35

Приобрел новый ноутбук вместе с ssd. Выбрал фс ext4, журнал не отключил, ибо в сети пишут, что возможны проблемы с trim. Внес изменения в fstab. Это вся моя оптимизация.

PadoNak · 28 мая 2012, 00:09:11

Вот какую ссылку мне дали на другом форуме, правда всё по-английски, особо не разберёшь, но как я понял что во втором способе там описан как раз мой случай, так что это сделать вполне реально http://www.linux-mag.com/id/7642/

Сообщение объединено: 28 мая 2012, 01:14:54

Как я понял из этой статьи мой порядок действия такой:

mke2fs -t ext4 /dev/sda1 Первым делом создаём файловую систему на SSD / dev/sda1
mke2fs -O journal_dev /dev/sdb1 Далее создаём журнал на втором диске / dev/sdb1 . (в статье написанно что он должен быть 16 МБ)
tune2fs -O ^has_journal /dev/sda1 Тем самым говорим что файловая система на /dev/sda1 не имеет журнала
tune2fs -o journal_data -j -J device=/dev/sdb1 /dev/sda1 А тут уже указываем что журнал раздела /dev/sda1 находится на /dev/sdb1

А вот что я нашёл ещё в просторах интернета:

"Если уж мы говорим о гибридных системах SSD+HDD, то почему бы журнал фс не расположить на HDD ?
Создаем раздел на HDD размером 400MB (назовем его для примера sdb1) . Форматируем с помощью команды:
mke2fs -O journal_dev /dev/sdb1
А потом создаем фс на SSD c помощью команды:
mke2fs -t ext4 -J device=/dev/sdb1 /dev/sda1"

Тут команды немного различаются. И тут не говорим файловой системе на SSD "/dev/sda1" что она не имеет журнала.
Какой из этих способов будет вернее!? И зачем во 2-ом способе под журнал 400MB? Мне конечно не жалко, (хоть гигабайт, ничё сташного), харды большие, просто интересно действительно ли под это нужно столько места?

qupl · 28 мая 2012, 06:50:33

Размер раздела под журнал напрямую должен зависеть от размера основного раздела (читать про особенности ext4). А способы одинаковые, во втором меньше команд, потому что при форматировании сразу указывается место под журнал. ПМСМ.

PadoNak · 29 мая 2012, 02:21:22

Спасибо!
Вот что ещё нарыл в инете:

ЦитироватьЖурнал должен зависеть не от количества места, занимаемого разделом, а от количества транзакций, информацию о которых он должен хранить, а это не так уж много - только те, которые находятся в обработке.
man mke2fs говорит нам, что журнал может иметь размер от 1024 до 102400 блоков, что при стандартном размере блоков в 4k составляет 4-400MiB

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

Извиняюсь за тупой вопрос, но тем не менее он у меня возникает)))
Если при создании разделов указывать пути до ФС /dev/sda1 и журнала этой ФС /dev/sdb1, то если вдруг потом поменять харды местами или воткнуть в порт между ними другой хард, то имена разделов поменяются. Не возникнет ли при этом такой ситуации что файловая система, раньше находившаяся на /dev/sda1, окажется без журнала, т.к. имя раздела с журналом для неё тоже изменится. Поэтому, при создании ФС и журнала может лучше указывать UUID? Или там всё по-хитрому сделано и такого произойти не может?