The OpenNET Project / Index page

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



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

Оглавление

Состояние развития ZFSonLinux и готовность проекта к повсеме..., opennews (?), 11-Сен-14, (0) [смотреть все]

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


24. "Состояние развития ZFSonLinux и готовность проекта к повсеме..."  –1 +/
Сообщение от Аноним (-), 12-Сен-14, 03:56 
>Увы, но будущее за  Btrfs...

Сколько у тебя свободного места на диске? Ах, btrfs не может это показать...

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

34. "Состояние развития ZFSonLinux и готовность проекта к повсеме..."  +/
Сообщение от Аноним (-), 12-Сен-14, 08:10 
> Сколько у тебя свободного места на диске? Ах, btrfs не может это показать...

Что достаточно логично для CoW с автоснапшотами, в котором свободное место - понятие относительное. Потому что объем свободного места зависит еще и от снапшотов и того готовы ли вы ждать пока например GC попашет. Можно запросто сделать так что на ФС без единого файла не будет места - все займут прошлые состояния и отличие от них. При этом вы не сможете ничего записывать в текущее состояние. Зато у вас будет 100500 прошлых состояний на выбор по которым можно шариться. Это не баг и не фича. Просто особенность технологии.

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

54. "Состояние развития ZFSonLinux и готовность проекта к повсеме..."  +5 +/
Сообщение от Нанобот (ok), 12-Сен-14, 09:59 
нехилая такая фича. обычный юзер не может просто так взять и узнать, поместится у него фильм на диске или нет. я б на месте юзера закопал бы такую систему вместе со всеми её такими небагами
Ответить | Правка | Наверх | Cообщить модератору

72. "Состояние развития ZFSonLinux и готовность проекта к повсеме..."  +/
Сообщение от Аноним (-), 12-Сен-14, 13:31 
Обычные юзеры сидят на ext4 и не пищат.
Ответить | Правка | Наверх | Cообщить модератору

87. "Состояние развития ZFSonLinux и готовность проекта к повсеме..."  +/
Сообщение от Аноним (-), 12-Сен-14, 18:54 
> нехилая такая фича. обычный юзер не может просто так взять и узнать,
> поместится у него фильм на диске или нет.

Если у тебя использование ФС завалилось в такой сценарий - держись от CoW подальше, ибо если ты CoW забьешь на 100% - там будет столько фрагментов-выносков распиханых в вермишель по всему диску, что потом даже дефрагер будет неделю эту жесть фиксить. Это отличный прострел своей пятки. Так что если у тебя такие сомнения вообще есть - лучше не юзай CoW-based FS для твоего же блага.

Тут один кадр aka iZEN завалил свой мегапул из 3 дисков с ZFS до состояния, когда скорость 20 мег на пул из 3 винчей. То-есть, ~6-7Мб/сек на шпиндель. При линейной скорости чтения ну уж никак не менее 50, даже у самого ушатанного ноутбучного винча. И это на более-менее большом линейном файле, он как раз на примере мувика показывал, IIRC. А вот пролечить такую ...опу в ZFS - а это вообще как? Удвинуть все данные руками куда-то еще на другие ФС, поудалять данные и снапшоты, потом заново перекопировать? Или просто пересобрать пул с ноля, что примерно одно и то же по смыслу? Ну да, очень удобно, блин.

> я б на месте юзера закoпал бы такую систему вместе со всеми её такими небагами

Забивать даже классическую файлуху близко к 100% занятие субоптимальное, а CoW - субоптимальное вдвойне. А так df тебе какую-то цифирь вернет. Как и сисколы. Только эта цифирь - не то чтобы окончательная. Потому что попахав GC'ом - можно отобрать еще места. Только заранее неизвестно сколько - для этого GC должен пойти и посмотреть что можно отжать. Это долго. На каждый запрос "сколько места" не подергаешь.

А на месте юзера - да закaпывай. Только вот если я случайно диру на btrfs снесу по ошибке, или того хуже, перезапишу вон тот файл старой версией, например - ну, в btrfs я достану снапшот и переиграю. А на обычной ФС - будешь драть волосы на всех частях тела с досады.

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

96. "Состояние развития ZFSonLinux и готовность проекта к повсеме..."  +/
Сообщение от iZEN (ok), 12-Сен-14, 20:20 
Тормознутость ZFS тогда пролечилась несколькими командами отключающими свойство дедупликации у всех ФС этого пула. Почему ты это старательно замалчиваешь, я не возьму в толк.

Другая опа случилась при апгрейде ZFS пулов после обновления системы: просто они были заполнены на 99% и не хватило места для новых метаданных - ФС перешли в состояние read only. Но, опять же, и эта проблема решилась удалением некритичных файлов.

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

113. "Состояние развития ZFSonLinux и готовность проекта к повсеме..."  +/
Сообщение от Аноним (-), 13-Сен-14, 03:01 
> Тормознутость ZFS тогда пролечилась несколькими командами отключающими свойство
> дедупликации у всех ФС этого пула.

1) Не понимаю как дедупликация может влиять на скорость чтения. Ну запись еще понятно, но у тебя ж вроде и чтение было в такой же лузе? Чтобы осознать насколько это луза: ARMовская платка с гигагерцевым процом и гигом оперативы с EXT4 читает с одного ноутбучного диска 90Мб/сек. Ну правда диск терабайтник и 7200RPM (да, такое нынче в 2.5" упаковывают).

> Почему ты это старательно замалчиваешь, я не возьму в толк.

Не помню чтобы ты показывал новые данные.

> Другая опа случилась при апгрейде ZFS пулов после обновления системы: просто они
> были заполнены на 99% и не хватило места для новых метаданных

Ну ты напрасно так с CoW - он тебе выносков нагородит и файлы по мере дозаписи/перезаписи превратятся в вермишель, равномерно размазанную по всему диску, на механике это будет означать отвратную скорость последовательного чтения. При том у ZFS дефрагера IIRC вообще совсем нет и undo этого безобразия можно сделать только стерев большинство файлов в надежде что свободное место придет в менее вермишельный вид. Только для эффективности этого деяния надо почти все файлы снести, что по смыслу близко к пересозданию пула с ноля.

> - ФС перешли в состояние read only. Но, опять же, и
> эта проблема решилась удалением некритичных файлов.

Да проблема CoW не в том, а в выносках с отличиями от предыдущего варианта. Если с местом душняк - даже обычная ФС будет распихивать файлы не "как лучше" а "как получится", постепенно превращаясь в мелкую вермишель. А CoW из-за своей природы количество фрагментов будет плодить еще быстрее. Саночники судя по их FAQам явно в курсе проблемы, раз советуют добавлять диск в пул при занятости в 80%. Что забавнее - они кажется не имеют плана действий на случай если это все-таки случилось. А в долговременном плане количество фрагментов все-таки будет увеличиваться и скорость работы ФС может деградировать.

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

97. "Состояние развития ZFSonLinux и готовность проекта к повсеме..."  +/
Сообщение от iZEN (ok), 12-Сен-14, 20:27 

> Забивать даже классическую файлуху близко к 100% занятие субоптимальное, а CoW -
> субоптимальное вдвойне. А так df тебе какую-то цифирь вернет. Как и
> сисколы. Только эта цифирь - не то чтобы окончательная. Потому что
> попахав GC'ом - можно отобрать еще места. Только заранее неизвестно сколько
> - для этого GC должен пойти и посмотреть что можно отжать.
> Это долго. На каждый запрос "сколько места" не подергаешь.

Ну и бредятина эта ваша  Btrfs с невнятным GC, который ещё  нужно ждать, пока разрешится от родов свободного места. df на ZFS амнезией не страдает.

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

114. "Состояние развития ZFSonLinux и готовность проекта к повсеме..."  +/
Сообщение от Аноним (-), 13-Сен-14, 03:17 
> Ну и бредятина эта ваша  Btrfs с невнятным GC, который ещё
>  нужно ждать, пока разрешится от родов свободного места.

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

При этом с логической точки зрения не совсем понятно что надо показать как "доступное место вообще". Можно показать суммарное свободное место по девайсам, но если ты например зеркалишь - тогда влезет в 2 раза меньше. И даже не в 2. А "когда у файловой системы закончатся возможности класть блоки на 2 физически разных девайса". Круть и гибкость в управлении RAIDовыми уровнями имеет некие странноватые tradeoff.

Еще сжатие есть. Заранее неизвестно насколько твои данные сожмутся. Поэтому если ты думаешь что вон та цифирь в ФС со сжатием - окончательная величина, ХРЕН ТЕБЕ, золотая рыбка.

> df на ZFS амнезией не страдает.

Ну так df на btrfs тоже нечто покажет. Просто это нечто - сферическое и в вакууме. И зависит от многих "если". Что интереснее, это можно сказать и про иные ФС, например, свободное место - очень условная величина, если ФС умеет сжатие. В том плане что сколько по факту влезет != тому что эта цифирь показывает.

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

110. "Состояние развития ZFSonLinux и готовность проекта к повсеме..."  –1 +/
Сообщение от freehckemail (ok), 12-Сен-14, 23:20 
> нехилая такая фича. обычный юзер не может просто так взять и узнать, поместится у него фильм на диске или нет. я б на месте юзера закопал бы такую систему вместе со всеми её такими небагами

Кгхм. Я, вообще говоря, в возможностях btrfs и zsh не шарю вообще. Но Вы, очевидно, напрасно считаете, будто узнать остаток места на диске возможно на обычных файловых системах типа ext.
Это же классика системного администрирования: спросить у собеседуемого, почему вывод команд du и df отличается...

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

35. "Состояние развития ZFSonLinux и готовность проекта к повсеме..."  +/
Сообщение от admin (??), 12-Сен-14, 08:17 
Здравствуйте админ локалхоста. btrfs filesystem df /
Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

37. "Состояние развития ZFSonLinux и готовность проекта к повсеме..."  +/
Сообщение от Аноним (-), 12-Сен-14, 08:20 
> Здравствуйте админ локалхоста. btrfs filesystem df /

Он наверное про то что показывает обычный df и соотв. сисколы. Ну... ээ... понимаете, там же тоже надо показывать что-то. И там нет места для вербозного показа что и где - ожидается какая-то одна цифирь.

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

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

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




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

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