Добро пожаловать, Гость. Пожалуйста авторизуйтесь здесь.
FGHIGate на GaNJa NeTWoRK ST@Ti0N - Просмотр сообщения в эхоконференции RU.UNIX.BSD
Введите FGHI ссылку:


Присутствуют сообщения из эхоконференции RU.UNIX.BSD с датами от 18 Jan 11 22:51:00 до 04 Jul 24 04:46:01, всего сообщений: 10757
Ответить на сообщение К списку сообщений Предыдущее сообщение Следующее сообщение
= Сообщение: 6774 из 10757 ===================================== RU.UNIX.BSD =
От   : Eugene Grosbein                  2:5006/1           20 Mar 18 00:23:59
Кому : Slawa Olhovchenkov                                  20 Mar 18 00:23:59
Тема : Re: Шифрование
FGHI : area://RU.UNIX.BSD?msgid=grosbein.net+65231ab2
На   : area://RU.UNIX.BSD?msgid=2:5030/500+5aafead1
= Кодировка сообщения определена как: IBM866 =================================
Ответ: area://RU.UNIX.BSD?msgid=2:5030/500+5ab00a6c
==============================================================================
19 марта 2018, понедельник, в 19:33 NOVT, Slawa Olhovchenkov написал(а):

EG>> Это очень небольшая плата за то, что таблица разделов и все загрузчики
EG>> синхронизируются автоматически, не требуя создания разделов
EG>> на новом диске. 10 гигабайт начала диска на дешевой материнке ASRock
EG>> девятилетней давности с контроллером ICH7 (даже не ICH7R),
EG>> без поддержки AHCI-режима синхронизируются ажно четыре минуты:
SO> зато это слишком большая плата за то, что надо опять думать про размер места
SO> под log,

Hету там логов, они на основном пуле.

SO> под beadm и прочее

beadm это где?

SO>>> да не особо они нужны. да и толку от включения-то? вот есть у меня
SO>>> инсталяция с отдельным tank. там уже лежит 30ТБ. ну включу я там skein
SO>>> и что? да ничего не поменяется.
EG>> Я имел в виду включать на новой инсталляции.
SO> они у тебя что, каждый день?

Они у меня только начали появляться.

EG>> Смысл в том, что нет ручного переразбиения и необходимости ручной
SO> а тут все равно зависит от того, что на замену воткнули.

В случае с graid - не зависит. Оно достаточно гибкое.

EG>> установки загрузчиков при замене диска и нет деградации свопа.
SO> своп можно и замирорить. или выбрать вдвое больше свопа.

Своп, действительно, дело десятое. Главное - нет мороки с разбиением
и загрузчиками, всё само синхронизируется.

EG>> Я всё ещё не понимаю, откуда ты для *основного* пула вытаскиваешь
EG>> разницу между gpt-разделами и SINGLE-томами graid, когда в обоих
EG>> случаях выполняется только пересчёт смещений и передача запросов далее.
SO> хосподя. я же несколько раз тебе сказал, что разница в том, что до zfs агрегат
SO> доходит,

SINGLE-тома до неё доходят, они ничем от gpart-разделов не отличаются.

EG>> Загрузочный пул с рутом и /usr и нулевой нагрузкой на них вообще
EG>> никому не интересен. Все файловые системы типа /var, /usr/local, /home
EG>> и т.д. живут не на этом пуле.
SO> ах, еще и /var не там. ну вот совсем не хочу я в такую извращенную веселуху.
SO> я хочу поменьше думать и поменьшь дрочить руками при установке, апгрейдах и
SO> эксплуатации. zfs на весь диск этому удоволетворяет лучше.

К сожелению, zfs реально не может "на весь диск". Могло бы -
я бы не развекался с graid. И как раз чтобы во время эксплуатации -
при замене дисков - поменьше думать, я лучше потрачу совсем немного
больше времени при установке.

Eugene
--- slrn/1.0.2 (FreeBSD)
* Origin: RDTC JSC (2:5006/1@fidonet)

К главной странице гейта
Powered by NoSFeRaTU`s FGHIGate
Открытие страницы: 0.151223 секунды