[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ZFS



*** Artem Chuprina <ran@lasgalen.net> [2017-06-24 22:49]:
>Я правильно понимаю, что если я, допустим, хочу хранить
>бэкапы/архивы/файлообменник на zfs, мне стоит систему все-таки ставить
>на нормальный раздел, а не на zfs же? А zfs разворачивать поверх второго
>раздела?
>
>А если я, допустим, хочу рейд на нескольких дисках, то поделить каждый
>так же на два раздела, на первых сделать raid1 с системой, а на вторых
>собирать raidz?
>
>Потому что систему на zfs я если и водружу, то в случае сбоя хрен я к
>файловой системе штатными средствами бутовой флешки доберусь?

Не знаю как в GNU/Linux, но не могу представить в чём может быть
проблема или подстава достучаться до ФС с бутовой флешки? Загрузились на
"LiveCD" с флешки, сделали zpool import mypool и всё. Ну ok, как правило
оно захочет подмонтировать сразу же и поэтому перед этим надо указать
другую директорию монтирования. Я так делал много раз, просто указывая
какой-нибудь /tmp/mypool. Я не понял в чём проблемы держать систему на
ZFS. Там это очень кстати бы было если например делается какой-нибудь
dist-upgrade и хочется откатиться до начального состояния в случае
проблем.

>И второй вопрос, к тем, кто имеет опыт. Дома у меня 2 терабайта суммой
>из всего этого уже забито, я собираюсь ставить 4-терабайтник,
>вероятно. На работе имеется в виду держать зеркало из пары
>4-терабайтников.
>
>В обоих случаях супербыстрый доступ не требуется, но и суровых тормозов
>быть не должно. 
>
>Сколько надо памяти, чтобы zfs чувствовала себя в этих условиях
>более-менее комфортно? А если я захочу дедупликацию включить?  (Кстати,
>ее можно включить/выключить на ходу, или это надо делать в момент
>создания FS?)

8 гигабайт точно хватит, а вот с 4-мя терзают сомнения. А вот если
хочется включить дедупликацию, то, личного опыта нет, но говорят что
нужно примерно 5 гигабайт RAM на каждый терабайт данных. То есть в
случае с 4 TB дисками, лучше бы иметь более 20 гигабайт. Дедупликацию
можно включить на уже работающей системе, когда угодно, как и выключить.
А точно вам нужна дедупликация? Вот например прозрачное сжатие LZ4 штука
я считаю почти всегда не помешающая (zfs set compression=lz4 mypool), а
вот дедупликация... я за несколько лет так и не смог увидеть в домашних
условиях где бы это могло помочь. Если делаются какие-то "ответвления"
типа clone или там snapshot (например есть chroot какой-нибудь ОС,
хочется из него наделать разных других chroot-ов для контейнеров) -- то
там и так только дельты хранятся. Где-то я чуть ли не в официальных
мануалах Sun-а (Oracle?) видел что зачастую правильное использование
clone-ов (snapshot и прочего) решает большинство проблем с
избыточностью, где люди думают о дедупликации. Хотя если это
какой-нибудь там хостинг картиночек, где одни и те же кошечки тысячами
пользователей заливаются, то там поможет. В ZFS есть команда zdb -S
mypool которая "эмулирует" дедупликацию и показывает поможет ли она или
нет. Буквально вчера на одном из разделов её делал у себя (подумал что
может пора?):

    # zdb -S storage
    Simulated DDT histogram:

    bucket              allocated                       referenced
    ______   ______________________________   ______________________________
    refcnt   blocks   LSIZE   PSIZE   DSIZE   blocks   LSIZE   PSIZE   DSIZE
    ------   ------   -----   -----   -----   ------   -----   -----   -----
         1    8.87M   1.11T   1.10T   1.10T    8.87M   1.11T   1.10T   1.10T
         2    6.31K    807M    782M    782M    13.0K   1.63G   1.57G   1.57G
         4      250   31.2M   27.2M   27.2M    1.08K    138M    120M    120M
         8       11   1.38M    653K    653K      102   12.8M   5.61M   5.61M
        16        7    896K    134K    134K      156   19.5M   2.38M   2.38M
        32        1    128K   20.5K   20.5K       52   6.50M   1.04M   1.04M
     Total    8.88M   1.11T   1.10T   1.10T    8.89M   1.11T   1.11T   1.11T

    dedup = 1.00, compress = 1.00, copies = 1.00, dedup * compress / copies = 1.01

Видно что о ней думать не приходится совершенно.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF


Reply to: