ZFS на 4GB RAM

такие не умеют делать снапшоты

а зачем ей самой это делать? закинь сам в крон и норм

такие не умеют делать снапшоты.

Они делаются автоматически :)

например на ufs в зависимости от заполненности данных сделать снапшот занимает очень много времени и в этот момент io повисает полностью.

пытаются протолкнуть эту свою ZFS куда-угодно, под любым предлогом..

И 632734 раз закинул старик невод... Следи за руками, я предлагаю всем ZFS потому, что подавляющее большинство десктопов, не говоря уже о серверах, имеют на борту более чем достаточные объём памяти и производительность.
ТС запросто может использовать ZFS для хранения порнухи, работать будет также быстро, как на классической ФС, а вот потерять данные шансов значительно меньше.

P.S. Фрактал доставил ), отправил в игнор, вот это бомбануло ))

P.S. Снапшоты надо будет все-равно удалять рано или поздно, а пропажа «папки» может обнаружиться значительно позже

P.S. Снапшоты надо будет все-равно удалять рано или поздно, а пропажа «папки» может обнаружиться значительно позже

«It is recommended to have 1-2 GB of RAM per TB of disk for good performance.»

ОК. Посчитаем 1,5 GB на 1 TB. Итого 2,25 GB на 1,5 TB. Откусим для ОС 0,5 ГБ. Остается 1,25 ГБ.

If you plan to use ZFS deduplication, a general rule of thumb is 5 GB RAM per TB of storage to be deduplicated.

А это некорректно. Результат сильно зависит от данных. Расчет я уже приводил выше. Если в этом есть сомнения, то советую посмотреть достоверную информацию от Oracle. Произведем расчет. На 1,5 TB приходится ~ 11,7 млн блоков объемом 128 килобайт каждый. 11,7e+06 *320= 3,744e+9 байт= 3,744 ГБайт. Расчет ОЗУ произведен для полностью заполненного жесткого диска (лучше не превышать 80% заполнение). ТС может безболезненно расчитывать на дедупликацию 1,25/3,744 * 1,5 TB = 0,5TB данных. Если использовать размер блока в 1 Мегабайт, то у ТС уйдет лишь 470 MB памяти на 1,5 TB дискового пространства. Сбалансированный вариант - блок на 256 КБ.

Начитался о преимуществах ZFS,

Они есть, но что из них ты будешь реально использовать?

Даже одного только контроля целостности данных с помощью контрольных сумм достаточно, чтобы сделать выбор в пользу ZFS.

У меня вообще десктоп на 4 гигах с zfs, всё нормально. Дедупликацию только не включай.

Только польза от этого на одном диске стремится к нулю. Как и без ecc памяти.

У меня вообще десктоп на 4 гигах с zfs, всё нормально. Дедупликацию только не включай.

А какое отношение это имеет к линуксу?

Даже одного только контроля целостности данных с помощью контрольных сумм достаточно, чтобы сделать выбор в пользу ZFS.

Когда уже бздуны убирутся на свой форум и не будут засирать все шо видят своими сектантскими бреднями?

Какое отношение эта ваша сраная ZFS имеет к линуксу?

Лучше б 802.11n наконец-то доделали, чтоб хоть на атеросах работало, а то стандарт устареет, пока вы тут непонятное чудовище пиарите, школьникам мозги неокрепшие загаживаете.

Знатно бомбит у красноглазой школоты. Да только ради такого цирка уже можно оставаться.

Знатно бомбит у красноглазой школоты. Да только ради такого цирка уже можно оставаться.

Школота как раз вот эту вот загадочную потустороннюю фигню под названием ZFS обсуждает, ибо никогда в реальности не сталкивалась, а времени свободного дофига, скучно и фантазии мучают.

А в действительности бздуны навязчивым пиаром своей застрявшей в прошлом колесницы порядком надоели. Лезут из всех дырок, как глисты. Хотя какой смысл ее пиарить, если у нее три калеки поклонника и те скоро вымрут по возрасту? Ибо размножаться по понятным причинам не могут.

Какое отношение эта ваша сраная ZFS имеет к линуксу?

Прямое http://zfsonlinux.org/

Прямое http://zfsonlinux.org/

Маргиналы и дураки присутствуют в любом виде деятельности.

Какое отношение эта ваша сраная ZFS имеет к линуксу? Ибо даже не бздуны ее придумали, они ее украли у Solaris, которая создала ее для очень специфических задач на специфическом оборудовании, а теперь пиарят ее как свое большое достижение.

Какое отношение эта ваша сраная ZFS имеет к линуксу?

Я тебе выше ответил уже )) ZFS на linux отлично работает.

Я тебе выше ответил уже )) ZFS на linux отлично работает.

NTFS тоже отлично работает.Будем ставить линукс на NTFS? Зачем тянуть всякое дерьмо?

Доставило с рач wiki:

ZFS is using too much RAM

By default, ZFS caches file operations (ARC) using up to two-thirds of available system memory on the host. Remember, ZFS is designed for enterprise class storage systems! To adjust the ARC size, add the following to the Kernel parameters list:

zfs.zfs_arc_max=536870912 # (for 512MB)

То есть, по умолчание это сумрачное чудовище отжирает две трети любого размера оперативки.

Какое отношение эта ваша сраная ZFS имеет к линукс?

То есть, по умолчание это сумрачное чудовище отжирает две трети любого размера оперативки.

Ты всегда используешь настройки по умолчанию? А говоришь не школота.

То есть, по умолчание это сумрачное чудовище отжирает две трети любого размера оперативки.

Ну и что? Сделай не по умолчанию.

Ты всегда используешь настройки по умолчанию? А говоришь не школота.

Я пользуюсь подходящими инструментами для решения конкретных целей.

А ты разговор в сторону не уводи — какое отношение эта ваша сраная ZFS имеет к линуксу?

И почему не обсуждать это на профильных форумах? Там больше информации, там единомышленники, там не будут посылать.

Или с языками проблема как всегда?

А ты разговор в сторону не уводи — какое отношение эта ваша сраная ZFS имеет к линуксу?

Ты тупой?

Я пользуюсь подходящими инструментами для решения конкретных целей.

А zfs и есть подходящий инструмент, только, как и любой другой, его надо настраивать под задачи.

А ты разговор в сторону не уводи — какое отношение эта ваша сраная ZFS имеет к линуксу?

Тебе уже дали ссылку на ядрёный модуль, болезный.

И почему не обсуждать это на профильных форумах? Там больше информации, там единомышленники, там не будут посылать.

Я и так там это обсуждаю. А opensource.ru тебе ни о чём не говорит?

Я и так там это обсуждаю. А opensource.ru тебе ни о чём не говорит?

Привычка говорить загадками — дурной тон и плохое, некачественное воспитание и образование.

opensource.ru — ну выкупили хозяева linux.org.ru доменное имя, ну включили перенаправление на linux.org.ru. И шо? Типично жлобское поведение под какие-то туманные планы.

На сегодня в разделе «О сервере» написано:

О Проекте

Некоммерческий проект «LINUX.ORG.RU: Русская информация об ОС Linux» был основан в октябре 1998 года. Нашей целью является создание основного информационного ресурса об операционной системе Linux в России. Мы стараемся обеспечить возможность обмена различной Linux-ориентированной информацией, последними новостями, ссылками, документацией и другими ресурсами.

Итак, какое отношение эта ваша сраная ZFS имеет к линуксу?

Если использовать размер блока в 1 Мегабайт

А если 100mb - то 4,7

А это некорректно. Результат сильно зависит от данных.

Конечно некорректно, ты же не потрудился ссылку открыть, да?

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

на zfs шанс потери данных меньше, чем на ext ?

на zfs шанс потери данных меньше, чем на ext ?

Имел ввиду контроль целостности данных с помощью контрольных сумм.

А если 100mb - то 4,7

Для ZFS максимальный размер блока 1 мегабайт.

Конечно некорректно, ты же не потрудился ссылку открыть, да?

Если некорректно и ты сам с этим согласился, то чего пишешь чушь? Я с материалом ознакомлен, привел расчет. А ты язык распустил - и только. Говорить ведь - не мешки ворочать!

Ты написал херню, твой расчет из размера блока 1mb, тогда как блок динамический, и ты сам пишешь о том, что усреднение в 256k более близко к реальности.

Твои рассуждения можно было бы закончить в месте, где для диска требуется 3.7GB только для хранения таблицы совпадений. При имеющихся у автора 4GB. Тогда как есть еще кэш самой zfs без которой оно будет нещадно тормозить и нужды системы и приложений.


Сам же говоришь «зависит от данных» и сам же приводишь расчет основываясь на сферических данных в вакууме. Тем временем автор утверждения «5GB/TB» проделал ровно то же самое и объяснил что-куда отнюдь не в короткой статье -

constant@walkuere:~$ zdb -b oracle

Traversing all blocks to verify nothing leaked ...

No leaks (block sum matches space maps exactly)

bp count: 306575
SPA allocated: 17891765760 used: 52.48%
The number to look for here is bp count which is the number of block pointers, hence the number of blocks in the pool.

In this example, the dedup table would take up 306575 blocks * 320 bytes, which yields around 100 MB. This file system has a size of 32GB, so we can assume that the dedup table can only grow to about 200 MB, since it's about 50% full now.

И если ты теоретик - то я практик, и результат включения дедупликации 3TB массива raidz с 16GB озу знаю на себе

Тогда как есть еще кэш самой zfs без которой оно будет нещадно тормозить и нужды системы и приложений.

Эк тебя прорвало. Спокойнее. Эти данные учтены. Для тех, кто умеет только писать, нашишу второй раз (1,5* 1,5= 2,25 ГБ на ZFS + 0,5 ГБ на ОС). На дедупликацию остается 1,25 ГБ.

и ты сам пишешь о том, что усреднение в 256k более близко к реальности.

Вовсе нет. Это рекомендуемый для ТС размер блока на основании расчетов.

еИ если ты теоретик - то я практик, и результат включения дедупликации 3TB массива raidz с 16GB озу знаю на себе

Где твое техническое задание? Рассуждай и дальше о сферическом коне в вакууме на основании «бабка сказала». Так что вы не практик, а лох.

P.S. для тех, кто в бронепоезде, размер блока по умолчанию 128KB (макс). Опция называется recordsize.

а лох.

Вот теперь правильные аргументы пошли.

Платон мне друг, но истина дороже. А за то извини, конечно.

Сказки Венского леса в другой опере.

Потрясающе аргументированный ответ. Что же именно здесь сказки венского леса? И чего это некоторые пользователи Линукс пытаются разбираться тут с неведомыми ошибками в архивах данных?

А те, кто не в бронепоезде, о существовании более новых версий солярки и более актуальной документации догадываются? Или обязательно надо носом ткнуть?

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

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

А индусы то чем тебя обидели? Что за нацпол тут развести пытаешься? Или ты под веществами и «так видишь»?

vxz шел бы ты лесом, можно Венским, с тобой мне вообще не о чем говорить.

Вот уже и галлюцинации начались :)

Безопасно ли юзать ZFS на 4-х гигах

безопасность-то причем? работать будет.

короче о дедупликации стоит забыть

100%

Что же именно здесь сказки венского леса?

То, что с одним диском никакого self-healing не будет. Но, после фразы про индусов, появилось подозрение, что он в это вообще не верит.

Это не маркетинговый бред, оно реально работает. Другое дело, что для self-healing надо зеркало или чётность.

Да верю, верю, просто носитесь со «сквозным контролем данных» как с писанной торбой.

То, что с одним диском никакого self-healing не будет. Но, после фразы про индусов, появилось подозрение, что он в это вообще не верит.

Кто сказал не будет? Copies никто не отменял, так что по умолчанию как минимум для метаданных будет, а ведь можно и для данных включить. Понятно дело, что если диск умрет, то копии не помогут, но у KRoN73 вроде диски не умирают, а данные повреждаются.

Копии на одном диске, что мёртвому припарки :)

Копии на одном диске, что мёртвому припарки :)

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

Безопасно.

Я извиняюсь, но как обрабатывается ситуация когда сама контрольная сумма при записи на диск исказилась?

ситуация когда сама контрольная сумма при записи на диск исказилась?

Какова вероятность этого явления? Для полной гарантии могу предложить использовать память с ECC.