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

Искам да попитам :
Някой ползва ли XFS  , по точно за "root" дял и какви са му впечатленията от нея?

Не съм сигурен че точно за / дяла има някакъв смисъл от XFS. Погледни сравнителните таблици и ползвай тази файлова система там, където тя е силна

Ооо да аз я ползвам. За / дял може би е е много удачно поради това че може да има проблеми с боотването. Но все пак си зависи с каква дистрибуция си. Аз съм от голямите й фенове и определено бих ти я препоръчал да я ползваш но естествено по правилния начин. Тази фс е на светлинни години от ехт3!

Еми ако искаш, като се счупи да ти изчезнат файлове - ползвай я :-) Много е интересно и ако си счупиш супер блога и има да чакаш с дни да намери втория :-) ...ташак работа

И преди да са ме оплюли да вметна следното:
* Счупен XFS и ремонтиран от съпорта на червената шапчица резултата е 10-20% загуба на информация
* Дърпане на кабела на захранването води до случване на супер блока в 60% от случаите /тествано от мен лично/.

Иначе нямаш проблем да boot'неш от такъв тип файлова система

П.П. говорим за PC архитектура!

Не виждам някакъв смисъл да се ползва точно за / файловата система.

Ами стува ми се доста по бърза от ext3 . Но от ext3 не съм губил данни . Ама трябва много време , и то пак няма да съм сигурен , овсем да гася компютъра от щепсела  ...

ext3 е с 20-30% процента по-бърза за малки файлове (под 100М) от xfs. При условие, че xfs е форматирана с 2 реда конфигурационна команда за оптимална работа с тези файлове - смешно. Не се подвеждайте под тестова направени върху огромни терабайтови масиви. Това определено не е продуктовия сървър, който ползва, нали?

единствения проблем на ext3 е лимита от директории!

Всъщност ако инсталацията ти представлява една голяма файлова система с една голяма директория, пълна с много много mp3-ки (например), тогава може и да има смисъл..

Между другото, аз лично съм наблюдавал ext3 колко зле се държи при някои странни обстоятелства. И това лесно се възпроизвежда. В конкретният случай беше един прост шел скрипт, с dd чете няколко байта от /dev/urandom (не /dev/random !, прави им md5sum и полученият стринг е аргумент към mkdir. Някъде около 7-8.000-дната такава директория, mkdir започва да отнема около секунда, това с ext3, на относително бърза машина.

С reiserfs същото упражнение показва по-добри резултати, с xfs вероятно също, ще пробвам, но съм убеден че ще е по-бързо.

Но това е доста граничен случай де

Не искам да загубя файлове. Ако  "роот" се скапе , винаги може да инсталирам наново ( може и от архив ?) ,  а важните неща да са на ext3 ?
Благодаря за отговорите!

Да, прав си! Но ако разгледаш сорса на ext3 ще видиш защо. xfs пък ги "прави" файловете... сере ги където си и след това почва дефрагментация - не следи къде точно са слободните inodes и има цяло дърво със свободните и за това създава илюзията за по-добра производителност. Като сумарно времето е по-голямо, но наистина има ефект за терабайтови масиви.

Иначе reiserfs има САМО един недостатък - rebuild-tree за един терабайт минава за 5 дена на относително мощна машина! И ако нямаш 10% свободно място... кур батенце

То в "root" по скоро как чете е важно , сега си мисля че и ext2 не е лош избор.

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

От друга страна, четенето е забавна работа, dentries и inodes се кешират от ядрото и веднъж изчетени, следващият път вероятно ще се изчетат по-бързо.

От трета страна. ext2/3 файловите системи нямат навика да записват dentries последователно на диска, така че изчитането на една директория, често води до seek операции, а те са най-бавни.

Така че, горният случай с записването на много поддиректории, означава също че и изчитането на тази директория (libc функцията readdir() - демек getdents() ) също така ще е доста по-бавно при ext3, отколкото при някоя друга файлова система.

Не мога да го твърдя със 100% сигурност, но мисля, че кешираните dentries се инвалидизират при записване на нов файл/директория, при четенето, съдържанието на директорията се flush-ва първо върху диска, след това се изчита новата директориина структура, като flush-ването слага един lock, който се освобождава след изписването й.

Един типичен сценарии е примерно /tmp директорията, в която apache записва едни сесийни файлове (примерно). strace-вал съм apache процеси и го знам колко тъпо се държи (не се опитва директно да изчете файла, а първо изчита директорията и ако няма такъв файл вади грешка, не знам защо прави така, може и да има причина).

Та при един натоварен сайт, при който тези сесийни файлове се записват на една ext3 файлова система, сайтът вероятно ще се отваря малко по-бавно.

Това е теория само де, не знам

Както казах, става въпрос за съвсем минимални разлики и гранични случаи. xfs е извратена файлова система за мен и тези минимални разлики не биха оправдали използването й за такива цели. Но това е мое мнение.

П.П. за щастие сорс-а на ext3 никога не съм го гледал. Иначе съм имал малко вземане-даване с vfs слоя, правил съм си много елементарна файлова система с файлове, които дефакто нямат backing device, за тях се заделя памет и така...това беше просто да си играя, да си призная честно тези неща с файловите системи са ми доста мъгливи. Това беше много прост и елементарен случай, ако трябва да вземаш предвид и дисковото устройство и организацията на данните по него, нещата предполагам доста загрубяват Но пък vfs от друга страна предоставя generic callback функции и всичко, което трябва да направиш е да пренапишеш някоя.

Добре , имате ли някакви идеи как да я тествам , без да гася компютъра от тока ?

Можеш да си направиш 2 примерно 5- гигабайтови файлове, да ги използваш за имиджи в qemu, да си ги форматираш с различните файлови системи и да тестваш. Според мен играчката не си струва.

Начи най се опасявам  от случайте от неправилно гасене , за които говори @GigaVolt. Иначе за производителност , то си се чуства , че е по добра . Сега пробвах новото SystemRescueCd (1.01) , не ми дава да я свивам , но форматирането на 49Г е около  2 секунди , то изобщо има ли формат ? Май се отказвам , оставям я да "отлежи", и времето ще покаже.Благодаря за отговорите още веднъж , ако се сетите още нещо  , казвайте.

А ти файлова система за какво търсиш Дай малко повече критерии!

на един от компютрите ми ползвам xfs за home дяла

и единствената причина да не съм я сменил е, че нямам време

причината е точно, че при проблем със захранването или нещо друго предизвикало гасене на РС-то без да е unmount home-a и почти винаги губя файлове ..... дори и такива, които не са били отворени  

така че за root никога не бих я ползвал

Освен опасността от загуба на данни , XFS  ( поне при мен )  много лошо се представи при изтриване на файлове. За сравнение ползвах една директория , сорса на ядрото и компилираните в нея файлове  , около 350 Мбайта ,
Kомпресиране с :
 time tar -czvf test_dir.tar.gz   test_dir/

Изтриване с:
time rm -fr  test_dir/*

И разархивиране с:
time tar xvf  test_dir.tar.gz

Като всички тестове бяха направени с LiveCD  SystemRescueCd-1.0.2-beta2 .
http://www.sysresccd.org/Beta-x86

Идеята ми беше да подбера най-бързата файлова система , и да я сменя на един дял , в който имам Ubuntu 8.04 (i368) , просто искам да „изстискам“ максимално това Убунто , да видя до колко може да се мери с 64 битовото ( имам и него) , защото в момента е бавно , а и да сравня каква е разликата с друга файлова система.
И ползвах свободен дял , в който направих горните тестове последователно xfs ,ext3, ReiserFS , Reiser4 .  Те разбира се не могат да бъдат достоверни , но явно беше превъзходството на  Reiser4. А XFS e малко по добра от ext3 само при четене , но когато трябваше да изтрие , беше ужасна.
Та накрая се спрях на  Reiser4 , архивирах дяла на  Убунто :
mkdir /dest  /source ;
mount -t reiserfs /dev/hda4 /dest  
 mount  -t xfs /dev/hda13 /source
cd /dest
 tar czvf source.tar.gz /source
umout /source
Правене на  Reiser4 ( gparted ) , и:
mount -t reiser4 /dev/hda13 /source
     tar xvf  source.tar.gz  -C  /
Всичко си е ОК , само че , нямам ядро , което да подържа  Reiser4. Та ползвам това , от LiveCD – rescue64.  И пее , ама ми трябва сорса , да го прекомпилирам , нещо не го намирам ( gentoo ?). Иначе трябва да правя
mm patch -a, за да подържа  Reiser4.
http://kernel.org/patchtypes/mm.html
a те в последно време  са  много несигурни .
 Позагледах се в пачовете , какво става с тая  Reiser4 ?
Ами например , един огромен пач е от рода:
минус някакъв  текст;
   плюс  някакъв текст;
Горе долу като : намери разликата м/у картинките.

 И сега питам за Reiser4 ?
Някой ползва ли го ?

P.P
Пача е в:
http://chichkin_i.zelnet.ru/namesys/

Е това е тестова версия... ext4 and reiser4 още не стават за нищо НООО всички ги чакаме с интерес

Е аз си компилирах ядрото :
tar xvf linux-2.6.24.tar.bz2
gunzip reiser4-for-2.6.24.patch.gz
cd linux-2.6.24
patch -p1 <../reiser4-for-2.6.24.patch
няма откази.
Но това не е най-новото , има доста пачове , ама за сега е ОК.

Начи ето един лесен начин , за компилиране на ядро 2.6.24.3 с подръжката на Reiser4 , aufs , squashfs +lzma.
Oт:
.ftp://ftp.slax.org/source/slax/kernel/2.6.24.3/
се изтегля цялата директория „src-core“ и я слагате някъде .
От:
http://chichkin_i.zelnet.ru/namesys/
теглите пача „reiser4-for-2.6.24“  и го слагате в /usr/src.
Разархивираме го с:
gunzip reiser4-for-2.6.24.patch.gz   т.е . имаме файл:
/usr/src/reiser4-for-2.6.24.patch

Влизате в „src-core“ и  може да си смените  файла „config“ вашата конфигурация. ( пак да е „config“ , може да я вземете от /boot/config-`uname -r` ).
Може да обновите aufs.tar.gz  със скрипта:
chmod a+x  get-aufs-cvs.sh
./get-aufs-cvs.sh

Отваряте build.kernel файла и може да промените линията
 116 „make oldconfig“ например на „make menucinfig“
Преди тази линия  обаче трябва да приложим пача , та добавяме:  ( преди „ make menucinfig“):
patch -p1 <../ reiser4-for-2.6.24.patch

После стартираме скрипта:
./build.kernel
Като стигне на „ menucоnfig“ маркираме  Reiser4 като вградена ( с модул на съм пробвал ).
Като свърши , преместваме си от /tmp/2..6.24.3 всичко по местата (  boot .>boot(ядрото)   , lib ->lib(модулите) ..usr/bin програмите за squashfs ).
После почистете  /usr/src остават много неща ( и ако ще повтаряте компилирането ,пак почистете предварително).
П.П
Grub не разпознава дяла , затова ядрото трябва да е някъде другаде , например:
kernel  (hd0,10)/boot/vmlinuz-2.6.24.3  root=/dev/hda15
( ядрото е на друг дял , но root си сочи дяла  с "reiser4")

Иво, според мен не е трудно да го подкараш. Плашещ в случая е факта, че софтуера е определен от разработчиците за нестабилен в момента и не би трябвало да се ползва, като изключение правят мега ентусиастите /които не се плашат от проблеми и искат да помогнат на отбора/