Отпечатай - btrfs впечатления

Не знам, за колко критични приложения става въпрос, но досега не съм констатирал проблеми с нея. Ползвал съм файловата система с ядра от 3.16 до 4.1. И, не знам, колко е преждевременна поддръжката в ядрото, като това си е официална файлова система за Linux, поддържана от поне три големи корпорации, едната от които е Red Hat. А, най- голямата издънка за годината - загубата на данни в RAID масиви беше констатирана при ext4, която определено не е нова. Изглежда, принципът "никога не е късно да се издъниш", важи и при софтуера.

Поне с Oracle XE 11 има проблеми.
Или поне в констелациите, в които я ползвахме на работа. Като цяло доста по-ниска производителност отколкото под ext4. За други цели не сме я ползвали за момента (нормални работни станции за писане на Java код). Честно нямах време да седна да направя сериозно сравнение, защо и какво може да се направи за да се промени поведението. Иначе ми е интересно и на мене какво може да се постигне с нея.
По едно време я ползвахме за on-the-fly mirroring на голяма MySQL база данни между 2 географски разделени места, но дали още се прави не знам (там работеше безотказно).

Ами, нормално е на показва понижена производителност. Ядро 3.13 не само, че е старо, но изобщо не трябваше да го вкарват в LTS версията при излязло 3.14. Сложете поне 3.19 от официалните хранилища на trusty, въпреки, че значително подобрение на работоспособността под btrfs и xfs има след версия 4.0.

Не е толкова лесно, една камара плъгини зависят от версията на ядрото. Иначе имаше и >3.13, но като цяло беше по-лесно да сменим ФС-а отколкото ядрата на засегнатите машини. Като тръгнем да мъдрим новата версия на "дистрото" дето ползваме, ще накарам някой програмист да тества на бтрфс, така за пробата :)

Като цяло, както казах за он-дъ-флай мироринга си беше копче, а и никой програмист не се оплака от други проблеми освен ДБ-то (а то тука може и самите оракъл да са се "постарали" малко или много).

Ще ми е интересно да разбера как се държи при спиране на тока например. Иначе принципно ме вълнува за файлов сървър. Нещата започнаха от shadow_copy в самбата и previous version на файловете в бозата. Като се разрових се оказа, че нещата работят само с zfs и btrfs+snapper. Понеже тогава снапъра беше експериментален и го нямаше още в самбата се хванах с freebsd и зарязах линукса. Сега гледам, че нещата вече са в Самба4.2 и единственият проблемен компонент (по-скоро компанент от който нямам никакви впечатления) е btrfs. Принципно freebsd ми е по-добър вариант, но има хора които се плашат и предпочитат да си стоят на линукс. Та за това разпитвам. Да не метнем док-овете на някоя фирма и после да ни гонят да ни бият :)))

Цитат на: growchie в Aug 20, 2015, 20:18

Принципно freebsd ми е по-добър вариант, но има хора които се плашат и предпочитат да си стоят на линукс.

А, има и хора, който предпочитат Linux, без да се плашат от BSD. Все пак, и BSD дели петте процента при сървърните машини, заедно с още няколко други OS. 95 процента от сървърите са под Linux. И, ако десктоп потребител може да се излъже от лъскав десктоп, при производителните машини случайност няма. Там, всичко е въпрос на внимателна преценка.

Едно време задавах същите въпроси само че за ext4
http://www.linux-bg.org/forum/index.php?topic=40089.0

Та тогава четох някакви изследвания че въпреки всичко все пак риска от загуба на информация при ext3 е бил мъничко по малък в сравнение с ехт4 (не става дума за бъговете които явно отдавна са изчистени)

А за btrfs как може да се направи пълен журнал (и на данните, не само на мета датата) по подобие на ext3/4 монтиране с опция data=journal
(ликуксите не идват по default по този начин монтирани, защото това прави системата забележително по бавна. И ако искате журнал и на данните трябва допълнително да се зададе data=journal)

Защото според мен това е най важното за сигурност на данните при неправилно изключване.

Цитат на: cybercop в Aug 20, 2015, 21:24

Цитат на: growchie в Aug 20, 2015, 20:18
Принципно freebsd ми е по-добър вариант, но има хора които се плашат и предпочитат да си стоят на линукс.
А, има и хора, който предпочитат Linux, без да се плашат от BSD. Все пак, и BSD дели петте процента при сървърните машини, заедно с още няколко други OS. 95 процента от сървърите са под Linux. И, ако десктоп потребител може да се излъже от лъскав десктоп, при производителните машини случайност няма. Там, всичко е въпрос на внимателна преценка.

Ми нямаш простотията да правиш конф фйлове за генерирането на конф файлове (визирам GRUB2), системата се настройва само в един файл (rc.conf) вместо в resolv.conf, hosts, мрежовите настройки, настройките на рънлевълите. Бутал съм само в 2 файла системни за да настроя машината - loader.conf за модулите на ядрото и rc.conf за всичко останало. Останах възхитен как може да е толкова просто и същевременно толкова гъвкаво.
Ако няма да търсиш хостинг извън офиса и разполагаш с железата, има решения с freebsd с които нещата стават обидно лесно чак. Визирам freenas и pfsense. При мен freenas не ставаше, защото трябваше освен samba да подкарам и DB сървър. Наистина за сега не съм видял нещо, ако изключим пощата, което да става по-лесно на линукс от колкото на фрибсд или линукс решението да има някакво огромно предимство.

https://www.kernel.org/doc/Documentation/filesystems/ext4.txt
https://www.kernel.org/doc/Documentation/filesystems/btrfs.txt
Тук пише, че commit интервала е 5сек при ext3/4 и 30сек при btrfs!

Което означава че при default стойностите btrfs е много по несигурна при неправилно изключване. но може да я монтираш с commit=5 и да стане като ext3/4

Цитат

commit=<seconds>
Set the interval of periodic commit, 30 seconds by default. Higher
values defer data being synced to permanent storage with obvious
consequences when the system crashes. The upper bound is not forced, but a warning is printed if it's more than 300 seconds (5 minutes).

Цитат на: growchie в Aug 21, 2015, 09:28

Ми нямаш простотията да правиш конф фйлове за генерирането на конф файлове (визирам GRUB2), системата се настройва само в един файл (rc.conf) вместо в resolv.conf, hosts, мрежовите настройки, настройките на рънлевълите. Бутал съм само в 2 файла системни за да настроя машината - loader.conf за модулите на ядрото и rc.conf за всичко останало. Останах възхитен как може да е толкова просто и същевременно толкова гъвкаво.

Ами хубаво. Настройваш си системата за час и я ползваш, примерно 10 години за CENTOS. Изобщо не ме бърка, че, примерно etc/hostname и etc/default/grub са отделни файлове. Предполага се, че тези настройки се правят от хора, които знаят, какво правят. За останалите има шарения и не се налага да ровичкат в системните файлове.

Цитат на: cybercop в Aug 21, 2015, 11:19

Ами хубаво. Настройваш си системата за час и я ползваш, примерно 10 години за CENTOS.

Ето точно това нещо ме разби във FreeBSD-то. Дойдох сутринта с идеята че ще ми отиде доста време за инсталация и настройка, а вече на 5-тата минута слагах самбата и приключвах.
А имаше години, когато и линукса се инсталираше за минути, но това става вече като оффтопик дискусия.

Хайде и аз off.
Много му се бях наточил на това Gentoo. Ама нещо на виртуалката не успях да го пусна. Погледнах като за начало към Sabayon - нъцки. Това изобщо не иска да стартира. Не пишат и не отговарят, защо, въпреки въпросите ми във фирума им. Погледнах и нещо наречено Funtoo или нещо подобно, производно от Gentoo, ама не го схванах, как да го инсталирам.
А много искам да се откажа от Ubuntu-Debian чаветата, ама ....
Освен да пробвам и аз FreeBSD

И аз да се изкажа.....
// offtopic <- щото съм примерен съфорумник и си чета правилата на форума.
// offtopic <- още един таг за по сигурно

Като гледам какви почнаха да ги правят RH и какви работи вмъкват, сериозно почнах да се оглеждам .... може би freeBSD

Ами то не са Нетворк Менагери....СистемД-та...нови имена на устройствата... какво им беше лошото на eth0...А все повече конфиг файлове биват пренаписвани от някой си демон или програма....Иди че се оправи. Направо ми се изправят косите като отворя някой известен конфиг файл и отгоре се мъдри съобщението "Do not edit this file" :o

Та последната хубава и стандартна сърверна дистрибуция е Центос 5 сериите. Шестицата изненадва с Нетворк Менагери. А пък за 7миците да не говорим.

Цитат на: Naka в Aug 22, 2015, 10:37

И аз да се изкажа.....
// offtopic <- щото съм примерен съфорумник и си чета правилата на форума.
// offtopic <- още един таг за по сигурно

Като гледам какви почнаха да ги правят RH и какви работи вмъкват, сериозно почнах да се оглеждам .... може би freeBSD

Ами то не са Нетворк Менагери....СистемД-та...нови имена на устройствата... какво им беше лошото на eth0...А все повече конфиг файлове биват пренаписвани от някой си демон или програма....Иди че се оправи. Направо ми се изправят косите като отворя някой известен конфиг файл и отгоре се мъдри съобщението "Do not edit this file" :o

Та последната хубава и стандартна сърверна дистрибуция е Центос 5 сериите. Шестицата изненадва с Нетворк Менагери. А пък за 7миците да не говорим.

→ ⑤
→ ⑤
→ ⑤

:D

А-а-а, аз от кога ги разправям тези, ще дойдете на моята [_]3

Цитат

Много му се бях наточил на това Gentoo. Ама нещо на виртуалката не успях да го пусна. Погледнах като за начало към Sabayon - нъцки. Това изобщо не иска да стартира. Не пишат и не отговарят, защо, въпреки въпросите ми във фирума им. Погледнах и нещо наречено Funtoo или нещо подобно, производно от Gentoo, ама не го схванах, как да го инсталирам.

питай РОКО за техния Калкулэйт :)

иначе, що не пробваш Slackware?

Цитат на: lunarvalley в Aug 22, 2015, 15:51

няма да се чудим вече :P

то и аз съм от десетина година на Slackware, ма не ми е чак елементарен...

Ми в слака предполагам, че нямате едни eselect, package.use, revdep-rebuild и за капак един make.conf да се тревожите :) И perl-cleaner е влизал в употреба... Това да си на ролинг ъпдейт с контол на дипендънсито си има предимства ама си има и недостатъците. Бе малко за мазохисти е Gentoo.

Цитат на: growchie в Aug 24, 2015, 09:20

Явно скоро ще имаме още една опция за избор.

"Скоро" в света на файловите ситеми, означава, поне две години. До тогава, btrfs, вероятно ще стане файлова система по подразбиране в повечето дистрибуции. След още една - две години, когато се развие достатъчно новата файлова система, ще почнат нови дискусии "Заслужава ли си да преминавам от btrfs на файлова система X". В света на софтуера, този цикъл се повтаря през няколко години. Същото се случи при преминаването от ext3 към ext4.

Цитат на: cybercop в Aug 24, 2015, 09:54

До тогава, btrfs, вероятно ще стане файлова система по подразбиране в повечето дистрибуции. След още една - две години, когато се развие достатъчно новата файлова система, ще почнат нови дискусии "Заслужава ли си да преминавам от btrfs на файлова система X".

Не разчитай на това, XFS може би, аз лично не бих мръднал от ext4 и в момента XFS дава най-добри показатели, като гледам тестове в фороникс-а :)

Цитат на: cybercop в Aug 24, 2015, 09:54

"Скоро" в света на файловите ситеми, означава, поне две години. До тогава, btrfs, вероятно ще стане файлова система по подразбиране в повечето дистрибуции. След още една - две години, когато се развие достатъчно новата файлова система, ще почнат нови дискусии "Заслужава ли си да преминавам от btrfs на файлова система X". В света на софтуера, този цикъл се повтаря през няколко години. Същото се случи при преминаването от ext3 към ext4.

И след доста години, като мине модата и като се позабравят пак ще почнат да се връщат назад към неща подобни на ext3/ext4 или някоя стара система. Колелото се завърта. Всичко ново е добре забравено старо.

Цитат на: bvbfan в Aug 24, 2015, 10:29

Аз от години съм си монторал дялове ext3 с 4-ката, не правя тестове, но не виждам и смисъл като скоростта на четене и запис ме задоволява.

На мен ми се струва, че старите системи с 2.2-2.32 ядра върху ext3 бяха с по- голяма производителност и по- бързи от сегашните с ядро 4.ХХ, независимо с коя файлова система. Но, отчитам, че приложенията вече са по- ресурсоемки и проблемът, вероятно идва от тях.

На мен много ми хареса Ahinora-та 32-битова. Пуснах live-DVD на една стара десктоп машина. Зареди системата учудващо бързо за мен. На по-старата ми машина, ползвана за теста, естествено си тръгнаха всички хардуери. А софтуера - и офиса, и лисицата, и звуци, и мрежа, и графиката си заработиха нормално. Нямаше никакви кахъри при работата (макар и само тестова). Помъчих се малко, да добавя един споделен в локалната мрежа лазерен принтер, ама явно нямах нерви и не го мъчих много. Само нямах свободен стар хард диск, да инсталирам на него операционната система.

После погледнах на страницата на проекта и кого да видя в екипа разработчици ? Браво за труда и старанието, много ми хареса СтотинкаОС.

Някой, може ли да ми обясни, следната разлика в работата на система, инсталирана върху ext4 файлова система и, такава, инсталирана върху btrfs или XFS.
И в двата случая, системите натрупват кеширани данни в рамките на сесията. Но, при системите, инсталирани върху EXT4, буферираните данни нарастват (често над два пъти), докато при XFS/btrfs са винаги постоянна величина. На какво може да се дължи това. На липса на натрупване на буфер или на триене на старите данни, когато се записват нова, което е причина общият им обем да е постоянна величина.
Благодаря предварително за отговорите !

Ако визираш page cache-a (disk cache), то при Линукс е той е независим от файловата система и съответно не би трябвало да има никаква разлика в поведението му при ext4/xfs/btrs. Ако ставаше въпрос за ZFS там е различно, но при въпросните файлови системи наистина не би трябвало да има никаква разлика.

Цитат на: d0ni в Aug 29, 2015, 22:09

Ако визираш page cache-a (disk cache), то при Линукс е той е независим от файловата система и съответно не би трябвало да има никаква разлика в поведението му при ext4/xfs/btrs.

Ето за тези данни говоря (маркираните) :
EXT4 http://s19.postimg.org/rv36um29d/bufer.png
BTRFS http://s19.postimg.org/za1peh2wh/btrfs.png
Размерът и поведението при различните файлови системи е доста различно.
При ext4 динамично се променят и са поне 20 пъти повече, като обем. При xfs и btrfs са постоянна величина (винаги) с обем от около 1000КБ.
Тази вечер, направих експеримент и натоварих така машината, че да изразходи за кеш почти цялата RAM памет. И тук, поведението е различно при различните файлови системи. При ext4 трябва да свърши цялата свободна памет, за да навлезеш в swap. При btrfs, системата заема от swap дяла много преди да свърши свободната физическа памет и дори изобщо не се стига до това положение.

Тези стойности, които си показал, би трябвало да са в байтове, т.е. при ext4 имаш 46кб, при btfs - под 1кб.
Иначе може да пробваш за теста да ремаунтнеш ext4 с опция commit=1, например. По подразбиране е 5, което означава, че на 5 секунди flush-ва buffer кеша. Но имай предвид, че по-ниската стойност ще ти забави системата, но пък ще има по-малък шанс за загуба на данни при power loss.

Отпред пише килобайти. Под 6 000 000 КБ може би имат предвид 6 ГБ, колкото ми е виртуалната памет.
A, и това няма никакво значение. Не искам да променям настройките на нито една файлова система, нито да правя други експерименти.
Искам да знам, конкретно, защо на едната буферът се променя непрекъснато, а на другата, размерът е винаги една и съща стойност, включително в момента.
http://s19.postimg.org/4z8qhi3g1/btrfs1.png
Двадесет до четиридесеткратната разлика в обема на данните мога да си я обясня с различните настройки или вид/форма на съхранение на данните.

Цитат

И тук, поведението е различно при различните файлови системи. При ext4 трябва да свърши цялата свободна памет, за да навлезеш в swap. При btrfs, системата заема от swap дяла много преди да свърши свободната физическа памет и дори изобщо не се стига до това положение.

Това няма абсолютно никакво отношение към монтираните файлови системи.

Оказва се, че буферът е, колкото го показва top.
http://s19.postimg.org/yq51ur375/bufer1.png
Ще се върнем ли на въпроса, или трябва да прекомпилирам и ядрото ?
Все пак, мисля, че въпросът беше ясен и се базира на показанията на една и съща програма, върху една и съща дистрибуция, ядро и хардуер. Интересуваше ме причината за разликата в тези резултати.

Цитат на: cybercop в Aug 24, 2015, 09:54

"Скоро" в света на файловите ситеми, означава, поне две години. До тогава, btrfs, вероятно ще стане файлова система по подразбиране в повечето дистрибуции. След още една - две години, когато се развие достатъчно новата файлова система, ще почнат нови дискусии "Заслужава ли си да преминавам от btrfs на файлова система X". В света на софтуера, този цикъл се повтаря през няколко години. Същото се случи при преминаването от ext3 към ext4.

Ми ще има със сигурност и може дори аз пак да я подхвана. Винаги има период в който при една файлова система се изчистват всякакви кусури, а и ако има нещо фундаментално сгрешено се разбира. Изобщо не съм фен да съм early adopter на може би най-критичния елемент в една система. Тази дискусия ми беше полезна до толкова до колкото никой не се оплака и следователно може да си я ползвам.

Само да отворя една скоба като заговорихте за кешовете. В ZFS има нещо като L2ARC https://blogs.oracle.com/brendan/entry/test което според този автор давало чувствителна производителност.
Колкото до скоростите на файловите системи няма нещо което да се мери с един нов по-бърз диск да речем, така че за мен този въпрос е теоретичен повече.

Има и нещо друго - за да работи добре на ZFS и трябва доста RAM. Така че за десктоп по-скоро не бих я ползвал.

Цитат на: growchie в Aug 31, 2015, 08:48

Винаги има период в който при една файлова система се изчистват всякакви кусури, а и ако има нещо фундаментално сгрешено се разбира. Изобщо не съм фен да съм early adopter на може би най-критичния елемент в една система. Тази дискусия ми беше полезна до толкова до колкото никой не се оплака и следователно може да си я ползвам.

Файловата система е нещо много консервативно. Това, което се променя динамично е поддръжката за нея в ядрото на ОС и създаването на допълнителните инструменти за работа с нея.

Цитат

Оказва се, че буферът е, колкото го показва top.
http://s19.postimg.org/yq51ur375/bufer1.png
Ще се върнем ли на въпроса, или трябва да прекомпилирам и ядрото ?
Все пак, мисля, че въпросът беше ясен и се базира на показанията на една и съща програма, върху една и съща дистрибуция, ядро и хардуер. Интересуваше ме причината за разликата в тези резултати.

Ами ето ти ясен отговор: ext{3,4} ползват jbd layer-а (https://en.wikipedia.org/wiki/Journaling_block_device) за журнала и съответно буферите, които ползва този слой се показват в колонката, която гледаш. От друга страна xfs (а вероятно и btrfs) не ползват jbd, а си имат тяхни имплементации и съответно не се отразяват в Buffer колонката. За да видиш аналогичните стойности при xfs, може да се разровиш в /proc/slabinfo. Не ми се рови в сорса, но вероятно става въпрос за xfs_buf (grep xfs_buf /proc/slabinfo). За да получиш реалния размер трябва да умножиш стойността на num_objs * objsize.

Цитат на: d0ni в Aug 31, 2015, 16:10

Цитат
Оказва се, че буферът е, колкото го показва top.
http://s19.postimg.org/yq51ur375/bufer1.png
Ще се върнем ли на въпроса, или трябва да прекомпилирам и ядрото ?
Все пак, мисля, че въпросът беше ясен и се базира на показанията на една и съща програма, върху една и съща дистрибуция, ядро и хардуер. Интересуваше ме причината за разликата в тези резултати.

Ами ето ти ясен отговор: ext{3,4} ползват jbd layer-а (https://en.wikipedia.org/wiki/Journaling_block_device) за журнала и съответно буферите, които ползва този слой се показват в колонката, която гледаш. От друга страна xfs (а вероятно и btrfs) не ползват jbd, а си имат тяхни имплементации и съответно не се отразяват в Buffer колонката. За да видиш аналогичните стойности при xfs, може да се разровиш в /proc/slabinfo. Не ми се рови в сорса, но вероятно става въпрос за xfs_buf (grep xfs_buf /proc/slabinfo). За да получиш реалния размер трябва да умножиш стойността на num_objs * objsize.

Благодаря. Това ми трябваше. Отдавна съм забелязал, че системи под btrfs и xfs имат сходно поведение. Възможно е в btrfs да са копирали доста неща от XFS.

Някой мигрирал ли е от ext4 към btrfs ($2) с ядро 4.x? Понеже искам да мигрирам, но в уикито ме плашат с проблеми, ако използвам ново ядро.
Иначе най-лесния вариант е да ползвам някой жив диск с ядро 3.x за конвертирането. То така или иначе ми трябва жив диск за да конвертирам, просто се чудя какво да използвам. Обаче, не е ли по-добре да използвам последните версии на инструментите за конвертиране, а и същото ядро, което после ще върви?
Между другото, ако накарм grub да зареди iso от дял, който ще конвертирам - няма да има проблеми, нали? В смисъл, няма да му хрумне по някое време, че трябва да чете от образа, намиращ се на дяла, който ще конвертирам.
Сещам се и още нещо - да речем, че тествам btrfs 1 месец, но искам да се върна към ex4, като съм запазил информацията за файловата система (виж връзката в началото) - тогава какво става с новосъздадените файлове?

Цитат на: zahari_bgr в Mar 05, 2016, 17:44

Някой мигрирал ли е от ext4 към btrfs ($2) с ядро 4.x? Понеже искам да мигрирам, но в уикито ме плашат с проблеми, ако използвам ново ядро.

Тествал съм я до ядро 4.2 и не съм констатирал проблеми. Няма логика, поддръжката за тази файлова система да се влошава в новите ядра. Тенденцията е точно обратната. Всяко следващо ядро е с по- добра поддръжка на btrfs.

Цитат на: cybercop в Mar 05, 2016, 19:22

Тествал съм я до ядро 4.2 и не съм констатирал проблеми. Няма логика, поддръжката за тази файлова система да се влошава в новите ядра. Тенденцията е точно обратната. Всяко следващо ядро е с по- добра поддръжка на btrfs.

Искам да преобразувам съществуващите си дялове, а на линка към уикито на btrfs по темата пише:

Цитат

Warning: As of 4.0 kernels this feature is not much used or well tested anymore, and there have been some reports that the conversion doesn't work reliably. Feel free to try it out, but make sure you have backup

Т.е. че btrfs-convert може да се издъни.
За това питам някой от тук конвертирал ли е от ext4 към btrfs с ядро 4.х.

В цитата, който си публикувал, не виждам ядро 4.ХХ, а ядро 4.0. А, това е доста рядко използвано ядро, като се има предвид, че LTS са 4.1 и 4.4. Доста грешки от 4.0 се изчистиха в 4.1.
П.П.: За конвертиране нямам практически опит. Ползвал съм файловата система в новоинсталирани системи.
Извинявам се. Не разбрах, какво имаш предвид под мигриране в първия пост.

Linux за българи: Форуми

Нетехнически теми => Идеи и мнения => Темата е започната от: growchie в Aug 20, 2015, 10:20