LXF167:ZFS on Linux

Текущая версия на 04:12, 10 ноября 2018 (просмотреть исходный код) Olkol (обсуждение | вклад) (Новая страница: «Категория: Главное в мире Linux == ZFS on Linux: == '''При­ме­ним на де­ле''' ''Алек­сей Фе­дор­чу…»)

---

Текущая версия на 04:12, 10 ноября 2018

Содержание 1 ZFS on Linux: 1.1 Соз­да­ем про­стой пул 1.2 «Из­бы­точ­ные» пу­лы 1.3 Пул кэ­ши­руе­мый 1.4 Об оп­ци­ях ко­ман­ды zpool 1.5 Соз­дание фай­ло­вых сис­тем 1.6 Фай­ло­вые сис­те­мы: свой­ст­ва 1.7 О пе­ре­мон­ти­ро­вании 1.8 Вместо заключения

[править] ZFS on Linux:

При­ме­ним на де­ле

Алек­сей Фе­дор­чук дор­вал­ся-та­ки на­ко­нец до вне­дре­ния ZFS on Linux на на­столь­ной ма­ши­не.

В пре­ды­ду­щей ста­тье, осво­ив основ­ные по­ня­тия, мы нау­чи­лись понимать ZFS. Для об­рат­ной же за­да­чи – что­бы ZFS понима­ла нас – нуж­но оз­на­ко­мить­ся с ее ко­ман­да­ми.

[править] Соз­да­ем про­стой пул

Глав­ных команд – две: zpool для соз­дания и управ­ления пу­ла­ми и zfs для соз­дания и управ­ления на­бо­ра­ми дан­ных. Не мно­го, прав­да? Впро­чем, ка­ж­дая из этих команд вклю­ча­ет мно­же­ст­во суб­команд, в ко­то­ры­х мы со вре­менем раз­бе­рем­ся.

Оче­вид­но, что ра­бо­ту с ZFS сле­ду­ет на­чи­нать с соз­дания пу­ла хранения. Нач­нем с это­го и мы. В про­стей­шем слу­чае од­но­дис­ко­вой кон­фи­гу­ра­ции это де­ла­ет­ся так:

# zpool create tank dev_name

Здесь create – суб­ко­ман­да оче­вид­но­го на­знач­ня, tank – имя соз­да­вае­мо­го пу­ла (оно обыч­но да­ет­ся в при­ме­рах, но на са­мом де­ле мо­жет быть лю­бым – с уче­том со­гла­шений ZFS), а dev_name – имя уст­рой­ст­ва, вклю­чае­мо­го в пул. Ка­ко­вое мо­жет стро­ить­ся по лю­бой из опи­сан­ных ранее мо­де­лей. И, что­бы да­лее не по­вто­рять­ся, на­пом­ню: все ко­ман­ды по манипу­ля­ции с пу­ла­ми и на­бо­ра­ми дан­ных в них вы­пол­ня­ют­ся от ли­ца ад­минист­ра­то­ра.

В слу­чае, ес­ли в со­став пу­ла вклю­ча­ет­ся один диск, а вто­ро­го не пред­ви­дит­ся, мож­но ис­поль­зо­вать имя уст­рой­ст­ва верхнего уров­ня – на­при­мер, sda для цель­но­го уст­рой­ст­ва (об­ра­тим внимание, что путь к фай­лу уст­рой­ст­ва ука­зы­вать не нуж­но). Од­на­ко ре­аль­но та­кая си­туа­ция ма­ло­ве­ро­ят­на: за­груз­ка с ZFS про­бле­ма­тич­на, так что как минимум по­тре­бу­ет­ся раз­дел с тра­ди­ци­он­ной фай­ло­вой сис­те­мой под /boot (и/или под ко­рень фай­ло­вой ие­рар­хии), так что ко­ман­да при­мет вид

# zpool create mypool sda2

Од­на­ко ес­ли мож­но ожи­дать в дальней­шем под­сое­динения но­вых на­ко­пи­те­лей и их вклю­чения в су­ще­ст­вую­щий пул, то луч­ше восполь­зо­вать­ся именем по мо­де­ли by-id, на­при­мер:

# zpool create mypool ata-ata-ST3500410AS_5VM0BVYR-part2

Оче­вид­но, что в слу­чае од­но­дис­ко­во­го пу­ла ни о ка­кой из­бы­точ­но­сти го­во­рить не при­хо­дит­ся. Од­на­ко уже при двух дис­ках воз­мож­ны ва­ри­ан­ты. Пер­вый – соз­дание пу­ла без из­бы­точ­но­сти:

# zpool create mypool dev_name1 dev_name2

где dev_name1 и dev_name1 – име­на уст­ройств в при­ня­той мо­дели име­но­вания.

В при­ве­ден­ном слу­чае бу­дет соз­да­но нечто вро­де RAID’а ну­ле­во­го уров­ня, с рас­ще­п­лением [stripping] дан­ных на оба уст­рой­ст­ва. Ка­ко­вы­ми мо­гут быть как дис­ко­вые раз­де­лы, так и дис­ки це­ли­ком. При­чем, в от­ли­чие от RAID0, дис­ки (или раз­де­лы) не обя­за­ны быть оди­на­ко­во­го раз­ме­ра:

# zpool create mypool sdd sdf

По­сле че­го ника­ких со­об­щений не по­сле­ду­ет. No news – good news, го­во­рят анг­ли­чане; в дан­ном слу­чае это оз­на­ча­ет, что пул был бла­го­по­луч­но соз­дан. В чем мож­но немед­лен­но убе­дить­ся дву­мя спо­со­ба­ми. Во-пер­вых, в корневом ка­та­ло­ге по­яв­ля­ет­ся точ­ка его мон­ти­ро­вания /mypool. А во-вто­рых, этой це­ли по­слу­жит суб­ко­ман­да status:

# zpool status mypool

ко­то­рая вы­ве­дет не­что вро­де та­ко­го:

pool: mypool

state: ONLINE

scan: none requested

config:

NAME STATE READ WRITE CKSUM

mypool ONLINE 0 0 0

sdd ONLINE 0 0 0

sdf ONLINE 0 0 0

errors: No known data errors

А с по­мо­щью суб­ко­ман­ды list мож­но уз­нать объ­ем но­во­об­ра­зо­ван­но­го пу­ла:

# zpool list mypool

NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT

mypool 18,9G 93K 18,9G 0% 1.00x ONLINE -

Лег­ко ви­деть, что он ра­вен сум­ме объ­е­мов обе­их флэ­шек, ес­ли «мар­ке­тин­го­вые» ги­га­бай­ты пе­ре­счи­тать в «на­стоя­щие».

К сло­ву ска­зать, ес­ли дать суб­ко­ман­ду list без ука­зания ар­гу­мен­та – имени пу­ла, то она вы­ве­дет ин­фор­ма­цию обо всех пу­лах, за­дей­ст­во­ван­ных в сис­те­ме. В моем случае это выглядит так:

# zpool list

NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT

mypool 18,9G 93K 18,9G 0% 1.00x ONLINE -

tank 199G 20,8G 178G 10% 1.00x ONLINE -

Об­ра­щаю внимание, что да­же чис­то ин­фор­ма­ци­он­ные суб­ко­ман­ды вро­де list и status тре­бу­ют прав ад­минист­ра­то­ра.

Ра­зу­ме­ет­ся, два пу­ла в од­ной, да еще и на­столь­ной, ма­шине – из­лиш­няя роскошь. Так что пул, соз­дан­ный в экс­пе­ри­мен­таль­ных це­лях, под­ле­жит унич­то­жению, что де­ла­ет­ся с по­мо­щью суб­ко­ман­ды destroy:

# zpool destroy mypool

По­сле это­го он про­па­дет из спи­ска пу­лов. А что мож­но сде­лать с пу­лом до его унич­то­жения, уви­дим со вре­менем.

[править] «Из­бы­точ­ные» пу­лы

Из­ба­вив­шись от став­ше­го ненуж­ным пу­ла, рас­смот­рим вто­рой ва­ри­ант – соз­дание пу­ла с зеркаль­ным уст­рой­ст­вом. Соз­да­ем его из двух на­ко­пи­те­лей оди­на­ко­во­го объ­е­ма:

# zpool create -f mypool mirror sdf sdg

Про­вер­ка по­ка­зы­ва­ет, что ито­го­вый пул, как и сле­до­ва­ло ожи­дать, ра­вен объ­е­му од­но­го на­ко­пи­те­ля:

# zpool list mypool

NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT

mypool 3,72G 91,5K 3,72G 0% 1.00x ONLINE -

При раз­ли­чии объ­е­мов боль­ший диск бу­дет «об­ре­зан» до объ­е­ма мень­ше­го.

Пол­ное зер­ка­ли­ро­вание лю­бы­ми сред­ст­ва­ми, по мо­ему мнению, в на­столь­ных усло­ви­ях – роскошь непо­зво­ли­тель­ная: ба­наль­ные бэ­ка­пы дан­ных про­ще и на­дежнее. Тем не менее, не ис­клю­чаю, что неко­то­рая из­бы­точ­ность на уровне про­вер­ки кон­троль­ных сумм мо­жет ока­зать­ся отнюдь не лишней, да не столь и на­клад­на. Так что да­вай­те по­смот­рим и на тре­тий ва­ри­ант пу­ла из бо­лее чем од­но­го уст­рой­ст­ва – RAID-Z.

Тео­ре­ти­че­­ски вир­ту­аль­ное уст­рой­ст­во с оди­ноч­ным кон­тро­лем чет­но­сти, как уже го­во­ри­лось, мож­но соз­дать при на­ли­чии двух уст­ройств фи­зи­че­­ских. Од­на­ко прак­ти­че­­ски это ока­зы­ва­ет­ся на­клад­но, осо­бен­но ес­ли уст­рой­ст­ва не оди­на­ко­во­го раз­ме­ра. По­это­му за­дей­ст­ву­ем под него три на­ко­пи­те­ля:

# zpool create mypool raidz sdd sdf sdg

что даст нам сле­дую­щую кар­ти­ну:

# zpool list mypool

NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT

mypool 11,1G 205K 11,1G 0% 1.00x ONLINE -

Впро­чем, как мне ка­жет­ся, в на­столь­ных усло­ви­ях не сто­ит вы­дел­ки и эта ов­чин­ка.

[править] Пул кэ­ши­руе­мый

И, на­конец, по­следний ва­ри­ант ор­ганиза­ции пу­ла из бо­лее чем од­но­го уст­рой­ст­ва – соз­дание пу­ла с кэ­ши­ро­ванием. Для че­го соз­да­ем из двух уст­ройств про­стой пул без из­бы­точ­но­сти и под­сое­ди­ня­ем к нему уст­рой­ст­во для кэ­ша:

# zpool create mypool sdd sdf cache sdg

Оче­вид­но, что уст­рой­ст­во для кэ­ши­ро­вания не долж­но вхо­дить в пул лю­бо­го ро­да – ни в про­стой, ни в из­бы­точ­ный. Что мы и ви­дим в вы­во­де суб­ко­ман­ды list:

# zpool list mypool

NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT

mypool 18,9G 82K 18,9G 0% 1.00x ONLINE -

где ника­ких сле­дов его об­на­ру­жить не уда­ет­ся. Ес­ли же по­яв­ля­ют­ся со­мнения, а под­клю­чи­лось ли оно на са­мом де­ле, об­ра­ща­ем­ся к суб­ко­ман­де status, ко­то­рая по­ка­жет бес­поч­вен­ность на­ших опа­сений.

Как я уже го­во­рил в об­зо­ре воз­мож­но­стей ZFS (LXF165/166), под­клю­чение уст­рой­ст­ва кэ­ши­ро­вания име­ет смысл при на­ли­чии боль­шо­го тра­ди­ци­он­но­го вин­че­сте­ра (или вин­че­сте­ров) и от­но­си­тель­но неболь­шо­го SSD, ко­то­рое и иг­ра­ет роль дис­ко­во­го кэ­ша.

[править] Об оп­ци­ях ко­ман­ды zpool

Ко­ман­да zpool под­дер­жи­ва­ет еще мно­же­ст­во суб­команд, пред­на­зна­чен­ных для экс­пор­та и им­пор­та пу­ла, до­бав­ления к нему уст­ройств и изъ­я­тия оных, и так да­лее. Но сей­час я рас­ска­жу о неко­то­рых оп­ци­ях, ко­то­рые мо­гут ока­зать­ся необ­хо­ди­мы­ми при соз­дании пу­ла.

Од­на из важ­ный оп­ций – -f: она пред­пи­сы­ва­ет при­ну­ди­тель­ное вы­полнение дан­ной опе­ра­ции и тре­бу­ет­ся, на­при­мер, при соз­дании пу­ла из нераз­ме­чен­ных уст­ройств.

По­лез­ной мо­жет ока­зать­ся оп­ция -n. Она оп­ре­де­ля­ет тес­то­вый ре­жим вы­полнения оп­ре­де­лен­ной суб­ко­ман­ды, то есть вы­во­дит ре­зуль­тат, на­при­мер, суб­ко­ман­ды zpool create без фак­ти­че­­ско­­го соз­дания пу­ла. И. со­от­вет­ст­вен­но, со­об­ща­ет об ошиб­ках, ес­ли та­ко­вые име­ют­ся.

Ин­те­рес­на так­же оп­ция -m mountpoint. Как уже го­во­ри­лось, при соз­дании пу­ла по умол­чанию в корне фай­ло­вой ие­рар­хии соз­да­ет­ся ка­та­лог /pool_name, ко­то­рый в дальней­шем бу­дет точ­кой мон­ти­ро­вания фай­ло­вых сис­тем ZFS. Воз­мож­но, что это ока­жет­ся не са­мым луч­шим ме­стом для их раз­ме­щения, и, как мы уви­дим в дальней­шем, это неслож­но бу­дет из­менить. Но мож­но за­дать ка­та­лог для пу­ла сра­зу – на­при­мер, /home/data: это и бу­дет зна­чением оп­ции -m. Ни­кто не за­пре­ща­ет оп­ре­де­лить в ка­че­­ст­ве та­ко­во­го и ка­кой-ли­бо из су­ще­ст­вую­щих ка­та­ло­гов – ес­ли он пуст: ина­че ав­то­ма­ти­че­­ское мон­ти­ро­вание фай­ло­вых сис­тем пу­ла в него ока­жет­ся невоз­мож­ным.

На­конец, нын­че важ­ное зна­чение при­об­ре­та­ет оп­ция ashift=#, зна­чением ко­то­рой яв­ля­ет­ся раз­мер бло­ка фай­ло­вой сис­те­мы в ви­де сте­пеней двой­ки. По умол­чанию при соз­дании пу­ла раз­мер бло­ка оп­ре­де­ля­ет­ся ав­то­ма­ти­че­­ски, и до неко­то­ро­го вре­мени это бы­ло оп­ти­маль­но. Од­на­ко за­тем, с од­ной сто­ро­ны, поя­ви­лись дис­ки так на­зы­вае­мо­го Advanced Format, с дру­гой – по­лу­чи­ли рас­про­странение SSD-на­ко­пи­те­ли. И в тех, и в дру­гих раз­мер бло­ка ра­вен 4 КБ, хо­тя в це­лях со­вмес­ти­мо­сти по-прежнему эму­ли­ру­ет­ся блок в 512 байт. В этих усло­ви­ях ав­то­ма­ти­ка ZFS мо­жет ра­бо­тать некор­рект­но, что при­во­дит к па­дению про­из­во­ди­тель­но­сти пу­ла.

Для пре­дот­вра­щения оз­на­чен­но­го без­обра­зия и бы­ла при­ду­ма­на оп­ция ashift. Зна­чение ее по умол­чанию – 0, что со­от­вет­ст­ву­ет ав­то­ма­ти­че­­ско­­му оп­ре­де­лению раз­ме­ра бло­ка. Про­чие же воз­мож­ные зна­чения ле­жат в диа­па­зоне от 9 для бло­ка в 512 байт (29 = 512) до 16 для 64-ки­ло­байт­но­го бло­ка (216 = 65536). В ин­те­ре­сую­щем нас слу­чае че­ты­рех­ки­ло­байт­но­го бло­ка оно со­став­ля­ет 12 (212 = 4096). Имен­но по­следнее зна­чение и сле­ду­ет ука­зать яв­ным об­ра­зом при соз­дании пу­ла из вин­че­сте­ров AF или SSD-на­ко­пи­те­лей.

[править] Соз­дание фай­ло­вых сис­тем

Пу­лы хранения пред­став­ля­ют со­бой вме­сти­ли­ща для на­бо­ров дан­ных, для манипу­ля­ции ко­то­ры­ми пред­на­зна­че­на вто­рая из главней­ших команд – zfs. Са­мы­ми важ­ны­ми на­бо­ра­ми дан­ных яв­ля­ют­ся фай­ло­вые сис­те­мы, к рас­смот­рению ко­то­рых мы и пе­ре­хо­дим.

Для соз­дания фай­ло­вых сис­тем пред­на­зна­че­на суб­ко­ман­да create ко­ман­ды zfs, ко­то­рая тре­бу­ет един­ст­вен­но­го ар­гу­мен­та – имени соз­да­вае­мой ФС и обыч­но не ну­ж­да­ет­ся ни в ка­ких оп­ци­ях:

# zfs create pool_name/fs_name

Внут­ри пу­ла мож­но соз­да­вать сколь угод­но слож­ную ие­рар­хию фай­ло­вых сис­тем. Един­ст­вен­ное усло­вие – ро­ди­тель­ская фай­ло­вая сис­те­ма для сис­те­мы бо­лее глу­бо­ко­го уров­ня вло­жен­но­сти долж­на быть соз­да­на за­бла­го­вре­мен­но. Ни­же я по­ка­жу это на кон­крет­ном при­ме­ре соз­дания фай­ло­вых сис­тем внут­ри ка­та­ло­га /home – это наи­бо­лее оп­рав­дан­ное ме­сто для раз­ме­щения на­бо­ров дан­ных ZFS.

Нач­ну я немно­жеч­ко из­да­ле­ка. При стан­дарт­ной уста­нов­ке openSUSE не обой­тись без соз­дания учет­ной за­пи­си обыч­но­го поль­зо­ва­те­ля, и, сле­до­ва­тель­но, в ка­та­ло­ге /home бу­дет при­сут­ст­во­вать по крайней ме­ре один под­ка­та­лог – /home/username. Смон­ти­ро­вать же фай­ло­вую сис­те­му ZFS в непустой ка­та­лог невоз­мож­но, и, зна­чит, мы не мо­жем сра­зу при­бег­нуть к оп­ции -m для оп­ре­де­ления «по­сто­ян­ной пропис­ки» соз­да­вае­мо­го пу­ла.

По­это­му для на­ча­ла де­ла­ем для пу­ла «пропис­ку» во вре­мен­ной точ­ке – пусть это бу­дет тра­ди­ци­он­ный /tank:

# zpool create -o ashift=12 tank ata-SanDisk_SDSSDX120GG25_120823400863-part3 ata-SanDisk_SDSSDX120GG25_120823402786-part3

Те­перь соз­да­ем фай­ло­вую сис­те­му для бу­ду­ще­го до­машнего ка­та­ло­га:

# zfs create tank/home

А внут­ри же нее – не­об­хо­ди­мые до­чер­ние вет­ви, как то:

=# zfs create tank/home/alv

ко­то­рая по­том за­ме­нит мой до­маш­ний ка­та­лог – в нем я не дер­жу ни­че­го, кро­ме кон­фи­гу­ра­ци­он­ных фай­лов;

# zfs create tank/home/proj

– это фай­ло­вая сис­те­ма для мо­их те­ку­щих про­ек­тов, и так да­лее.

Как и бы­ло обе­ща­но раз­ра­бот­чи­ка­ми ZFS, про­це­ду­ра ничуть не сложнее, чем соз­дание обыч­ных ка­та­ло­гов. Бла­го­да­ря это­му фай­ло­вые сис­те­мы мож­но лег­ко соз­да­вать по ме­ре на­доб­но­сти, для ре­шения ка­кой-ли­бо ча­ст­ной за­да­чи. И столь же лег­ко унич­то­жать их, когда за­да­ча эта вы­полнена. Что де­ла­ет­ся та­ким об­ра­зом:

# zfs destroy pool_name/fs_name

Ис­поль­зо­вать суб­ко­ман­ду destroy сле­ду­ет ак­ку­рат­но: ника­ко­го за­про­са на под­твер­ждение при этом не бу­дет. Прав­да, и унич­то­жить фай­ло­вую сис­те­му, за­ня­тую в ка­ком-ли­бо те­ку­щем про­цес­се, мож­но толь­ко с ука­занием оп­ции -f, а фай­ло­вую сис­те­му, со­дер­жа­щую сис­те­мы до­черние, не по­лу­чит­ся убить и та­ким об­ра­зом.

Ни в ка­кой спе­ци­аль­ной опе­ра­ции мон­ти­ро­вания но­во­об­ра­зо­ван­ные фай­ло­вые сис­те­мы не ну­ж­да­ют­ся – оно про­ис­хо­дит ав­то­ма­ти­че­­ски в мо­мент их соз­дания, о чем сви­де­тель­ст­ву­ет сле­дую­щая ко­ман­да:

$ mount | grep tank

tank/home on /tank/home type zfs (rw,atime,xattr)

tank/home/alv on /tank/home/alv type zfs (rw,atime,xattr)

tank/home/proj on /tank/home/proj type zfs (rw,atime,xattr)

...

Для обес­пе­чения мон­ти­ро­вания фай­ло­вых сис­тем ZFS при ре­стар­те ма­ши­ны не тре­бу­ет­ся и ника­ких за­пи­сей в фай­ле /etc/fstab: это так­же про­ис­хо­дит са­мо со­бой, со­вер­шен­но нечув­ст­ви­тель­но для поль­зо­ва­те­ля. Прав­да, ес­ли для фай­ло­вой сис­те­мы ZFS оп­ре­де­лить свой­ст­во mountpoint=legacy, то с ней мож­но управ­лять­ся и тра­ди­ци­он­ным спо­со­бом.

Как и для обыч­но­го ка­та­ло­га, объ­ем ка­ж­дой фай­ло­вой сис­те­мы ничем не ли­ми­ти­ро­ван, и в мо­мент соз­дания для лю­бой из них по­тен­ци­аль­но доступ­но все про­стран­ст­во пу­ла, ко­то­рое рав­но­мер­но умень­ша­ет­ся по ме­ре раз­рас­тания фай­ло­вых сис­тем. На дан­ный мо­мент в мо­ей сис­те­ме это вы­гля­дит так.

Ка­за­лось бы, для тех же це­лей мож­но ог­раничить­ся обыч­ны­ми ка­та­ло­га­ми. Од­на­ко в на­бо­рах дан­ных ZFS мы име­ем де­ло с пол­но­цен­ны­ми фай­ло­вы­ми сис­те­ма­ми, для ко­то­рых мо­гут быть уста­нов­ле­ны ин­ди­ви­ду­аль­ные свой­ст­ва, ана­ло­гич­ные оп­ци­ям мон­ти­ро­вания фай­ло­вых сис­тем тра­ди­ци­он­ных. Чем мы сей­час и зай­мем­ся.

[править] Фай­ло­вые сис­те­мы: свой­ст­ва

При соз­дании фай­ло­вая сис­те­ма ZFS по­лу­ча­ет по умол­чанию оп­ре­де­лен­ный на­бор свойств, во мно­гом сход­ный с ат­ри­бу­та­ми тра­ди­ци­он­ных фай­ло­вых сис­тем, оп­ре­де­ляе­мы­ми оп­ция­ми их мон­ти­ро­вания. Пол­ный их спи­сок мож­но по­лу­чить ко­ман­дой

# zfs get all fs_name

Свойств этих очень мно­го, од­на­ко да­ле­ко не все они пред­став­ля­ют для нас ин­те­рес. Важ­но толь­ко помнить, что лю­бое из свойств ка­ж­дой фай­ло­вой сис­те­мы мож­но по­ме­нять с по­мо­щью суб­ко­ман­ды set и ее па­ра­мет­ра ви­да свой­ст­во=зна­чение. При­чем из­менение свойств для ма­те­рин­ской сис­те­мы ре­кур­сив­но рас­про­стра­ня­ет­ся на все до­черние. Од­на­ко для лю­бой по­следней свой­ст­ва мож­но из­менить в ин­ди­ви­ду­аль­ном по­ряд­ке. Что я сей­час и про­ил­лю­ст­ри­рую на при­ме­рах.

Ска­жем, аб­со­лют­но лишним пред­став­ля­ет­ся свой­ст­во atime, то есть об­нов­ление вре­мени по­следнего досту­па к фай­лам. Оно, с одной стороны, снижа­ет бы­ст­ро­дей­ст­вие, с дру­гой – спо­соб­ст­ву­ет из­но­су SSD-на­ко­пи­те­лей (прав­да, нын­че и то, и дру­гое яв­ление чис­то сим­во­лич­ны). Так что от­клю­ча­ем это свой­ст­во для всех фай­ло­вых сис­тем:

# zfs set atime=off tank/home

Ана­ло­гич­ным об­ра­зом рас­прав­ля­ем­ся и со свой­ст­вом xattr:

# zfs set xattr=off tank/home

А вот даль­ше мож­но за­нять­ся и ин­ди­ви­дуа­ли­за­ци­ей. Как я уже го­во­рил, в мо­мент соз­дания фай­ло­вые сис­те­мы ZFS «без­раз­мер­ны». Ес­ли это не под­хо­дит, для них мож­но уста­но­вить кво­ты. Од­на­ко я это­го де­лать не бу­ду – в мо­ем слу­чае это при­во­дит к по­те­ре по­ло­ви­ны смыс­ла ZFS. А вот за­ре­зер­ви­ро­вать ме­сто для кри­ти­че­­ски важ­ных ка­та­ло­гов, да­бы его не отъ­е­ла, ска­жем, муль­ти­ме­диа, из­вест­ная сво­ей про­жор­ли­во­стью, бу­дет не лишним. И по­то­му я для фай­ло­вых сис­тем tank/home/proj и tank/home/alv уста­нав­ли­ваю свой­ст­во reservation. Для фай­ло­вой сис­те­мы про­ек­тов оно бу­дет мак­си­маль­ным:

# zfs set reservation=10G tank/home/proj

Для осталь­ных ог­раничусь бо­лее скром­ным ги­га­бай­том ре­зер­ва.

Да­лее, по­сколь­ку дан­ные в фай­ло­вой сис­те­ме tank/home/proj для ме­ня дей­ст­ви­тель­но важ­ны, и шу­тить с ними я склонен да­же го­раз­до мень­ше, чем с да­ма­ми, пред­принимаю до­полнитель­ные ме­ры по их со­хран­но­сти пу­тем уд­воения чис­ла ко­пий (по умол­чанию оно рав­но 1):

# zfs set copies=2 tank/home/proj

А для дан­ных не столь важ­ных – тех, что час­то про­ще ска­чать за­но­во, неже­ли оты­скать на локаль­ной ма­шине, мож­но вы­полнить и об­рат­ную опе­ра­цию – от­ка­зать­ся от под­сче­та кон­троль­ных сумм:

# zfs set checksum=off tank/home/media

Для фай­ло­вых сис­тем, со­дер­жа­щих хо­ро­шо сжи­мае­мые дан­ные (на­при­мер, для мое­го до­машнего ка­та­ло­га, где ле­жат одни dot-фай­лы), мож­но вклю­чить ком­прес­сию:

# zfs set compression=on tank/home/alv

Я это­го не де­лал: эко­но­мия мес­та по­лу­ча­ет­ся гро­шо­вая, а на­груз­ка на про­цес­сор и рас­ход па­мя­ти, как го­во­рят, очень при­лич­ные. Од­на­ко это свой­ст­во це­ле­со­об­раз­но вклю­чать в сис­те­мах с ог­ром­ны­ми ло­га­ми, ес­ли вы­де­лить под них фай­ло­вую сис­те­му в пу­ле ZFS.

При же­лании для неко­то­рых фай­ло­вых сис­тем (на­при­мер, то­го же до­машнего ка­та­ло­га) мож­но от­клю­чить та­кие свой­ст­ва, как exec, setuid, devices – лег­ко до­га­дать­ся, что ре­зуль­тат бу­дет ана­ло­ги­чен ука­занию оп­ций мон­ти­ро­вания noexec, nosuid, nodev для тра­ди­ци­он­ных фай­ло­вых фай­ло­вых сис­тем. И, ра­зу­ме­ет­ся, фай­ло­вым сис­те­мам, из­менение ко­то­рых неже­ла­тель­но, мож­но при­дать свой­ст­во readonly.

Все необ­хо­ди­мые свой­ст­ва фай­ло­вых сис­тем же­ла­тель­но уста­но­вить до их на­полнения кон­тен­том, ибо мно­гие из них (на­при­мер, ком­прес­сия) об­рат­ной си­лы не име­ют.

[править] О пе­ре­мон­ти­ро­вании

По­сле соз­дания фай­ло­вых сис­тем и за­дания всех необ­хо­ди­мых их свойств на­сту­па­ет пси­хо­ло­ги­че­­ский мо­мент для пе­ре­мон­ти­ро­вания их по мес­ту «по­сто­ян­ной пропис­ки» – то есть в ка­та­лог /home. Что по­тре­бу­ет от нас неко­то­рых под­го­то­ви­тель­ных дей­ст­вий.

По­сколь­ку пред­по­ла­га­ет­ся, что все но­во­об­ра­зо­ван­ные фай­ло­вые сис­те­мы долж­ны быть пол­но­стью доступ­ны обыч­но­му поль­зо­ва­те­лю (то есть мне, лю­би­мо­му), пер­во-на­пер­во сле­ду­ет из­менить ат­ри­бу­ты из при­над­леж­но­сти – ведь соз­да­ва­лись они от имени ад­минист­ра­то­ра и при­над­ле­жат юзе­ру по имени root. Для че­го даю ко­ман­ду:

# chown -R alv:users /tank/home/*

Те­перь нуж­но ско­пи­ро­вать кон­фи­ги из ка­та­ло­га /home/alv в /tank/home/alv:

# cp -Rp /home/alv/.* /tank/home/alv/

не за­быв про оп­цию -p для со­хра­не­ния ат­ри­бу­тов.

Все пре­ды­ду­щие опе­ра­ции мож­но бы­ло вы­пол­нять, по­лу­чив пра­ва ад­минист­ра­то­ра с по­мо­щью ко­ман­ды su (или, при же­лании, sudo). При­чем где угод­но – в тек­сто­вом вир­ту­аль­ном тер­ми­на­ле или в тер­ми­наль­ном окне Ик­со­во­го се­ан­са (на­при­мер, в konsole KDE). Те­перь же по­тре­бу­ет­ся пе­ре­ав­то­ри­зо­вать­ся в «го­лой» кон­со­ли.

Мон­ти­ро­вание фай­ло­вых сис­тем ZFS в ка­та­лог с лю­бым со­дер­жи­мым невоз­мож­но, так что тре­бу­ет­ся очи­стить ка­та­лог /home от сле­дов прежней жизнедея­тель­но­сти поль­зо­ва­те­ля та­ким об­ра­зом:

# rm -Rf /home/alv

При хотя бы од­ном ак­тив­ном поль­зо­ва­тель­ском про­цес­се в от­вет на это по­сле­ду­ет со­об­щение об ошиб­ке. Так что, воз­мож­но, п­редварительно при­дет­ся убить все ре­лик­то­вые про­цес­сы, за­пу­щен­ные в Ик­сах от имени поль­зо­ва­те­ля. Сна­ча­ла вы­яв­ля­ем их ко­ман­дой

# ps aux | grep alv

об­ра­щая внимание на иден­ти­фи­ка­то­ры про­цес­сов (PID). А за­тем по­сле­до­ва­тель­но «мо­чим их в сор­ти­ре»:

# kill -9 ####

Вы­полнив все ука­зан­ные дей­ст­вия, оп­ре­де­ля­ем для на­бо­ра дан­ных tank/home свой­ст­во mountpoint, что и осу­ще­ст­вит пе­ре­мон­ти­ро­вание:

# zfs set mountpoint=/home tank/home

Те­перь оста­ет­ся толь­ко с по­мо­щью ко­ман­ды ls убе­дить­ся, что в /home поя­ви­лись но­вые под­ка­та­ло­ги с нуж­ны­ми ат­ри­бу­та­ми:

drwxr-xr-x 26 alv users 48 Sep 23 14:27 alv/

drwxr-xr-x 18 alv users 18 Sep 22 02:28 proj/

...

А ко­ман­да

# mount | grep /home

по­ка­жет нам но­вые точ­ки мон­ти­ро­ва­ния фай­ло­вых сис­тем:

tank/home on /home type zfs (rw,noatime,noxattr)

tank/home/alv on /home/alv type zfs (rw,noatime,noxattr)

tank/home/proj on /home/proj type zfs (rw,noatime,noxattr)

...

Как я уже го­во­рил вы­ше, при ис­поль­зо­вании па­ке­тов из ре­по­зи­то­рия munix9 на этом де­ло с под­го­тов­кой фай­ло­вых сис­тем ZFS к прак­ти­че­­ской ра­бо­те мож­но счи­тать за­кон­чен­ным: при пе­ре­за­груз­ке ма­ши­ны все они бу­дут бла­го­по­луч­но смон­ти­ро­ва­ны в ав­то­ма­ти­че­­ском ре­жи­ме. Па­ке­ты же из ghaskins по­тре­бу­ют еще од­но­го деяния – соз­дания в ка­та­ло­гах /etc/init.d/rc3.d и /etc/init.d/rc5.d сим­во­ли­че­­ских ссы­лок на файл /etc/init.d/zfs.

[править] Вместо заключения

За чер­той ста­тьи оста­лись мно­гие во­про­сы при­менения ZFS, в ча­ст­но­сти, экс­пор­та и им­пор­та пу­лов, со­вме­ст­но­го ис­поль­зо­вания на­бо­ров дан­ных в раз­ных ди­ст­ри­бу­ти­вах Linux’а (и, воз­мож­но, не толь­ко его), соз­дания снап­шо­тов и кло­нов, восста­нов­ления по­сле сбо­ев. Очень ин­те­рес­но изу­чить про­бле­му раз­ме­щения на ZFS кор­ня фай­ло­вой ие­рар­хии и воз­мож­ность за­груз­ки с нее. Од­на­ко на­де­юсь, что рас­ска­зан­ное на пре­ды­ду­щих страницах по­зво­лит чи­та­те­лю оценить досто­ин­ст­ва ZFS как универ­саль­ной ком­плекс­ной сис­те­мы раз­ме­щения дан­ных. По­ла­гаю, что при­ве­ден­ных све­дений бу­дет доста­точ­но и для на­ча­ла прак­ти­че­­ской ра­бо­ты с ней. |