The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Релиз OpenZFS 2.0, реализации ZFS для Linux и FreeBSD, opennews (ok), 01-Дек-20, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


37. "Релиз OpenZFS 2.0, реализации ZFS для Linux и FreeBSD"  +1 +/
Сообщение от Аноним (30), 01-Дек-20, 12:46 
Дедупликация по умолчанию отключена, для самого ARC рекомендуется выделять объём 1 Гб и выше. Если нет постоянных или больших потоков данных, используется типа а-ля десктоп, то скорее всего и со ~200Мб под ARC будет работать так же.
Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

56. "Релиз OpenZFS 2.0, реализации ZFS для Linux и FreeBSD"  +/
Сообщение от n00by (ok), 01-Дек-20, 14:25 
> Дедупликация по умолчанию отключена, для самого ARC рекомендуется выделять объём 1 Гб
> и выше.

1 Гб на каждый 1 ТБ хранилища, насколько помню. Искать ссылку лень, кому важно, тот сам эти цифры знает.

Ответить | Правка | Наверх | Cообщить модератору

66. "Релиз OpenZFS 2.0, реализации ZFS для Linux и FreeBSD"  +/
Сообщение от OpenEcho (?), 01-Дек-20, 15:24 
Пожалуйста, не говорите ерунды, если не в теме.

1Гб достаточно если без дедупликации даже на exabyte хранилище.

Почитайте не "ХауТо" блоги, а ответы на эту тему реальных разработчиков ZFS:

https://www.reddit.com/r/DataHoarder/comments/5u3385/linus_t.../

https://www.reddit.com/r/DataHoarder/comments/5u3385/linus_t.../

Ответить | Правка | Наверх | Cообщить модератору

98. "Релиз OpenZFS 2.0, реализации ZFS для Linux и FreeBSD"  –2 +/
Сообщение от Аноним (98), 01-Дек-20, 19:54 
Если без давайте без если и без. Т.е. По факту ей надо полтерабайта памяти и больше на типичное использование а ля подкроватный сервер. Как с этим у btrfs сейчас?
Ответить | Правка | Наверх | Cообщить модератору

104. "Релиз OpenZFS 2.0, реализации ZFS для Linux и FreeBSD"  –1 +/
Сообщение от OpenEcho (?), 01-Дек-20, 22:00 
> Если без давайте без если и без.

В ZFS по умолчанию выключена дедуплекация, о каких "без" не "без" разговор?

>Т.е. По факту ей надо полтерабайта памяти и больше на типичное использование а ля подкроватный сервер.

С английским проблема посмотреть ссылки приведеные выше?
1Гб памяти достаточно для любого обьема

> Как с этим у btrfs сейчас?

FYI: Поддержка btrfs была остановлена одним из главных спонсоров линукса - т.е. красношляпой

Ответить | Правка | Наверх | Cообщить модератору

113. "Релиз OpenZFS 2.0, реализации ZFS для Linux и FreeBSD"  +/
Сообщение от Аноним (98), 01-Дек-20, 23:12 
>по умолчанию выключена

Какой смысл использовать дефолт?

>1Гб памяти достаточно для любого обьема

Зачем же такая очевидная ложь? Не любого, далеко не всегда эффективно, и без дедупликации естественно.

>FYI: Поддержка btrfs была остановлена одним из главных спонсоров линукса - т.е. красношляпой

https://www.phoronix.com/scan.php?page=news_item&px=Fedora-3...

Ответить | Правка | Наверх | Cообщить модератору

149. "Релиз OpenZFS 2.0, реализации ZFS для Linux и FreeBSD"  +/
Сообщение от OpenEcho (?), 02-Дек-20, 13:40 
>Зачем же такая очевидная ложь? Не любого, далеко не всегда эффективно, и без дедупликации естественно.

А кто говорил про эффективность? Естественно, чем больше памяти, тем лучше, но если как было сказанно - подкроватный вариант, то работать будет. 100% (если руки конечно из правильного места)

И вы не бложики популярные читайте, - а оригиналы:
https://access.redhat.com/discussions/3138231

Ответить | Правка | Наверх | Cообщить модератору

163. "Релиз OpenZFS 2.0, реализации ZFS для Linux и FreeBSD"  +1 +/
Сообщение от Кир (?), 02-Дек-20, 20:12 
Наиболее заметные улучшения в Fedora 33:

    Все варианты дистрибутива для рабочего стола (Fedora Workstation, Fedora KDE и т.п.) переведены на использование по умолчанию файловой системы Btrf

Ответить | Правка | К родителю #104 | Наверх | Cообщить модератору

133. "Релиз OpenZFS 2.0, реализации ZFS для Linux и FreeBSD"  +1 +/
Сообщение от ZFS (?), 02-Дек-20, 07:04 
6TB пулы работают просто прекрасно на Core2Duo всего с двумия гигами рамы под Devuan.
Добавление SSD кэширования еще более улучшает все это.
Ответить | Правка | К родителю #98 | Наверх | Cообщить модератору

193. "Релиз OpenZFS 2.0, реализации ZFS для Linux и FreeBSD"  +1 +/
Сообщение от Аноним (-), 03-Дек-20, 11:24 
> Как с этим у btrfs сейчас?

Живет на роутере с 64 мегами. Нормально?

Ответить | Правка | К родителю #98 | Наверх | Cообщить модератору

144. "Релиз OpenZFS 2.0, реализации ZFS для Linux и FreeBSD"  +/
Сообщение от n00by (ok), 02-Дек-20, 11:04 
> Пожалуйста, не говорите ерунды, если не в теме.
> 1Гб достаточно если без дедупликации даже на exabyte хранилище.

Дословно "не должно быть массы проблем" ("would not have much trouble"). В общем, нет противоречий со средней температурой по больнице.

> Почитайте не "ХауТо" блоги, а ответы на эту тему реальных разработчиков ZFS:

Я не читал блоги до Вашей ссылки на reddit, только issues zfsonlinux.

Ответить | Правка | К родителю #66 | Наверх | Cообщить модератору

96. "Релиз OpenZFS 2.0, реализации ZFS для Linux и FreeBSD"  +2 +/
Сообщение от Аноним (96), 01-Дек-20, 19:39 
> 1 Гб на каждый 1 ТБ хранилища, насколько помню

А вы не помните, вы головой подумайте. Есть горячие данные, есть холодные. Для горячих нужен ARC, а сколько холодных, а тем более места в хранилище, ему глубочайше насрaть.

Если хранилище используется как лента, ARC вообще не нужен. Если на хранилище идёт значительная нагрузка в виде равномерно наспределённого случайного доступа, ARC имеет смысл делать либо размером в хранилище, либо вообще не делать потому что он иначе никак не поможет. Если доступ распределён неравномерно, то оптимальный размер arc может лежать где угодно в диапазоне от 0 до размера хранилища и зависит от множества факторов.

Сделай одолжение, найди свою ссылку, узнай её автора и напиши ему что он некомпетентный графоман-вредитель.

Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

99. "Релиз OpenZFS 2.0, реализации ZFS для Linux и FreeBSD"  –1 +/
Сообщение от Аноним (98), 01-Дек-20, 19:55 
А как он дедуплицировать будет?
Ответить | Правка | Наверх | Cообщить модератору

105. "Релиз OpenZFS 2.0, реализации ZFS для Linux и FreeBSD"  +/
Сообщение от OpenEcho (?), 01-Дек-20, 22:04 
> А как он дедуплицировать будет?

А зачем ??? У вас правда столько много одинаковых котиков раскиданных по всему диску чтоб экономить через дедупликацию?

Ответить | Правка | Наверх | Cообщить модератору

110. "Релиз OpenZFS 2.0, реализации ZFS для Linux и FreeBSD"  +/
Сообщение от Аноним (98), 01-Дек-20, 23:04 
Ты не поверишь сколько одинаковых котиков. Я прошёлся hardlink и освободил примерно так треть пространства, но метаданные и атрибуты были утеряны конечно и в идеале этого стоит избежать. И это ведь только абсолютно идентичные данные, а сколько их частично совпадающих? Да 2/3 оставшегося наверно.
Ответить | Правка | Наверх | Cообщить модератору

134. "Релиз OpenZFS 2.0, реализации ZFS для Linux и FreeBSD"  +/
Сообщение от ZFS (?), 02-Дек-20, 07:08 
Дедупликация бэкапов DB2 с опцией DB2 dedup позволяет добиться снижения занимаего физического пространства в количество раз, равное примерно количеству бэкапов.

Например, если у вас 1000 бэкапов, то они займут примерно в 1000 раз меньше места, ну может в 300-500 раз с поправкой на дельты и т.п.

Ответить | Правка | К родителю #105 | Наверх | Cообщить модератору

135. "Релиз OpenZFS 2.0, реализации ZFS для Linux и FreeBSD"  +/
Сообщение от ZFS (?), 02-Дек-20, 07:12 
Только потом для операций на удаление, например, снэпшотом даже при количестве рамы в 8 гиг будет уходить очень много времени. Поэтому чтобы почистить такой пул с бэкапами от старых бэкапов проще просто его дропнуть и создать новый, иначе будете его чистить неделями, если не месяцами.

При это запись и чтение работает вполне приемлемо по скорости, до тех пор пока пул не переполнится. Т.е. дедупнутые пулы OpenZFS - это как бы такие ленточки, на которые можно только писать и с которых можно читать, но не удалять. А если нужно удалить, то проще (быстрее в 1000 раз) "размагнитить" всю ленточку командой zpool destroy.

Ответить | Правка | Наверх | Cообщить модератору

150. "Релиз OpenZFS 2.0, реализации ZFS для Linux и FreeBSD"  +/
Сообщение от OpenEcho (?), 02-Дек-20, 13:50 
Я не спорю, что задачи разные бывают, но вы прочитайте пожалуйста оригинальный вопрос еще раз:
>"А можно как-то настроить ZFS для старого компа с ОЗУ 2-4ГБ? Отключить тяжелые фичи (типа дедупликации), оставив сжатие..."

Вы правда думаете что в этом случае нужна дедупликация ?

Ответить | Правка | К родителю #134 | Наверх | Cообщить модератору

176. "Релиз OpenZFS 2.0, реализации ZFS для Linux и FreeBSD"  +/
Сообщение от Аноньимъ (ok), 03-Дек-20, 00:41 
> Например, если у вас 1000 бэкапов, то они займут примерно в 1000
> раз меньше места, ну может в 300-500 раз с поправкой на
> дельты и т.п.

ZFS поддерживает инкрементальные бекапы снапшотов.

Ответить | Правка | К родителю #134 | Наверх | Cообщить модератору

194. "Релиз OpenZFS 2.0, реализации ZFS для Linux и FreeBSD"  +/
Сообщение от Аноним (-), 03-Дек-20, 11:26 
> Например, если у вас 1000 бэкапов, то они займут примерно в 1000 раз меньше места,

...но когда сыпанется под общим для них всех набором блоков, мы скажем "во бл$!"

Ответить | Правка | К родителю #134 | Наверх | Cообщить модератору

196. "Релиз OpenZFS 2.0, реализации ZFS для Linux и FreeBSD"  +/
Сообщение от Аноним (98), 03-Дек-20, 13:04 
Неправильно ты бэкапы делаешь, дядя. 1000 кратная избыточность на одном массиве это не правильно.
Ответить | Правка | Наверх | Cообщить модератору

145. "Релиз OpenZFS 2.0, реализации ZFS для Linux и FreeBSD"  +/
Сообщение от n00by (ok), 02-Дек-20, 11:05 
>> 1 Гб на каждый 1 ТБ хранилища, насколько помню
> А вы не помните, вы головой подумайте.

Над чем? Есть вопрос пользователя. Похоже, его запугало мнение экспертов, что ZFS съедает всю память и даже косточки не выплёвывает.

> Есть горячие данные, есть холодные.
> Для горячих нужен ARC, а сколько холодных, а тем более места
> в хранилище, ему глубочайше насрaть.

Вот только часть:

     * The hash table is big enough to fill all of physical memory
     * with an average block size of zfs_arc_average_blocksize (default 8K).
     * By default, the table will take up
     * totalmem * sizeof(void*) / 8K (1MB per GB with 8-byte pointers).

https://github.com/openzfs/zfs/blob/zfs-2.0-release/module/z...

> Если хранилище используется как лента, ARC вообще не нужен. Если на хранилище
> идёт значительная нагрузка в виде равномерно наспределённого случайного доступа, ARC имеет
> смысл делать либо размером в хранилище, либо вообще не делать потому
> что он иначе никак не поможет. Если доступ распределён неравномерно, то
> оптимальный размер arc может лежать где угодно в диапазоне от 0
> до размера хранилища и зависит от множества факторов.

*    This is the easy case; all clean data contained by the mru and mfu
*    lists is evictable. Evicting all clean data can only drop arc_size
*    to the amount of dirty data, which is greater than arc_c_min.

> Сделай одолжение, найди свою ссылку, узнай её автора и напиши ему что
> он некомпетентный графоман-вредитель.

Простите, но с такой целью я только вот что могу найти, а с авторами сами разбирайтесь:

В настоящее время минимальный объем памяти, рекомендуемый для установки
системы Solaris, составляет 768 МБ. Однако для обеспечения высокой
производительности ZFS рекомендуется по крайней мере 1 ГБ памяти или более.

Ответить | Правка | К родителю #96 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру