СЪЗДАВАНЕ НА ФАЙЛОВИ СИСТЕМИ
http://unix.ginras.ru/linux/base007.html
Алексей Федорчук
Създаването на файлови системи върху
дисковите дялове (или казано с термините
на DOS/Windows, форматирането на дяловете)
е вторият етап от подготовката на диска
за инсталация на Linux. Само по себе си
това действие не е от най-сложните, но
осъзнатото му изпълнение изисква някаква
подготовка.
СЪДЪРЖАНИЕ
УВОД
Терминът “файлова система” е един от
най-многозначните в компютърната
терминология въобще и в литературата,
свързана с операционната система Unix и
нейните клонове (a Linux се отнася именно
към тях) в частност. Голямо значение има
по-точно думата “система”. Нещата са
се развили исторически по този начин и
затова се налага да се определя значението
на термина според контекста. На мен са
ми известни поне пет значения, като не
съм сигурен, че това са всички възможни
значения.
Първо, файлова система или понякога
подсистема наричат частта от ядрото,
която управлява организацията на
файловете и операциите над тях. В този
аспект, заедно с файловата система роля
играе и системата за управление на
процесите и системата за вход/изход.
Между другото, именно това значение ние
засега няма да разглеждаме.
Второ, специфично за Unix и Unix-подобните
операционни системи, файловата система
е универсален интерфейс за достъп до
всички ресурси както на локалната
машина, така и на машини, обединени в
мрежа по произволен начин – от модемна
връзка до спътников канал. Именно
използването на такъв интерфейс в някоя
операционна система е една причините
за причисляването и към семейството на
Unix-подобните.
Трето, файловата система е метод за
описание на някакво физическо устройство
(обикновено дисков дял). Именно това
значение се използва в термина
“идентификатор на типа файлова система”,
за който се говореше в статията за
дисковите
дялове.
Обикновено той е специфичен за конкретната
операционна система и затова тук са
уместни термините “DOS-дял”, разширен
(extended) дял на DOS, дял Linux native и така нататък.
Макар че повечето истински операционни
системи могат по един или друг начин да
познаят “нестандартните” за тях
идентификатори и да се обръщат към тях
за данни. А в Linux като “вградени” (native)
се разглеждат дисковите дялове,
идентифициращи цял ред файлови системи
в третото значение на термина – от
наистина вградената Linux native до extended DOS,
включително и логическите (LVM) дялове,
за които ще стане в съответните
статии.
Тук трябва да отбележим, че покрай
физическите файлови системи (тези, които
надстройват реалните дискови устройства,
защото в този контекст нерядко фигурира
израза disk based file system), съществуват и
виртуални файлови системи от различен
тип. Към тях спадат файловата система
на устройствата devfs, временната файлова
система в оперативната памет tmpfs и procfs
– системата, представяща процесите във
вид на файлова система (съжалявам за
тавтологията). Понякога
се използват и файлови системи от
междинен тип, например виртуални дискове
(RAM дискове). Подобно на tmpfs, те съществуват
само в оперативната памет, но във всичко
останало имат поведението на физическите
(disk based) файлови системи.
Четвърто, под файлови системи се разбира
вътрешната управляваща структура,
позволяваща да съхраняваме, идентифицираме
и намираме данни, както и да ги манипулираме.
Такива структури, от една страна, са
специфични за операционните системи,
като FAT16 (с всичките нейни вариации VFAT
или FAT32) за DOS, UFS за FreeBSD или ext2fs за Linux. От
друга страна, структурите за управление
на файловете в редица операционни
системи се построяват по близки принципи,
като най-ярки примери за това са файловите
системи на Unix и Unix-подобните операционни
системи. И поради което, те могат да
бъдат обединени в едно семейство,
противопоставящо се, например, на FAT
семейството.
Освен това, Linux в момента може да работи
с управляващи структури от различен
тип – от ext3fs, представляваща надстройка
на традиционната ext2fs, до XFS и JFS, първоначално
разработени за Unix съответно от SGI и IBM,
както и ReiserFS. Няма забрана
и за разполагането на Linux на файлова
система FAT (макар също така да няма и
причини за това).
Ще добавя, че в списъка, изброен в горния
параграф са включени само файлови
системи, способни да носят основните
компоненти на Linux, отговорни за нейното
стартиране и минимална функционалност.
Колкото до обмена на данни – той е
възможен от Linux практически с всички
известни файлови системи, макар че с
някои от тях (примерно NTFS или HPFS) обменът
на данни е възможен само в режим на
четене.
И пето, последно, файловата система в
Unix е и логическа структура
на директории и файлове, която обединява
и физически и виртуални файлови системи
от най-различен тип (например дискови
дялове с ext2fs и FAT16, виртуалните procfs, devfs
и tmpfs), при това не само от локалната
машина, но и на всяка отдалечена машина.
Структурата е йерархична (дървовидна),
започваща с коренна директория (/), която
се явява родител на всичко останало, от
която се разклоняват отделни файлове
и дъщерни директории, които на свой ред
могат да бъдат родителски по отношение
на поддиректории от
по-дълбоки нива на влагане.
Положението на нещата в момента е такова,
че в Linux, структурата на файловата система
обикновено е специфична за конкретната
дистрибуция или група дистрибуции,
свързани с общ произход. Затова често
се срещат изрази като файловата система
на Red Hat или Debian. Именно тези исторически
създали се различия в йерархията на
директориите се явяват единият от
критериите, по които се обособяват
различните линии дистрибуции на Linux,
както и потенциална причина за тяхната
несъвместимост. Но може да се надяваме,
че усилията на стандартизиращите
организации, като Linux
Standard Base и Filesystem
Hierarchy Standard, (руският превод [1]
на стандарта е на сайта на Виктор
Костромин), ще се увенчаят с успех и
ще може да говорим за единна логическа
файлова система на Linux, подобна на тази,
която е в операционните системи от
семейството на BSD.
В контекста на настоящата статия, нас
ни интересува само четвъртия аспект на
файловите системи – създаването на
управляващи файловете структури,
базирани на дискове (по-точно на техните
дялове).
УСТРОЙСТВО НА ФАЙЛОВИТЕ СИСТЕМИ ОТ
СЕМЕЙСТВОТО НА UNIX
В този раздел ще говорим за неща, общи
за всички Unix операционни системи. Всички
файлове в Unix физически се състоят от
две части, реално разположени в различни
блокове на диска, но задължително
намиращи се на един и същ дисков дял,
бил той първичен или логически.
Първата част на файла, неговите така
наречени метаданни, които съдържат
файловия дескриптор (някакво уникално
число), сведения за неговите атрибути
(принадлежност, права за достъп, време
на модификация и т. н.), а също и информация
за това, в кои блокове на дисковия дял
(които така и се наричат – блокови данни)
физически се намира съдържанието на
файла – последователностите от байтове,
които образуват достъпен за потребителя
ASCII текст или изпълним модул на програма.
Метаданните за всеки файл са записани
в специална област на диска, наречена
суперблок, където образуват така
наречените inodes (от information nodes – информационни
възли). На всеки съществуващ файл отговаря
собствен inode и именно той еднозначно се
идентифицира с файловия дескриптор.
Сам по себе си, списъкът с тези информационни
възли, отговарящи както на съществуващи
файлове, така и на свободни блокове от
дисковият дял, определя границите на
файловата система, тоест колко файла
могат да бъдат създадени в нея.
По този начин, същността на процеса на
създаване на файлова система на един
дисков дял (или казано с терминологията
на DOS/Windows – неговото форматиране) е
създаването на този суперблок (в някои
файлови системи – на няколко негови
копия), списъка с информационните възли
(inodes) и отделянето на дисково пространство
за блоковете с данни (а също и за блок
за зареждане, за който ще бъде споменато
по-долу), а устройството на тези дискови
области се определя
от различията между файловите системи
от различен тип. В
резултат на това, на новия дял се създава
един единствен файл – коренната
директория (за дадената файлова система)
на дяла (в някои случаи се създава още
една директория, /lost+found, предназначена
за съхраняване на повредени или загубени
файлове).
Възниква въпроса, защо такъв неотменим
атрибут на файла, като неговото име, не
се намира нито в неговите метаданни,
нито даже в неговите данни? Отговорът
е прост – в Unix името на файла се явява
само по себе си не атрибут на файла, а
на файловата система (в петото, логическо
разбиране на термина). И за съхранение
на имената на файловете са предназначени
файлове от особен тип – директориите
(в Unix има и други типове файлове, например
споменатите преди файлове на устройства).
Те представляват просто списък на
файловите дескриптори на идентификаторите
и отговарящите им имена на файлове.
Затова, идващата от MacOS и активно
използвана във Windows метафора директория
като папка с документи, в Unix само замъглява
същността на нещата – тук по-скоро това
е каталожно чекмедже в библиотека.
Независимо от простото устройство,
ролята на директориите във файловата
система на Unix е трудно да се оцени –
имената на файловете, чрез които те се
включват във файловата система (и чрез
които потребителя получава достъп до
тяхното съдържание), фигурират само в
състава на директорията, към която файла
е описан и никъде повече в системата.
По този начин отстраняването на името
на файла (или поддиректорията) от списъка,
представляващ данните на неговата
родителска директория (която, разбира
се, има собствен информационен възел
inode и файлов дескриптор, свързани към
директорията, разположена едно ниво
нагоре в йерархията на файловата система
и така нататък) е равносилно на това,
метаданните на файла да станат недостъпни,
а свързаните към неговия информационен
възел блокове с данни да се маркират
като свободни. Именно по този начин се
осъществява отстраняването
на файловете от командата rm или от файлов
мениджър от типа на Midnight Commander [2].
Само че нас сега ни интересува точно
обратното – как да направим достъпна
файловата система. От казаното досега
става ясно, че за тази цел тя със цялото
си съдържание (суперблока, списъка с
информационните възли, блоковете данни)
трябва да бъде включена в състава на
някоя от съществуващите директории,
наречена точка на монтиране. Именно
това е същността на процеса на монтиране.
Резултатът за монтируемите файлови
системи е, че коренната директория,
която досега е била без име получава
името на директорията – точка на
монтиране (mount point), съдържанието на която
представлява списък от имената на
нейните файлове и поддиректории.
ФАЙЛОВИТЕ СИСТЕМИ НА LINUX
Ext2fs
До неотдавна списъкът на поддържаните
(native) файлови системи за Linux беше ограничен
до една единствена – ext2fs (вярно е, че
Linux може да се зареди и работи с FAT дял,
но затова даже не ми се говори). Названието
на тази файлова система се разшифрова
като “втора разширена файлова система”
– “разширена” в сравнение с файловата
система на операционната система Minix,
послужила за прототип на Linux, “втора”
– защото ранните версии на Linux използваха
extfs с по-ограничени възможности.
За файловата система ext2fs е писано немалко
(гледайте допълнителните източници).
Затова ще отбележа само, че по начина
на организиране на съхранението на
данните, тя e типичен представител на
файловите системи от семейството на
Unix. Нейна отличителна особеност е
наличието на няколко копия на суперблока,
което увеличава надеждността на
съхранение на данните. Освен това, тя
има характерен, много ефективен механизъм
за кеширане на дисковите операции, което
осигурява забележителното им бързодействие
– тя е една от най-бързите между известните
ми файлови системи. Обратната страна
на това бързодействие е относително
ниската устойчивост при аварийно
завършване на работата (вследствие на
блокиране на компютъра или спиране на
захранването), тъй като отложеният запис
на изменението на файловете увеличава
вероятността за нарушаване на връзката
между техните информационни възли и
блоковете с данни.
Разбира се, времената, когато некоректното
спиране на машини с Linux можеше да доведе
до пълно разрушаване на файловата
система, останаха в далечното минало.
Но във всеки случай, спирането на
системата без стандартно демонтиране
на файловите системи води до това, че в
тях не се установява така наречения
“бит за чисто демонтиране”. А без него,
програмите за обслужване на диска
(такива, като програмата за проверка
fsck) при презареждането на системата
няма да ги възприемат като цели и ще
започне проверка, която при съвременните
обеми на дисковете може да отнеме доста
време.
За журналните файлови системи
Проблемът с нарушаването цялостта на
файловата система при некоректно
завършване на работата в по-голяма или
по-малка степен е характерен за всички
операционни системи от семейството на
Unix. И затова от много време в тях се
разработват така наречените журнални
файлови системи. Дневникът
[3]
е нещо подобно на log-файл на дисковите
операции, в който се отбелязват не
извършените, а предстоящите действия
с файловете, вследствие на което е
възможно самовъзстановяването на
цялостта на файловата система след
срив.
За избягване на недоразумения, трябва
да подчертая, че протоколирането е
насочено към осигуряване цялостта на
файловата система, но в никакъв случай
не гарантира съхраняването на
потребителските данни като такива.
Така, че не трябва да очаквате, че
протоколирането по вълшебен начин ще
възстанови незапазените преди срива
промени в документа, зареден в текстовия
редактор.
Нещо повече, в повечето журнални системи
се фиксират бъдещите операции само над
метаданните на променяните файлове.
Обикновено това е достатъчно за
съхраняване на цялостта на файловата
система и във всеки случай предотвратява
дълготраещите проверки, но не предотвратява
загубите на данни при аварийни ситуации.
В някои от файловите системи е възможно
протоколиране на действията и в областта
за данни на файла. Но, както винаги,
повишаването на надеждността е за сметка
на намаляване на бързодействието.
Текущите версии на ядрото на Linux подържат
четири вградени журнални файлови системи
– ReiserFS и ext3fs, специфични за нея и XFS и
JFS – като резултат от портването в Linux
на файловите системи, първоначално
разработени за работни станции под
управлението съответно на операционните
системи Irix (SGI) и AIX (IBM). Широко признание
получиха само първите три системи,
поради което засега няма да говоря за
JFS.
ReiserFS
Файловата система ReiserFS е исторически
първата за Linux от журналните – тя се
поддържа от каноничните ядра
(http://www.kernel.org/)
още
от първите версии на клона 2.4.х (в момента
вече съществуват кръпки, позволяващи
използването на ReiserFS с ядра от клона
2.2.х). И беше единствената, разработена
от нулата специално за тази операционна
система от Ханс Райзер и неговата фирма
Namesys. Както и в
повечето разгледани файлови системи,
и в ReiserFS се осъществява протоколиране
само на операциите над метаданните на
файловете. При определено намаляване
на надеждността се осигурява висока
производителност – според мен, при
повечето потребителски задачи тя
отстъпва незначително на ext2fs. А при
такава обикновена операция, като
копирането на голямо количество малки
файлове, значително я изпреварва.
Освен това, ReiserFS притежава уникалната
(и по подразбиране активна) възможност
за оптимизиране на дисковото пространство,
заемано от малки, по-малки от един блок,
файлове (а трябва да помним, че във всяка
Unix система, такива файлове има в изобилие)
– те се съхраняват изцяло в своите
информационни възли (inodes),
без да се отделят дискови блокове в
областта за данни – заедно с икономията
на място, това води и до увеличаване на
производителността, тъй като и метаданните,
и данните (в света на термините на
ReiserFS – stat-data) се съхраняват в непосредствена
близост и може да се смятат за една
входно-изходна операция.
Втората особеност на файловата система
ReiserFS е, че така наречените опашки на
файловете, тоест техните крайни части,
които са по-малки по размер от един блок,
могат да бъдат опаковани. Този режим
(tailing) също се включва по подразбиране
при създаването на файловата система
и осигурява около 5% икономия на дисково
пространство. Което донякъде намалява
бързодействието на системата, поради
което режима на опаковане може да бъде
отменен при монтирането на файловата
система. Но при прекомпилиране на ядрото,
този режим се възстановява автоматично,
което, както ще бъде споменато малко
по-надолу, изисква внимателно отношение.
ReiserFS не е съвместима с ext2fs на ниво
обслужващи програми на файловата
система. Но съответният инструментариум
за това, обединен в пакета reiserfsprogs,
отдавна е част от стандартният комплект
на съвременните дистрибуции (или в краен
случай може да бъде изтеглен от сайта
Namesys).
По-сериозният проблем със съвместимостта
е този, че разпространените програми
за начално зареждане на Linux (и Lilo, и GRUB,
макар и по различни причини) често не
могат да заредят ядрото на Linux от дял с
ReiserFS файлова система,
оптимизирана с режим на опаковане на
опашките на файловете. А поради това,
че след като бъде изключен, този режим
притежава свойството да се самовъзстановява,
потребителя може да се сблъска с това,
че след прекомпилация на ядрото системата
просто да откаже да зареди. Именно заради
това споменах по-горе, че може да се
окаже необходимо създаването на отделен
дял за директорията /boot.
Ext3fs
За разлика от ReiserFS, ext3fs
не е нищо повече от протоколираща
надстройка на класическата ext2fs,
разработена от Стивън Туиди в компанията
Red Hat и поддържана от ядрото на Linux от
версия 2.4.16. Като резултат от този
произход, тя запазва пълна съвместимост
със своя прародител, включително и на
ниво обслужващи програми (започвайки
от версия 1.21 на обединяващия ги пакет
e2fsprogs). И прехода от ext2fs към ext3fs може да
бъде осъществен с просто добавяне на
журналния файл към първия дял, не само
без преформатиране на дяла, но даже и
без рестартиране на машината.
От тук идва първото предимство на ext3fs,
особено при голям брой компютри. Второто
предимство е едва ли не максималната
надеждност на системата – ext3fs е
единствената файлова система от
разгледаните, в която е възможно
протоколиране на операциите не само с
метаданните на файловете, но и със самите
данни.
В ext3fs са предвидени три режима на работа
– пълно протоколиране (full data journaling),
протоколиране с обратен запис (writeback),
а също и активираното по подразбиране
последователно протоколиране (ordered).
Режима на пълно протоколиране, както
лесно може да се досетим от името му, се
разпростира и върху метаданните, и върху
данните на файловете. Всичките техни
изменения отначало се записват в
журналния файл и чак след това се фиксират
на диска. В случай на аварийно спиране
на работата, може повторно да прочетем
журнала и да приведем данните и метаданните
в непротиворечиво състояние. Този
механизъм практически премахва загубите
на данни, но е най-бавният от трите режима
на работа.
В режима на отложен запис, обратно – в
журналният файл се записват само
измененията на метаданните на файловете,
подобно на всички разгледни по-надолу
файлови системи. Тоест той не дава
никаква гаранция за запазване на данните,
но осигурява най-голямото (в рамките на
ext3fs) бързодействие.
При последователният режим на работа,
физически се протоколират само метаданните
на файловете, но свързаните с тях блокове
данни логически се групират в общ модул,
наречен транзакция (transaction). И тези
блокове се записват преди записа върху
диска на нови метаданни, което макар и
да не гарантира запазване на данните,
твърде много спомага за това. При това
с по-малки допълнителни разходи в
сравнение с пълното протоколиране,
осигурявайки някакво междинно ниво на
бързодействие.
Но по мои наблюдения, ext3fs нито в един от
трите режима не може да се похвали с
висока производителност при изпълнение
на потребителските задачи. А в режим на
пълно протоколиране са възможни ситуации,
водещи за известно време до пълно
парализиране на машината.
XFS
Файловата система XFS, за
разлика от по-младите ReiserFS и ext3fs се
развива от фирмата SGI в продължение на
почти 10 години – за първи път тя се появи
във версията 5.3 на операционната система
Iris, която излезе през 1994 г. Но тя беше
портната за Linux сравнително неотдавна
(нейната текуща версия [4]
е 1.1, свободно достъпна на страницата
за XFS от сайта на SGI –
http://oss.sgi.com/projects/xfs)
и досега не се поддържаше от официалните
ядра [5].
XFS е единствената 64 разрядна файлова
система от разгледаните. Но нейната
уникалност не е само в
това. Особеностите на файловата система
XFS са:
използване на механизма allocation group –
разделяне на общият дисков дял на
няколко равни области, имащи собствени
списъци на информационните възли и
свободни блокове, за едновременно
изпълнение на дисковите операции;
логическо протоколиране само на
променените метаданни, но с чест запис
върху диска за минимизиране на възможните
загуби при евентуални сривове;
използване на механизма delayed allocation –
присъединяване на дисковото пространство
при запис на файла не по време на
протоколирането, а при фактическото
му прехвърляне върху диска, което заедно
с повишаване на производителността,
предотвратява и фрагментацията на
дисковият дял;
наличие на списъци за контрол на достъпа
(ACL – Access Control List) и разширени атрибути
на файловете (extended attributes), разглеждането
на които надхвърля рамките на тази
статия.
Като резултат от всичко това, XFS
представлява много
балансирана файлова система, която е
надеждна почти колкото ext3fs и не отстъпва
с много на ReiserFS в бързодействието на
повечето файлови операции. А при операции
с (много) големи файлове, тя е просто без
конкуренция – както може да се досетите
от името на компанията, която я е създала,
тя е предназначена за работа с мултимедийни
приложения с техните огромни потоци от
данни. Не са отбелязани и проблеми със
съвместимостта и с другите файлови
системи.
Всичко казано досега, позволява да се
направи извода, че XFS е оптималната
файлова система за Linux, но трябва да се
има предвид, че за разлика от ReiserFS и
ext3fs, поддръжката на които е стандартно
включена в ядрото на Linux, XFS и досега
(текуща версия на ядрото 2.4.19) не се
поддържа от каноничното ядро на Линус
Торвалдс (това, което може да изтеглите
от http://www.kernel.org).
Макар, че с неотдавнашното включване
на такава поддръжка в клон 2.5.Х на ядрото,
ни позволява да се надяваме, че скоро
тази функция ще стане стандартна.
Възможност за работа с XFS осигурява
специална кръпка (xfs-2.4.1X-all-i386.bz2), която
може да се изтегли от сайта на SGI,
заедно със съответните приложни програми
за нейната поддръжка – традиционните
средства e2fsprogs не са приложими към XFS.
Програмите за поддръжка на XFS са обединени
в няколко пакета, от които абсолютно
необходим е xfsprogs. За всичко това трябва
да се помни при предварителното разделяне
на диска.
Критерии за избор
По този начин, всяка от четирите разгледани
файлови системи има своя уникална
положителна особеност (даже и ext2fs –
както и да го разглеждаме, тя остава
лидер по общо бързодействие) и поне един
недостатък (който не пречи на нейното
използване). Така, че изборът на файлова
система трябва да се определя от задачите
на потребителя и характера на
преобладаващите му данни.
Освен това, ако, както се разказва в
статията за LVM,
разтоварим максимално коренната файлова
система, отделяйки в логически дялове
отделните и клонове, е възможно и
комбинирано използване на файловите
системи. Тоест за всеки дисков дял
избираме най-подходящата за неговото
съдържание управляваща структура.
Както нееднократно се споменаваше,
ext2fs е най-подходящият
избор за зареждащия дял (а при използване
на GRUB като програма за начално зареждане,
това е почти задължително). Освен това,
ext2fs е напълно подходяща за /tmp или /var
клоновете от главната директория (/). За
първата от тях, по дефиниция устойчивостта
към сривове на системата не е критична.
За втората, основното изискване е
бързодействието (например в source based
дистрибуции от типа на Gentoo /var се използва
за съхранение на временните продукти
от компилацията и бързодействието на
файловите операции в нея донякъде
ускорява компилацията на пакетите).
Накрая, на настолна машина, ext2fs може да
се приложи и за корена на файловата
система (/) – нали при разбиването на
диска на повече дялове, в корена остават
най-рядко променяните компоненти на
системата.
От друга страна, коренът на файловата
система е най-критичният по отношение
на устойчивостта елемент от файловата
система. И затова, най-оптимална за него
е файловата система ext3fs, като най-устойчива.
Освен това, в екстремни ситуации тя може
да бъде монтирана без проблеми като
ext2fs. За дяловете от типа /usr и /usr/local ext3fs
също изглежда напълно подходящ вариант.
Най-важната част на файловата система
на една настолна машина от гледна точка
на потребителя са неговите, потребителски
данни, които обикновено са разположени
в директорията /home (понеже системата
може да се преинсталира, а загубата на
данни може да се окаже невъзстановима).
Но тези данни са най-често променяната
част от файловата система, което поставя
високи изисквания към бързодействието
на файловите операции. И затова ext3fs не
е най-доброто (imho [6])
решение за директорията /home. По-целесъобразно
е за нея да използваме някоя от
бързодействащите журнални файлови
системи, ReiserFS или XFS. Изборът между тях
се определя от личните предпочитания
и вида на данните (ще се възползвам от
случая и ще отбележа, че от бързодействието
на JFS, по мои наблюдения, при типични
потребителски действия, има какво още
да се желае).
Очевидно, бързодействието на XFS при
работа с файлове с (много) голям размер
я прави предпочитана, ако става дума за
обработка на изображения, мултимедийно
съдържание, картографска информация и
т. н. В същото време, преимуществата на
ReiserFS се проявяват основно при работа с
файлове с (много) малка големина (по-малки
от един блок на файловата система),
каквито между потребителските данни
обикновено са малко [7].
И затова моето лично мнение е еднозначно
в полза на XFS. Освен това, собственият
ми опит в общуването с ReiserFS беше
неблагоприятен, особено в съчетание с
технологията LVM, докато XFS според моите
впечатления, идеално си хармонира с
нея.
Вече е време да теглим чертата – оптимално
за мен изглежда следното съчетание на
файлови системи:
ext3fs – за корена (/) на файловата система
и директорията /usr (и за /usr/local и /usr/X11R6,
ако те също ще се отделят в отделни
дялове);
ext2fs – за директорията за начално
зареждане /boot и директориите /tmp и /var;
XFS – за дяла с потребителските директории
(/home)
И пак ще повторя, че това е само мое
мнение, основано на опита от прилагането
на Linux на настолни машини – за различните
видове сървъри, то не е в сила.
ПРАКТИЧЕСКИ ПОСЛЕДСТВИЯ
Надявам се, че предишният раздел даде
достатъчно информация за правилен избор
на файлова система, най-подходяща за
конкретните условия. И затова вече може
да разгледаме накратко последователността
от действия, след като този избор е
направен.
Обикновено при инсталацията на Linux,
създаването на файловите системи е от
компетенцията на инсталатора, който го
осъществява с няколко възможности по
подразбиране. От контекста на разгледаното
в предишния раздел става ясно, че тези
опции не винаги са най-добрите от гледна
точка на потребителя. Да се променят
характеристиките, определени за файловата
система при нейното създаване е невъзможно
без повторно изпълнение на този процес
(и съответно, загуба на данни). Но всички
source based дистрибуции допускат ръчна
намеса в процеса на създаване на файловата
система, а например в Gentoo това е
единственият начин за нейното изпълнение.
Файловата система ext2fs може да бъде
създадена с всяка една от следните
команди – /sbin/mke2fs, /sbin/mkfs, /sbin/mkfs.ext2 с
указан файл на устройство в качеството
на аргумент, например:
$ /sbin/mke2fs /dev/hd?#
Всяка от тези команди (a /sbin/mkfs.ext2 е
символна връзка към /sbin/mke2fs) има редица
възможности, като:
-b за определяне размера на блока на
файловата система (възможни значения
са 1024, 2048 или 4096 байта, по подразбиране
е приета последната стойност);
-с за проверка на повредени участъци
от диска;
-N и -i за задаване на броя на информационните
възли и съответно количеството байтове
на един възел.
Подробно може да се запознаете с
възможностите на командите от съответните
man-страници, например man (8) mke2fs.
За създаване на файловата система ext3fs
може да се използва същата команда
mke2fs с опция -j, като в този случай тя ще
получи някои характеристики по
подразбиране. Ръчното им определяне
може да стане с помощта на командата:
$ /sbin/mke2fs -J опция_на_протоколиране
/dev/hd?#
Възможните стойности на опцията за
протоколиране са:
size=размер – задава размера на журналния
файл в мегабайтове и
device=външен_дневник – включва нова
файлова система към дневника,
предварително създадена на друг дисков
дял.
Може да използваме и специалната команда
/sbin/mkfs.ext3 – нейните възможности са
идентични на възможностите на командата
/sbin/mke2fs (и няма как да е другояче, тъй
като тя е символна връзка към нея). Но
най-интересното е възможността за
преобразуване на съществуващата файлова
система ext2fs към ext3fs не само без загуба
на данни, но и без рестартиране на
системата (даже и без демонтиране на
файловата система) чрез просто добавяне
на дневник към нея. Това става с командата:
$ tune2fs -j /dev/hd?#
Тя просто добавя файла на дневника
/.journal в главната директория на
модифицираната файлова система (ако
последната не е била демонтирана) или
стартира за него скрит информационен
възел (ако преди модификацията файловата
система е била демонтирана). Трябва да
добавя, че обратното преобразуване е
още по-лесно и се осъществява с командата
за монтиране (което ще се обсъжда в
следващата статия).
Файловата система ReiserFS се създава със
специално предназначена за това команда
– /sbin/mkreiserfs от пакета reiserfsprogs. Тази
команда има много възможности (-s за
създаване на големината
на дневника, -f за принудително
преформатиране на файлови системи от
друг тип и т. н.). с които може да се
запознаете с помощта на командата man
(8) mkreiserfs. И за избягване на неочаквани
проблеми, ще напомня, че ако коренният
дял се форматира като ReiserFS, няма да е
излишно да предвидим един малък дял за
директорията /boot и да го форматираме с
ext2fs.
За създаване на файловата система XFS
също съществува собствена команда
mkfs.xfs от пакета xfsprogs. В нея са предвидени
няколко опции, всяка от които има няколко
аргумента, приемащи числени значения.
Най-важните от тях са:
-b, която с помощта на аргумента size=## ни
позволява да зададем размера на блока
данни в байтове, който трябва да бъде
кратен на размера на страницата
оперативна памет (за платформата i386 –
4 kbytes) и може да варира в интервала от
512 до 65536 bytes (по подразбиране той е 4096
bytes);
-d – определя параметрите на областта
за данни на файловата система, такива
като брой на самостоятелните области
в дяла (Allocation groups, аргумент agcount) или
техният размер (аргумент agsize);
-l – определя параметрите на журналния
файл, например неговата големина (size).
При използване на mkfs.xfs за постигане на
максимална производителност,
се препоръчва в явен вид да се зададе
броя на allocation groups – в противен случай
то се определя автоматично, което води
до непроизводителен преразход на
ресурси. Определянето на този брой се
основава на допускането, че една
allocation group заема 4 GB дисково пространство.
След това може да установим и големината
на дневника – тук препоръчваното
значение е 32 MB, тоест за дисков дял с
големина 20 GB командата ще има следния
вид:
$ mkfs.xfs -d agcount=5 -l size=32m /dev/hda1
Освен всички изброени опции, командата
mkfs.xfs има и опция -f за принудително
създаване на файловата система XFS върху
вече съществуваща файлова система. За
нея е достатъчно тя да е била ext2fs (и воден
от общи съображения и ext3fs, макар, че не
съм го проверявал). Ако създаваме XFS
върху ReiserFS, са възможни грешки при
монтирането на новата файлова система.
Това се отнася и за обратната процедура
– при замяна на XFS с ReiserFS, а също и за
случаите, когато заменяме някоя от
“напредналите” файлови системи с
ext2fs. Тези проблеми са свързани с факта,
че командата за монтиране може да
разпознае новосъздадената XFS файлова
система като повредена ReiserFS и обратно.
За тяхното избягване, преди подобно
заместване се налага да прибегнем към
един малко шамански подход – да нулираме
началните области на дяла (съхраняващ
метаданните на файловата система) с
командата:
$ dd if=/dev/zero of=/dev/hd?#
Не е необходимо да чакаме запълването
с нули на цялото устройство – достатъчно
е да оставим командата да работи 10-20
sec, след което да прекъснем нейното
изпълнение с Control-D и да започнем
създаването на новите файлови системи.
И последното, което трябва да се спомене
– за swap дяла, създаден по време на
разделянето на диска. Макар, че той не
съдържа файлова система в себе си, той
има нужда от такава, която се създава с
командата
$ mkswap име_на_устройство
към която трябва да се подхожда с внимание
– прилагането и върху обикновен дял ще
унищожи всички данни върху него.
БИБЛИОГРАФИЯ
Много сложни въпроси около устройството
на файловите системи в тази статия бяха
засегнати само накратко. За по-подробна
информация за тях трябва да се обърнете
към допълнителни източници. Общата
организация на файловата система на
Unix се разглежда в много ръководства за
нея, например в С.
Д. Кузнецов, Операционная система UNIX.
Устройството на файловата система
ext2fs е подробно описано в статията на
Виктор Хименко “Файлове, файлове,
файлове”, (Мир ПК, 2000, част
1 – No 2; част
2 – No 3,).
Подробно описание на съвременните
журнални файлови системи, използвани
в Linux е дадено в цикъла статии на Даниел
Робинс, руският превод на които, направен
от Владимир Холманов, е достъпен на
сайта на Ярославската
група на потребителите на Linux
[8].
Превод: Николай
Ангелов
добре
зле
Вариант за отпечатване
