FreeBSD vs Linux: хуткадзейнасць файлавых сістэм

1. Мэты і задачы
2. Удзельнікі тэставання
3. Аб тэставай платформе
4. аб'екты тэставання
5. вынікі
6. UFS
7. Ext2fs
8. Ext3fs
9. ReiserFS
10. XFS
11. JFS
12. высновы

Аляксей Федарчук
2004 г.

Пры ўсіх нямераных вартасцях FreeBSD агульнапрызнана, што адным яна не можа пахваліцца - хуткадзейнасцю на файлавых аперацыях. Праўда, існуе меркаванне, што гэта звязана не з марудлівасцю яе файлавай сістэмы, а выключна з умолчальным рэжымам яе выкарыстання. Аднак ніякіх колькасных дадзеных я выявіць не змог, і таму вырашыў правесці ўласнае невялікае даследаванне.

Мэты і задачы

Спачатку я ставіў сабе вельмі абмежаваную задачу - вымераць хуткадзейнасць сучаснай файлавай сістэмы FreeBSD, UFS2, у розных рэжымах мантавання. Як вядома, па змаўчанні яна мантуецца ў т.зв. рэжыме noasync, пры якім змены метададзеных файлаў запісваюцца на дыск сінхронна, а для ўласна дадзеных прымяняецца асінхронная запіс, то ёсць кэшаванне. Што першапачаткова ставіць UFS2 у нявыгаднае (з пункту гледжання хуткадзейнасці) становішча ў параўнанні з Linux, дзе па змаўчанні для большасці файлавых сістэм, падтрымоўваных гэтай аперацыёнкай ў якасці натыўных, прыняты чыста асінхронны рэжым - з кэшаваннем не толькі дадзеных, але і метададзеных.

Аднак тэарэтычна чыста асінхронны рэжым існуе і ва FreeBSD, хоць выкарыстанне яго вельмі не рэкамендуецца ва ўсіх афіцыйных дакументах праекта, як якое спрыяе падзення надзейнасці. Што, безумоўна, дакладна для сервераў, але не здаецца гэтак ужо крытычным для дэсктопаў, аснашчаных бесперабойнік (а бесперабойнік, па маім сціплым меркаванні, - абавязковы атрыбут любой Unix-машыны, асабліва ва ўмовах постсавецкай рэчаіснасці). Так што паўстала натуральнае жаданне - паглядзець, а як паводзіць сябе UFS2 ў асінхронным рэжыме.

Адразу заўважу, што першыя ж вынікі вымярэнняў апынуліся некалькі нечаканымі і, па меншай меры для мяне - не зусім зразумелымі. І таму для высвятлення сітуацыі я вырашыў параўнаць іх з праведзенымі ў аналагічных умовах вымярэннямі для ext2fs у Linux. Ну а далей - болей, стала цікавым супастаўленне з іншымі файлавымі сістэмамі Linux. І, нарэшце, паўстала пытанне, а як гэтыя аперацыёнкі працуюць з файлавымі сістэмамі адзін аднаго. Паколькі падтрымка ў Linux UFS2 цяпер не рэалізаваная (ды і ўключыць падтрымку UFS проста - задача не трывіяльная), прыйшлося абмежавацца вымярэннямі толькі для ext2fs пад FreeBSD. Такім чынам і вызначыліся

Удзельнікі тэставання

Такім чынам, першым удзельнікам, натуральна, стала UFS2, адукаваная з параметрамі па змаўчанні sysinstall (памер блока - 16384 байт, памер фрагмента - 2048), з прадугледжаных гэтай утылітай уключэннем рэжыму SoftUpdates. І мантаваным ў умолчальном ж, гэта значыць часткова асінхронным (опцыя -o noasync, якая прымаецца па змаўчанні пры выкананні каманды mount) рэжыме.

Далей, зыходзячы з агульных меркаванняў, можна было меркаваць, што на хуткадзейнасць файлавых аперацый можа ўплываць таксама опцыя -o noatime, якая забараняе абнаўленне часу апошняга доступу для файлаў. Затым, зразумела, быў апрабаваны чыста асінхронны рэжым (опцыя -o async). І, нарэшце, спалучэнне абедзвюх опцый, ад якога тэарэтычна варта было чакаць максімальнага хуткадзейнасці.

У якасці аб'ектаў параўнання выступілі натыўнымі файлавыя сістэмы Linux. У першую галаву гэта, вядома, была класічная ext2fs, мантаваць у двух рэжымах - умолчальном і ў рэжыме -o noatime.

Затым - яе журналіруемые варыянт, ext3fs. Для яе штатна прадугледжана тры рэжыму выкарыстання - поўнага журналявання (опцыя -o data = journal), пры якім фіксуюцца аперацыі не толькі з метададзенымі файлаў, але і іх дадзенымі, стандартнага частковага журналявання (опцыя -o data = ordered, пры якой дадзеныя і метададзеныя групуюцца ў адзіны блок транзакцыі) і рэжыму writeback, у якім ніякага журналявання дадзеных не ажыццяўляецца. Ад выкарыстання опцыі -o noatime я ў дадзеным выпадку адмовіўся (шчыра кажучы, проста з ляноты - хоць, як стала ясным з вынікаў, нічога прынцыпова новага гэтая опцыя не дала б).

Далей - ReiserFS, самая прэтэнцыёзна (і, мабыць, найбольш папулярная сярод карыстальнікаў Linux) журналіруемая файлавая сістэма. Тут, акрамя умолчального, я зноў апрабаваў рэжым з адмовай ад абнаўлення atime - і, як паказала практыка, не дарма).

Аналагічна я зрабіў і з XFS - вымярэння на ёй вырабляліся ў умолчальном рэжыме і ў рэжыме з опцыяй -o noatime. І, нарэшце, у дачыненні да JFS я абмежаваўся рэжымам па змаўчанні - так як гэтай сістэмай ніколі практычна не карыстаўся, мала чаго пра яе ведаю і прыцягнуў яе да справы выключна для параўнання.

Ўсе файлавыя сістэмы ствараліся з дапамогай адпаведных утыліт (mke2fs - для ext2fs і ext3fs, mkreiserfs і mk.xfs - для аднайменных файлавых сістэм, jfs_mkfs - для JFS) з параметрамі па змаўчанні. Выключэннем стала XFS, для якой памер allocation group і аб'ём часопіса былі падабраныя ў адпаведнасць з рэкамендацыямі Дэніэла Роббінса (аб'ём часопіса - 32 Мбайт, мінімум адна allocation group на 4 Гбайт дыскавай прасторы, які адводзіцца пад гэтую файлавую сістэму).

Пры любым вымярэнні хуткасці файлавых аперацый заўсёды ўзнікае падступны пытанне - а што ж на самай справе мы мераем, прадукцыйнасць файлавай сістэмы або проста фізічнае хуткадзейнасць дыска, а таксама эфектыўнасць працы АС з адпаведнымі дыскавымі інтэрфейсамі. Таму неабходна сказаць некалькі слоў

Аб тэставай платформе

Вымярэння вырабляліся на падручным жалезе, якое ўтрымлівала:

• працэсар Pentium-4 / 2,53 Ггц, FSB 533, без HT;
• матчына плата Albatron PX845PE на аднайменным чыпсэце, у варыянце з дадатковым кантролерам ATA RAID / SerialATA Promise FastTrack 376 (зрэшты, не задзейнічаным);
• 1 Гбайт аператыўнай памяці (2 × 512 PC-2700, які прадаваў пад брэндам «нібыта Samsung»);
• жорсткі дыск Seagate Barracuda IV 40 Гбайт, інтэрфейс ParallelATA, 7200 аб. / мін., падлучаны як single на 1-й канал стандартнага ATA-кантролера з паўднёвага моста ICH4.

Іншыя кампаненты, тыпу CD-ROM (single на другім IDE-канале), значэння ў дадзеным выпадку не маюць.

На дыску мелася 4 першасны падзелу. Першы, аб'ёмам 30 Мбайт з файлавай сістэмай ext2fs, выконваў функцыі загрузнага і нёс на сабе толькі GRUB (і ядро ​​Linux). Другі раздзел быў вызначаны як BSD-слайс, і ў ім, на файлавай сістэме UFS2, размяшчалася FreeBSD 5.2.1. Трэці раздзел быў абвешчаны DOS Extended і нёс на сабе Archlinux 0.6 (ядро 2.6.6). Дэталі іх разбіцця, а таксама файлавыя сістэмы, у дадзеным кантэксце не істотныя.

Ць аб пазбяганне непаразуменняў заўважу, што ў абедзвюх АС дыск функцыянаваў у штатным рэжыме UDMA100, што вызначалася ўтылітамі atacontrol ва FreeBSD і hdparm ў Linux.

І яшчэ: FreeBSD была падвергнутая працэдуры make world са сцягамі аптымізацыі -O1 і -march = pentium4. Ядро, перасабраў на базе вельмі палегчанага GENERIC (з выключэннем падтрымкі ўсяго адсутнага, тыпу SCSI і сеткавых карт), кампіляваць са сцягам -O2 пад той жа Pentium-4. Для Archlinux выкарыстоўвалася штатны прадкампіляванае (з рэпазітара праекта - current) ядро, сабранае, як і ўся сістэма ў цэлым, са сцягамі -O2 -march = i686.

Зрэшты, усё сказанае ў папярэднім абзацы наўрад ці здольна было кардынальна паўплываць на прадукцыйнасць пры файлавых аперацыях. І таму для нас важны толькі чацвёрты першасная частка, аб'ёмам 5,5 Гбайт, які і падвяргаўся усялякім здзекаванням. Для чаго на ім, пасля прысваення адпаведнага ідэнтыфікатара (4.2BSD або Linux native, адпаведна), на ім ствараліся пералічаныя ў папярэднім раздзеле файлавыя сістэмы, якія мантаваліся з названымі опцыямі. А на іх ужо змяшчаліся тыя дадзеныя, якія прадстаўлялі сабой

аб'екты тэставання

Вымярэння я ладзіў для асабістых мэтаў, і таму мяне больш за ўсё цікавілі аперацыі з тымі дадзенымі, з якім я маю справу рэгулярна. А гэта а) масівы змешаных дадзеных (тэксты і ілюструе іх графіка), б) масівы з велізарнай колькасці вельмі маленькіх файлаў (тыпу дрэва портаў FreeBSD і аналагічных сістэм кіравання пакетамі з Source Based дыстрыбутываў Linux) і в) вялікія файлы, ад аб'ёму CD і вышэй. У адпаведнасць з гэтым я і падабраў тэставыя аб'екты.

Па-першае, гэта быў каталог маіх працоўных матэрыялаў - файлаў у фарматах plain text і html з ілюстрацыямі ў фарматах gif, tiff, jpeg, png, аб'ём якіх вар'іраваў ад некалькіх кілабайт да першых дзясяткаў мегабайт. Для ажыўлення карціны я развёў яго гукавымі файламі mpeg (ад 1,5 да 6 Мбайт кожны). У выніку першы тэставы масіў сумарна склаў 830 Мбайт.

Другім аб'ектам было падручнае дрэва портаў FreeBSD ад 6 траўня 2004 г., аб'ёмам 24,2 Мбайт, і вынік яго «растаривания», што давала каталог у 124 Мбайт. Спецыфіка яго - у тым, што ён утвораны велізарным (звыш 100 тысяч) колькасць файлаў, пераважны памер якіх - некалькі сот байт.

Нарэшце, трэцім аб'ектам стаў avi-файл памерам у CD - 693 Мбайт.

Нічога лепшага, чым вымяраць час капіявання гэтых масіваў, я не прыдумаў. Гэта значыць каталог дадзеных капіяваўся камандай выгляду

$ Cp data newdata

з наступным знішчэннем мэтавага каталога

$ Rm -Rf newdata

і замераў часу кожнай аперацыі пасродкам высновы каманды date да і пасля яе. Аналагічна я паступаў і з вялікім файлам. А тарбалл портаў папярэдне разгортваўся камандай

$ Tar xzvf ports.tar.gz

час чаго таксама замяралася - гэта ж не толькі хуткасць дэкампрэсіі і разархіваціі, якая залежыць ад хуткадзейнасці працэсара, але і хуткасць інкарпарацыі выніку ў файлавую сістэму. У мэтах палягчэння жыцця аперацыі над кожным аб'ектам выконваліся з прасценькага скрыпту выгляду

date >> file_of_result && command1 && date >> file_of_result && ... date >> file_of_result &&

Усе тры тэсты для кожнай файлавай сістэмы ў кожным рэжыме выконваліся тройчы. Па завяршэнні цыкла файлавая сістэма размантаваць і перад паўторам мантавалася нанова. У якасці выніковых прымалася сярэдняе арыфметычнае з трох значэнняў.

вынікі

Вынікі вымярэнняў хуткасці выканання ўсіх аперацый над трыма аб'ектамі прыведзены ў табліцы і на мал. 1-3. Адзінкі вымярэння - секунды, адпаведна, меншыя значэння ўсюды адказваюць лепшым паказчыках. Якія мы і разгледзім паслядоўна для ўсіх файлавых сістэм.

UFS

Пачнем з той, што паслужыла першапрычынай гэтай нататкі - з UFS2. Нагадаю, што яна мантавалася паслядоўна ў чатырох рэжымах - умолчальном, з уключэннем опцыі -o noatime, у чыста асінхронным рэжыме (опцыя -o async) і, нарэшце, з уключэннем абедзвюх гэтых опцый. Тэарэтычна разважаючы, у гэтым парадку і павінна ўзрастаць хуткадзейнасць файлавых аперацый. Што ж мы бачым на практыцы?

Табліца. Вынікі вымярэння (у сек.) Хуткадзейнасці файлавых аперацый у розных файлавых сістэмах

тэст

Праца з дадзенымі

Праца з партамі

вялікі файл

FS + Mode

Copy

Delete

Untar

Copy

Delete

Copy

Delete

UFS, default

211

7

189

255

92

104

0

UFS, noatime

210

7

194

333

99

102

0

UFS, async

211

8

201

352

99

103

0

UFS, both

209

6

202

344

98

103

0

Ext2, FreeBSD

222

25

280

309

222

150

1

Ext2, default

71

6

90

68

7

45

0

Ext2, noatime

73

6

93

68

7

46

0

Ext3, journal

123

6

134

58

6

98

1

Ext3, ordered

81

15

107

115

17

50

16

Ext3, writeback

91

7

107

68

51

53

1

Reiser, default

100

2

59

51

7

44

1

Reiser, noatime

89

2

71

26

7

47

1

XFS, default

95

9

76

83

41

48

0

XFS, noatime

97

9

80

74

42

49

0

JFS, default

132

13

267

160

19

91

0

Вынікі па капіяванні масіва дадзеных (гл. Мал. 1) ва ўсіх чатырох рэжымах можна лічыць практычна ідэнтычнымі. Здавалася б, ледзь лепшыя вынікі дазваляе атрымаць адмову ад абнаўлення atime, аднак і абсалютна, і адносна розніца нікчэмная. І ў любым выпадку, ўключэнне асінхроннага рэжыму не забяспечвае ніякага скачка ў хуткадзейнасці, якога можна было б чакаць, зыходзячы з агульных меркаванняў. Хуткасць выдалення змешанага масіва файлаў таксама прыкладна аднолькавая: некалькі лепшыя вынікі пры ўключэнні абедзвюх опцый ляжаць, хутчэй за ўсё, у межах памылкі эксперыменту (дакладнасць высновы каманды date - у межах адной секунды).

Мал. 1. Праца з масівам змешаных дадзеных

Яшчэ больш уражлівы графік дэманструюць вынікі працы з дрэвам партоў (мал. 2). Тэарэтычна можна было б чакаць рэзкага скачка хуткадзейнасці пры асінхроннай апрацоўцы велізарнай колькасці дробных файлаў. Аднак на практыцы мы бачым прама процілеглы карціну: найлепшыя вынікі і пры разгортванні тарбалла, і пры капіяванні дрэва портаў, і пры яго выдаленні атрымліваюцца як раз пры умолчальном, сінхронным для метададзеных, рэжыме. Прычым у выпадку капіявання перавагу яго выглядае цалкам значным: ўключэнне любы з дадатковых опцый (а асабліва - іх абедзвюх) выклікае падзенне хуткасці гэтай аперацыі на 30-50%.

Мал. 2. Праца з дрэвам партоў

Капіяванне вялікага файла - адзіная аперацыя, дзе умолчальный рэжым паказвае як быццам бы самыя горшыя вынікі (мал. 3). Аднак розніца і ў абсалютных велічынях, і ў адносных выглядае проста смяхотна. І, хутчэй за ўсё, зноў жа мае прычынай натуральны роскід у межах памылкі. Ну а выдаленне адзінкавага файла, як і варта было чакаць, адбываецца практычна імгненна (хоць, як мы ўбачым далей, і гэта - не само сабой разумеецца назіранне).

Мал. 3. Праца з вялікім файлам

Асабіста я бачу адно тлумачэнне назіранай карціне: асінхронны рэжым пры мантаванні сучаснай файлавай сістэмы FreeBSD - не больш чым фікцыя, і на самай справе метададзеныя ў любым выпадку апрацоўваюцца сінхронныя. Ну і ў любым выпадку можна толькі парадавацца за распрацоўшчыкаў гэтай АС: прапанаваны імі умолчальный рэжым мантавання забяспечвае ці лепшыя, або практычна не горшыя вынікі, чым любыя іншыя, якія патрабуюць дадатковых опцый і, адпаведна, лішніх рухаў цела.

Мінус гэтага - тое, што рэзерваў павышэння хуткадзейнасці файлавых аперацый ва FreeBSD не знаходзяцца. Паглядзім ж цяпер, што мы губляем, адмаўляючыся ў яе карысць ад Linux з яго шматлікімі файлавымі сістэмамі.

Ext2fs

Пачнем ізноў жа з класікі жанру - традыцыйнай ext2fs. Пры капіяванні масіва змешаных дадзеных яна паказвае зайздроснае хуткадзейнасць, больш чым у тры разы праўзыходнае хуткасць гэтай аперацыі ў UFS2, пры супастаўнай (але фармальна лепшай) хуткасці выдалення. Калі ж адцягнуцца ад абсалютных лічбаў, можна бачыць, што ўключэнне опцыі noatime і тут, насуперак чаканню, нічога не дае ў плане прадукцыйнасці.

Тая ж карціна назіраецца ў цесцю з дрэвам партоў. І разгортванне тарбалла, і капіраванне каталога дробных файлаў, і яго выдаленне адбываюцца аднолькава хутка па-за залежнасці ад таго, абнаўляецца Ці час апошняга доступу ці не. Адносна UFS2 гэта самае «хутка» выяўляецца двух- (для аперацыі «растаривания») і нават пяці-(для капіявання) кратным перавагай. Ну а выдаленне дрэва портаў наогул больш чым на парадак хутчэй - фактычна такое ж хуткае, як і выдаленне змешанага масіва.

Пры працы з вялікім файлам таксама ніякіх нечаканасцяў не назіраецца: капіюецца ён хутка (больш чым у два разы хутчэй, чым у UFS2), а выдаляецца практычна імгненна.

Увогуле, даводзіцца з жалем канстатаваць, што ў плане хуткадзейнасці UFS2 і блізка не ляжала з ext2fs, чым бы гэта ні тлумачылася (desktop-карыстачу гэтыя тлумачэнні па вялікім рахунку да лямпачкі). І таму цікава паглядзець, а не праявіць ці сябе ext2fs з гэтак жа добрага боку таксама і ва FreeBSD?

Зноў жа, як гэта ні сумна, не праявіць. Змантаваная па змаўчанні, яна пад гэтай АС дэманструе проста правальны хуткадзейнасць. Дакладней, поўнае яго адсутнасць - вынікі па ўсіх тэстаў горш (а ў дачыненні да партоў і вялікага файла - шмат горш), чым для роднай UFS2. Прычым паказальна, што нават сваёй добрай хуткасці выдалення файлаў яна тут не захоўвае, прымудрыўшыся ледзь-ледзь вылучыцца нават пры спробе ачысціць адзінкавага вялікага файла.

Вядома, ext2fs па самой сваёй прыродзе не можа быць такі ж надзейнай, як UFS2. І яе патэнцыйную схільнасць да разбурэння (а былі часы, калі ext2fs амаль гарантавана бурылася пры аварыйным завяршэнні працы сістэмы) спрабуе скампенсаваць наладжваць яе журналіруемые, прыкручваньне якой дае самастойную файлавую сістэму - ext3fs. Паглядзім, дорага ці прыходзіцца плаціць за гэта ў плане хуткасці.

Ext3fs

Як ужо гаварылася, у ext3fs прадугледжана тры рэжыму мантавання - з поўным журналяваннем метададзеных і дадзеных, з поўным журналяваннем метададзеных і частковым дадзеных (на самай справе гэта не зусім строга, але па дэталі рэжыму ordered прапаную звярнуцца да спецыяльных крыніцах), і без усялякага журналявання дадзеных наогул. У афіцыйнай дакументацыі па ext3fs сцвярджаецца, што надзейнасць сістэмы падае ў парадку пералічэння, а хуткадзейнасць, наадварот, узрастае. Адпаведна, па змаўчанні ext2fs мантуецца ў тым рэжыме, які распрацоўшчыкі лічаць прамежкавым ў абодвух адносінах, гэта значыць у рэжыме ordered.

Пытанні надзейнасці мы тут не абмяркоўваем, а вось што тычыцца хуткадзейнасці ... Пры капіяванні масіва змешаных дадзеных рэжым journal сапраўды аказваецца найбольш павольным, аднак першынство застаецца за рэжымам ordered (а не writeback, як варта было б чакаць). А вось сціранне вынікаў гэтага капіявання наогул паказвае парадаксальную карціну: калі пры рэжымах journal і writeback хуткасць выдалення каталога чакана хуткая (практычна такая ж, як у ext2fs), то ў рэжыме ordered гэтая працэдура выконваецца проста непрыстойна павольна (15 секунд супраць 6-7, як можна бачыць з табліцы).

Разгляд працы з дробнымі файламі пакідае вельмі супярэчлівае адчуванне. Разгортванне архіва - найбольш павольна ў рэжыме поўнага журналявання, і некалькі хутчэй (і аднолькава) - у абодвух рэжымах журналявання частковага. З капіяваннем дрэва портаў нечакана лепш за ўсё спраўляецца рэжым journal, рэжым writeback аказваецца некалькі павольней, а ordered гэтую задачу проста правальвае - хуткасць аперацыі выдалення аказваецца ў ім удвая ніжэй астатніх.

Далей - больш: графік хуткасцяў выдалення дрэва портаў проста звярнуць тэарэтычна чаканага: бліскучы вынік у рэжыме поўнага журналявання (6 секунд - ледзь не лепш, чым для ext2fs), пасрэдны (17 секунд) - у рэжыме ordered, і найгоршы для ўсіх файлавых сістэм Linux (51 секунда) - у нібыта больш хуткім рэжыме writeback.

Нарэшце, зварот з вялікім файлам дае нам чарговую (ужо чаканую) нечаканасць: размеркаванне хуткасцяў капіявання паўтарае такое для дрэва портаў (лепшы вынік - у рэжыме ordered, горай, але блізкі - у рэжыме writeback, і істотна горшы - у рэжыме journal, 50, 53 і 98 секунд, адпаведна). Але затое пры выдаленні гэтага самага вялікага файла рэжым ordered вызначыўся як ніхто: у ім гэтая працэдура заняла аж 16 секунд. Не проста горш за ўсіх, а недасягальна горш. І яшчэ раз падкрэслю, што гаворка ідзе не пра выпадковы воплеску, а аб сярэдняй з трох вымярэнняў, падзеленых перемонтированием файлавай сістэмы.

Як будзе відаць з далейшага, ext3fs з пункту гледжання хуткадзейнасці наогул глядзіцца бледнавата на фоне іншых файлавых сістэм, з якімі працуе Linux. Але супраць FreeBSD яна ўсё роўна захоўвае перавага па ўсіх пазіцыях: намаганнямі ўсіх трох рэжымаў журналявання першапачатковую ext2fs не ўдаецца зьвесьці да ўзроўню часткова сінхроннай UFS2. І нават горшы вынік ext3fs пры працы з партамі застаецца недасягальных для той АС, у якой сама ідэя партоў з'явілася ўпершыню.

Аднак, кажучы пра партах, я некалькі забег наперад. Таму што спачатку варта было б паглядзець, а якая файлавая сістэма трымае першынство ў працы з вялікай колькасцю маленькіх файлаў?

ReiserFS

Гэта файлавая сістэма першапачаткова праектавалася (у тым ліку і) для эфектыўнага абыходжання з вялікай колькасцю маленькіх файлаў - у прыватнасці, эканоміі займанага імі прасторы для. Аднак цяпер нас цікавіць хуткадзейнасць - і для ўсіх файлаў наогул. Так што пачнем з масіва змешаных дадзеных.

І тут мы ўпершыню бачым ўрачыстасць тэарэтычных прадказанняў: умеранае хуткадзейнасць пры капіяванні нашага масіва ў рэжыме па змаўчанні павялічваецца на 10% пры ўключэнні рэжыму noatime - са 100 секунд да 89 (хоць і не дасягае рэкорднага). Але затое рэкорд б'е выдаленне капіяванага масіва - па 2 секунды ў кожным з рэжымаў.

Дрэва портаў ... Цудоўныя вынікі пры «растаривании» і капіяванні ў умолчальном рэжыме. Пры адмене абнаўлення atime ў першым выпадку яны некалькі пагаршаюцца. Але затое - брава - капіяванне з гэтай опцыяй ажыццяўляецца практычна ўдвая хутчэй, чым без яе; такога выніку мы яшчэ не бачылі. І зноў ReiserFS блізкі да рэкорду пры выдаленні партовага бязладдзі - финишируя галава ў галаву з ext2fs.

І апошняя нечаканасць ад стварэння Ханса Райзера - у капіяванні вялікай файла яно паказвае сябе ў ліку лепшых, хоць тут ўплыў noatime і не адбіваецца. Паглядзім, ці зможа пацягацца з гэтым XFS, якая, наадварот, паводле задумы меркавалася менавіта для захоўвання мультымедыйнай інфармацыі.

XFS

На масіве дадзеных агульнага характару капіраванне дае вынік, блізкі да гарманічнага сярэдняму, час жа выдалення іх здаецца ледзь-ледзь завышаных (9 секунд).

Праца з партамі - на сярэднім узроўні ў дачыненні «растаривания» і капіявання. І - нечакана вялікі час выдалення дрэва портаў (больш за 40 секунд), якое набліжалася да «анты-рэкорду» writeback-рэжыму ext3fs (хоць усё роўна шмат лепшае, чым для UFS2).

А вось вынік па вялікім файлу (48-49 секунд) - не пацешыў: хоць ён і ў ліку лепшых, але ад «мультымедыйнай» файлавай сістэмы я чакаў большага. Хоць, можа быць, з пункту гледжання SGI, гэта 700 Мбайт - гэта зусім не шмат? І ў суцяшэнне - правалу пры выдаленні вялікага файла таксама не адзначаецца :-).

JFS

Эпонім журналіруемых файлавых сістэм выступае ў нашым заліку па-за конкурсам - прычынах, пра якія казаў вышэй. І вынікі паказалі, што гэта было цалкам апраўдана. Бо мы маем:

• горшы сярод усіх файлавых сістэм Linux вынік у капіяванні змешанага масіва і другі з канца (пасля правалу ordered-рэжыму etx2fs) - у яго выдаленні;
• горшы вынік «растаривания» сярод усіх натыўных файлавых сістэм наогул, уключаючы UFS2; горш апынулася толькі ext2fs з пад FreeBSD - але ж з чужынца і ўжо нічога не возьмеш;
• прама скажам, не бліскучае час выдалення дрэва портаў;
• капіяванне вялікага файла - фініш у шчыльнай групе адстаючых.

Увогуле, JFS, адзінай з падтрымоўваных Linux файлавых сістэм, апынулася супастаўнай з UFS2 па хуткадзейнасці (дакладней, адсутнасці гэтага). Вядома, нельга выключыць, што знаўцы яе могуць павысіць прадукцыйнасць якімі-небудзь опцыямі; у прыватнасці, я дзесьці чуў, што Linux-версія JFS стандартна працуе ледзь не ў чыста сінхронным рэжыме - гледзячы на ​​вынікі, у гэта цалкам можна паверыць. Аднак, паўтараю, па змаўчанні яна паўстае перад карыстачом у якасці самай павольнай.

высновы

Павінен сказаць, што праведзеныя вымярэння істотна перавярнулі мае ўяўленні пра файлавыя сістэмы наогул (хоць сёе ў чым і ўмацавалі).

У прыватнасці, я заўсёды падазраваў, што абедзве файлавыя сістэмы FreeBSD - і старая UFS, і новая UFS2, - саступаю сваім Linux'ов сёстрам у хуткадзейнасці. Ды гэта звычайна відаць і, што называецца, органалептычна. Аднак я ніяк не чакаў, што для UFS2 ў колькасных адносінах адставанне апынецца гэтак істотным. Павінен заўважыць - што выконваліся мной раней вымярэння для UFS проста гэтак ашаламляльнай тормознутості не паказвалі - нават у дачыненні да ext2fs (для ReiserFS меншы разрыў можна было б растлумачыць немаўляці тады яе узростам). Не выключана, што гэта - адплата і за 64-бітную адрасаванне, і за удвая павялічаныя inodes ...

Далей, я не чакаў гэтак годных вынікаў ReiserFS не толькі ў дачыненні да вельмі маленькіх файлаў, але і ва ўсіх астатніх тэстах. Так што бяру назад усе не вельмі добрыя словы, якія раней казаў у яе адрас. Праўда, неправераных засталося эмпірычнаму назіранае (але не пацвярджаюць колькасна) з'ява падзення яе прадукцыйнасці на вялікіх (больш за 100 Гбайт) раздзелах, размешчаных на праграмным RAID - але для многіх Ці desktop-карыстальнікаў гэта актуальна?

Не паказала сябе ў чаканай бляску i гэтак каханая мною раней XFS. Ўсё ж мала калі прыходзіцца працаваць з файламі больш аб'ёму сидюшника, а ў гэтых межах яна апынулася не хутчэй ReiserFS.

А вось у чым вымярэння мяне ўмацавалі - дык гэта ў прадузятасці (і неспрыяльным) дачыненні да ext3fs. І справа нават не ў тым, што хоць якім-небудзь яе рэжым «вызначыўся» хоць бы на адным тэсце. Незадаволенасць выклікае менавіта непрадказальнасць яе паводзін у залежнасці ад рэжыму і характару дадзеных. Верагодна, распрацоўшчыкі мелі падставы для заключэння аб аптымальнасці рэжыму ordered - аднак засноўваліся яны, мяркуючы па ўсім, на задачах серверных, але зусім не дэсктопных.

Так якую ж файлавую сістэму абраць простаму настольным карыстачу для сваёй асобна ўзятай персаналкі? Мой адказ не будзе бліскаць арыгінальнасцю, калі я заяўлю з усёй пэўнасцю: кожнаму гародніна - свой фрукт. І бескарысна спрабаваць знайсці сістэму, аднолькавы хуткую і для захоўвання дрэва портаў (або іх Linux-аналагаў), і для зборкі iso-вобразаў пад рэзервовае капіраванне, і іншая, і іншая, і іншая.

На шчасце, карыстальнік FreeBSD пазбаўлены ад гэтых пакут - UFS і UFS2 сутнасць аб'ектыўныя рэальнасці, дадзеныя яму ў адчуваннях беркліанскіх распрацоўшчыкаў. Толькі ён павінен разумець, што, прынамсі, пры працы з файламі яму прыйдзецца паступіцца хуткадзейнасцю дзеля складнасці і акуратнасці выкарыстоўванай сістэмы. Зрэшты, ці не кампенсуецца страта часу на капіяванні файлаў адсутнасцю пакут з несупадзеннем версій бібліятэк або кампілятараў?

А вось карыстачу Linux ёсць над чым паламаць галаву. Таму што адназначна я не рэкамендаваў бы да ўжывання толькі JFS - ды і тое, не факт, што, прачытаўшы многопудовую дакументацыю да яе, я быў бы гэтак катэгарычны (іншая справа, што пакуль ні адна з асаблівасцяў гэтай файлавай сістэмы не здольная падштурхнуць мяне на такое чытанне, тым больш па англицки).

Бо нават нялюбай мною ext3fs можна знайсці прымяненне. У прыватнасці, для каранёвай файлавай сістэмы ў тым выпадку, калі зь яе ў асобныя галіны вынесеныя / var, / usr, / opt (калі ў дадзеным дыстрыбутыве задзейнічаецца актыўна), і, вядома ж, / home.

Для першых трох галін прыдатнай бачыцца ReiserFS. Асабліва калі ў нас - Source Based дыстрыбутыў, які выкарыстоўвае якую-небудзь портападобных сістэму. І дарэчы - ідэальнай яна апынецца менавіта тады, калі дрэва гэтых портоидов вынесена ў асобную галіну усярэдзіне / usr ці / var. А яшчэ вымярэння схілілі мяне да думкі, што і для / home ReiserFS больш чым прыдатная - раней я нічога, акрамя XFS, у гэтай якасці не прызнаваў. Хоць і зараз не бачу прычын, чаму б высакароднаму дону не размяшчаць на XFS свае дадзеныя - асабліва калі ён не мае звычкі часта і ў вялікай колькасці іх выдаляць.

Нарэшце, ext2fs - зусім не горшы выбар для многіх карыстальнікаў, якія не жадаюць затлумляцца стварэннем мноства раздзелаў і падборам пад іх ідэальных файлавых сістэм (пры ўмове наяўнасці бесперабойнік, зразумела). І ўжо зусім незаменнай яна аказваецца а) для абмену дадзенымі з усталяванай на той жа машыне FreeBSD, і б) для падзелу / boot у выпадку выкарыстання мультізагрузчіка GRUB. Так што і бабульку ext2fs рана яшчэ спісваць ў тыраж ...