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

От около месец ползвам BTRFS като основна файлова система. Досега, не съм забелязал, някакви проблеми в работата с нея. Дори ми се струва, че има леко подобрение в скоростта при извършването на файлови операции. Компресирането не е активирано и не смятам да го правя.
Разликата, която реално се забелязва е огромното количество кеширани данни, които се задържат. Понякога, стигат до 3 ГБ и се задържат до края на сесията. Това, наистина помага на приложенията да заредят по- бързо, но ме вкарва в размисли.
http://s19.postimg.org/d88ubsb3l/top.png
Въпросът е - има ли някаква вероятност да се стигне до момент в който, голямото количество кеширани данни да възпрепятстват оперативната работа на системата?
В смисъл - да не остане достатъчно свободна памет.
Досега не ми се е случвало, но може, някой да има по- голям опит с тази файлова система и да е по- добре запознат.

Браво за темата! На мен също ми е много интересно да чуя отзиви за тази файлова система.
Относно кешираните данни, не мисля че е възможно да се случи, тъй като disk cache не спира други процеси да заемат от неговата "кеширана памет" -  не пречи нови процеси да използват паметта.

И аз я пробвах. Като цяло забелязах, че малко по-бавно зарежда системата. Не зная защо. Не съм се интересувал още, защото не ми е проблем. Работи нормално.

При мен зарежда, като система върху ext4 или незначително по- бързо. Във всеки случай - разликите при зареждане са нищожни. Възможно е, забавянето да се дължи на допълнителен процес, а не на файловата система.

Въпросът е - има ли някаква вероятност да се стигне до момент в който, голямото количество кеширани данни да възпрепятстват оперативната работа на системата?
В смисъл - да не остане достатъчно свободна памет.

BTFS не кешира, това се прави от VFS cache layer-а и от тази гледна точка не би трябвало да има разлика в размера на кешираните спрямо предишния ти FS. Ако беше ZFS - ок, там си има специален кеш - ARC, който на теория е по-интелигентен от стандартния page cache. Дали има шанс да останеш без памет заради кеш - виж /proc/sys/vm/vfs_cache_pressure:

Controls the tendency of the kernel to reclaim the memory which is used for
caching of directory and inode objects.

At the default value of vfs_cache_pressure=100 the kernel will attempt to
reclaim dentries and inodes at a "fair" rate with respect to pagecache and
swapcache reclaim.  Decreasing vfs_cache_pressure causes the kernel to prefer
to retain dentry and inode caches. When vfs_cache_pressure=0, the kernel will
never reclaim dentries and inodes due to memory pressure and this can easily
lead to out-of-memory conditions. Increasing vfs_cache_pressure beyond 100
causes the kernel to prefer to reclaim dentries and inodes.

BTFS не кешира, това се прави от VFS cache layer-а и от тази гледна точка не би трябвало да има разлика в размера на кешираните спрямо предишния ти FS. Ако беше ZFS - ок, там си има специален кеш - ARC, който на теория е по-интелигентен от стандартния page cache. Дали има шанс да останеш без памет заради кеш - виж /proc/sys/vm/vfs_cache_pressure:

Не кешира, но, въпреки това, разликата в кешираните данни е огромна.
Това е резултата, когато съм ползвал ext4
http://s19.postimg.org/3nv518dgx/top1.png
В момента с btrfs
http://s19.postimg.org/ioj8hfnld/top_btrfs.png
До края на сесията, кешът ще нарасне поне два пъти. При ext4, след известен престой, кешираните данни се премахват.

Дони, при положение, че бътърефес се опитва да е zfs, то вероятно с него идва нещо кеширащо дори да не е вградено. Не вярвам да са пропуснали да гепят нещо.

Това разбира се е спекулация. Btrfs е поредната повърня, до която няма да се докосна.

Аз се докосвам, за да разбера, дали действително е такава. Че, много специалисти-теоретици се навъдиха.
Засега, става точно така, както писах в предишният пост
http://s19.postimg.org/p3i9e3ub5/btrfstop2.png
Може би ще се върна на ext4, но засега системата работи много добре и не ми се занимава.
Евентуално, като излезе стабилната версия на Debian Jessie, защото и без това, няма да мога да издържа на изкушението.
Тези кеширани данни, просто ми поддържат приложенията "активни". В смисъл - стартират много бързо. Иначе - никакви проблеми нямам със самата работа.

Дони, при положение, че бътърефес се опитва да е zfs, то вероятно с него идва нещо кеширащо дори да не е вградено. Не вярвам да са пропуснали да гепят нещо.

Това разбира се е спекулация. Btrfs е поредната повърня, до която няма да се докосна.

go_fire, zfs cache-а (ARC) е нож с две остриета - ефективен е понеже ползва две стратегии - MRU и MFU и адаптивно определя размера им спрямо workload-а. Но за да се имплементира, трябва да се заобиколи стандартния page cache за да се избегне двойно кеширане. А BTRFS няма собствен кеш, проверих. Няма и вградена възможност да ползваш SSD за кеширане на данни (както L2ARC при ZFS).

cybercop, можеш ли да дадеш output-а на /proc/slabinfo (през pastebin) в двата случая?

Заповядай :
master@master-laptop:~$ sudo pastebinit /proc/slabinfo
[sudo] password for master:
http://paste.ubuntu.com/9255552/
master@master-laptop:~$

Не би трябвало да кешира повече от ext4, поне няма някаква причина поради която да го прави. И двете използват dentry/block кеширането в ядрото, не би трябвало да има каквото и да било значение. Да не би поради някаква причина да е променян swappiness-а покрай тази миграция на файловата система?

А иначе btrfs никога не съм виждал даже, мразим оракълски файлови системи от едно време, кога трябваше да имам вземане-даване с ocfs2.

Ма т'ва извращение Зетефес го писаха слънцата и в типичният си гаднярски стил не го сложиха под ОПЛ. От днешна гледна точка можем да сме им благодарни за неблагоразумието. Те сами изковаха съдбата си.

zfs е друга губерния, която също никога не съм ползвал, въпреки всичкото рекламиране, винаги ми се е виждало като комбинация от LVM и произволна файлова система и поради тази причина не ме е интересувало особено. ocfs2 от друга страна е клъстерна файлова система от сорта на gfs. В известен смисъл трябва да призная че е доста по-прощаваща към юзъри от редхатския еквивалент, но когато се счупи се счупва качествено и тогава ходи се оправяй. В граничните случаи когато SAN блоковите устройства почват да се държат странно поради мрежови проблеми, ocfs-а почва да се опитва да мисли прекалено много и стават необясними драми. Поне ставаха преди години, сега се радвам че нямам никакво вземане-даване с тези гадини.

Това му е проблема. Това е файлова система, която се опитва да прави прекалено много неща ‑ да бъде едновременно ФС, архиватор, RAID, инструмент за управление на ФС и още глупости. Това е еквивалента на sd при файловите системи.

Ми аз имам представа главно от ZFS и тя иска наистина много РАМ за да е ефективна, иначе се забавя. Някои функции са деактивирани на машини с под 4 гб рам. BTRFS не знам до колко вече е стабилна и е безопасно да се ползва за критични данни. Иначе като цяло си е супер това.

BTRFS не знам до колко вече е стабилна и е безопасно да се ползва за критични данни.

Още поне няколко години няма да е, въпреки че в SuSE вече я сложиха като файлова система по подразбиране. Ако човек иска подобна, но стабилна, файлова система, за момента трябва да избере ZFS. Ако администрира машини със стотици и хиляди дялове, тогава пак е по-добре да избере нея, а не LVM с която и да е друга файлова система. Но за масовия случай (било то десктоп или сървър) дълго ще продължа да избирам LVM с която и да е друга файлова система.

ZFS+FreeBSD е супер. BTRFS го сложиха в SuSE за да могат да реализират снапшот архиви по време на ъпдейт на пакети, което отново е супер като идея. Иначе за нещо различно от файлов сървър не бих ползвал нито едната, нито другата. Просто много рам лапа. Иначе дедупликацията в ZFS е супер стига да имаш процесора и паметта да го поддържаш.

Темата е доста стара, но реших да се включа :)
ZFS е доста добър FS, но наистина е предназначен по-скоро за "big iron" или иначе казано дебели сървъри с доста рам, добръ процесор и бързи дискове. При нея готиното е, че може да се настрои да използва комбинация от HDD/SDD ефективно, а не ги третира просто като еднакви block device-и. Вече има и директен порт към Линукс и казват, че работел почти като под FreeBSD (доста по-добре от предишната fuse имплементация).
Друго адски удобно нещо е администрацията - счупен диск в райд/мирър, менажирането на файловите системи и т.н. въпреки, че последното е малко неинтуитивно в началото.

За кеширането - колкото повече по-добре. Според мен просто си имал повече I/O, което се е кеширало, ако си пускал някакви тестове или си копирал/местил файлове. Ако метнеш достатъчно данни може и цялата та ти се напълни, но това не е проблем. Кеша си е свободна памет, която се оползотворява, за да не утива "зян". В момента, в който някой процес си поиска памет, част от кеша се дропва (стига вече да е на диска) и се дава на процеса. Може да познаеш, че ти свършва рама ако ОС-а ползва SWAP, иначе си пушка

Понеже се заговори за файлови системи, в момента съм с ext4 и на системния дял и този за домашната папка. Забелязах, че нещо ми свършва паметта. Главно като ползвам някой браузър. Преди не ставаше така. Имал съм отворени по 60-70 таба, половината сигурно със сложени на пауза клипове в тубата и машината си вървеше. Сега като погледна процесите и тъпия Хром, а и Мозилата харчат много, ама много. Къде да търся причината. Във новите версии на браузърите или някъде другаде? Споменахте кеширане от файловата система. ext4 прави ли това?
Все си мислех, че осем гигабайта рам ще са ми достатъчни, ама сега се замислям, дали да не сложа още една осмица. 

Много хора се бъркат, защото сравняват Linux със Windows и да кажем top със Task Manager-а и колко памет е заета :)
Windows, или не си казва, или наистина не използва целия наличен RAM, което за Linux си е чисто хабене на ресурс.

Filesystem cache-а си е в самия kernel и се използва при всички файлови системи ext3/4, xfs, reiser (zfs има специален, но мисля, че ако не се изключи изрично, и другия си работи, което забавя нещата).
Ето един отрез от free -m на моята машина, преди малко я рестартирах:

             total       used       free     shared    buffers     cached
Mem:         15808       2722      13086        243         45       1304
-/+ buffers/cache:       1372      14436
Swap:         4091          0       4091

Само след няколко минути:

             total       used       free     shared    buffers     cached
Mem:         15808      15593        214        261         48      13981
-/+ buffers/cache:       1564      14244
Swap:         4091          0       4091

Според втората извадка, RAM-а ми на свършване. Само че за Linux, използвана (used) е памет, която се ползва за каквото и да е.
Пак на първия ред под cached виждаш, че 13981 MB всъщност са кеш на файловата система и на практика са свободни. Спокойно можеш от used да извадиш кешираните и ще видиш горе доло колко действително свободни имаш.

За по-лесно гледай втория ред "-/+ buffers/cache:" там използваната и свободната са сметнати БЕЗ да се включват буферите и кеша и виждаме, че реално използвания RAM е 1564 MB.

Ако паметта наистина е на свършване, на първия ред в cached, числото ще е много малко, тоест няма "свободно" място за оползотворяване с кеш и всичко е заето от процеси. Тогава и swap-а ще почне да се пълни и т.н. Надявам се, че горе долу го обясних :)

П.П. Напълниха се кешовете, защото копирах един ~7 GB файл. С местене няма да стане, защото всъщност ще се сменят само мета данните, няма да има истински 7 гъби I/O

Ма т'ва извращение Зетефес го писаха слънцата и в типичният си гаднярски стил не го сложиха под ОПЛ. От днешна гледна точка можем да сме им благодарни за неблагоразумието. Те сами изковаха съдбата си.

След като не знаеш за какво говориш е по-добре да замълчиш. Пробвал ли си някога ZFS? Пускал ли си я на прадъкшън системи (не една а >200)? Възстановявал ли си данни от нея?

И аз да добавя за ZFS лиценза, Sun всъщност си отвориха сорса на цялата операционна система, включително ZFS, zones, DTrace - всичко.
От там дойде по едно време и OpenSolaris. Обаче Oracle ги купиха и отново затвориха сорса, така че те са за оплюване, а не слънцата (които са дали доста неща, включително NFS още в зората на Unix-а).
Та от тоя OpenSolaris са форкнати ZFS, DTrace, Illumos кернела и т.н.

И аз да добавя за ZFS лиценза, Sun всъщност си отвориха сорса на цялата операционна система, включително ZFS, zones, DTrace - всичко.
От там дойде по едно време и OpenSolaris. Обаче Oracle ги купиха и отново затвориха сорса, така че те са за оплюване, а не слънцата (които са дали доста неща, включително NFS още в зората на Unix-а).
Та от тоя OpenSolaris са форкнати ZFS, DTrace, Illumos кернела и т.н.

Вярно. Дребния проблем е че в момента ZFS е много по-напред от версията, която е в ОпенСоларис

Не съм толкова навътре със солариса, но типовете зад Illumos и разните SmartOS, OpenIndiana и другите дистрибуции, казват, че има много неща в тяхната версия на ZFS, които Oracle нямат, понеже те са си ги написали и са ги лицензирали под лиценз несъвместим с Oracle-ския. Може и да има нещо вярно, повечето от тия хора са разработвали ZFS и Соларис кернела преди да ги купят оракулите, че някои и след това. Има надежда :)

След като не знаеш за какво говориш е по-добре да замълчиш. Пробвал ли си някога ZFS? Пускал ли си я на прадъкшън системи (не една а >200)? Възстановявал ли си данни от нея?

Мнението ми за  зетефес е в следващият ми коментар. За по-лесно, ще се самоцитирам:

Това му е проблема. Това е файлова система, която се опитва да прави прекалено много неща ‑ да бъде едновременно ФС, архиватор, RAID, инструмент за управление на ФС и още глупости. Това е еквивалента на sd при файловите системи.

Да не съм админствал такива чудовища, вярно. Но пък колко ли са тези, дето са?

В коментара, който цитираш, всъщност говорих за скапаният му договор за разпространение, специално проектиран да е несъвместим с ОПЛ и от там реализациите с бушони и т.н. Но както казах, направиха ни услуга.

***

Дитрейс е съвсем трета кочина. А енефес пък що е изписано за нещо, колко е скапан, нямам думи.

ZFS вярно не се придържа към Unix идеала една програма да прави 1-2 неща, но изключително добре. Прави много неща, но пък си ги прави добре. Колко са хората, дета са администрирали дебели сървъри със ZFS - със сигурност са много по-малко от любителите linux-джии, но това не означава, че технологията е лоша.

Пак казвам, ZFS беше отворен на 100%, 1:1 с това, което беше в Solaris 10. Сега има 11, но ZFS особено не се е променил, така че fork-а си е перфектен, но работи по-добре под FreeBSD и Illumos производните, просто не е приключил порта към Linux.

А за DTrace пък явно въобще нямаш идея що е то и за какво аджеба се ползва. Не че аз съм го ползвал, но знам достатъчно, че да осъзнавам колко съм невеж в темата. Там нещата са на много ниско ниво и никой със всичкия си няма да седне да си пуска/пише DTrace скриптове за десктопа (освен ако не е да се научи, за да го ползва другаде).

За NFS е малко наобратно, това че куцо и сакато пише, че е кочина, не означава автоматично, че е. Повечето проблеми се дължат на олигофренска или просто необмислена конфигурация на сървъра/клиента или ползване на стара версия (v2/v3 вместо v4).

Е добре в четвъртата версия след около двадесет години са го пооправили  ;D

Dtrace има няколко проблема. Първият е, че не е писан на Ц, а на тяхната си измишльотина Д. За да може да го развиваш не, да го ползваш, трябва да учиш още един език, който за нищо друго няма да ти трябва. Досадно и непрактично. Но не е само това. Практически  цялото слънчево ядро е обхванато от него, но на Линукс е пренесена една мъничка частичка, която не е чак толкова полезна. Екзотика.

п.п. Виличката на ЗФС щеше отдавна да се е случила, например няколко месеца след отварянето, ако не беше последният напън на юристите на слънцата да натъкмят последният от дълга поредица юридически капан. Както казах, сами си изковаха съдбата. Няма някой, който да е правил подобни мизерии и клиентите да не са го накарали да си плати, а те имаха богат опит в това.

Силно казано, че трябва да учиш цял нов език, за да ползваш DTrace. Това е просто някакъв елементарен синтаксис, който се учи за половин час, а преимуществата, които ти дава са безброй. А и каква е алтернативата? SystemTap също си има свой синтаксис.

/Off
Моля оправете заглавието на темата BRTFS --> BTRFS

Благодаря  [_]3