Ўстаноўка Linux на SSD нетбука з кампрэсіяй файлаў

  1. Асноўныя асаблівасці файлавай сістэмы Btrfs
  2. Ўстаноўка Linux на тым Btrfs з уключанай кампрэсіяй
  3. Даданне другога дыска ў файлавую сістэму Btrfs
  4. Дадатковая аптымізацыя аперацыйнай сістэмы Linux для працы на SSD
  5. Опцыі мантавання файлавай сістэмы Btrfs для традыцыйных механічных жорсткіх дыскаў
  6. заключэнне

У адрозненне ад Microsoft Windows, у якой на працягу многіх гадоў вяршэнствуюць і практычна адзіным тыпам файлавай сістэмы з'яўляецца NTFS (аб FAT і пра аб анансаванай ў 2012 годзе ReFS казаць не будзем), у Linux выбар ёсць. Тут наўскідку можна налічыць больш за дзесятак разнавіднасцяў файлавых сістэм. Найбольш вядомымі і часцей за ўсё выкарыстоўваюцца з'яўляюцца EXT2, EXT3 і, вядома, EXT4. Да іх можна дадаць btrfs, jfs, reiserfs і шэраг іншых.

Ідэальных файлавых сістэм не існуе. Кожная з іх мае свае моцныя і слабыя бакі. Сёння мы паэксперыментуем з Btrfs, якая лічыцца адной з самых хуткіх і перспектыўных.

Асноўныя асаблівасці файлавай сістэмы Btrfs

Файлавая сістэма Btrfs (Better FS), заснаваная на структурах двайковых дрэў ( B-Tree ), Была прадстаўлена кампаніяй Oracle ў 2007 годзе.

Пералік вартасцяў і магчымасцяў btrfs вельмі шырокі. Пералічу тыя з іх, якія падаліся мне найбольш цікавымі для прымянення на хатнім кампутары і падштурхнулі ў канчатковым рахунку на эксперыменты з гэтай ФС:

  • Высокая хуткасць;
  • Падтрымка многодісковых канфігурацый прылад захоўвання - можна налёту падключаць / адключаць дыскі да файлавай сістэмы, а таксама ствараць RAID канфігурацыі розных узроўняў. Можна ствараць канфігурацыю з чаргаваннем або люстраванне і для асобных каталогаў.
  • Можна ўключыць празрыстае сціск дадзеных (Zlib - больш высокая ступень сціску, LZO - хуткае сціск, у распрацоўцы - snappy, LZ4);
  • Online дэфрагментацыя файлавай сістэмы;
  • Убудаваная падтрымка цвёрдацельных назапашвальнікаў SSD;
  • Кантроль цэласнасці блокаў дадзеных і метададзеных з дапамогай кантрольных сум;
  • Магчымасць стварэння подтомов (subvolumes);
  • Магчымасць пераўтварэння існуючых ext3 / ext4 файлавых сістэм у btrsf;
  • Прасторава-эфектыўная (Space-efficient) ўпакоўка дробных файлаў;
  • Эфектыўнае індэксаванне каталогаў;
  • У ліку запланаваных магчымасцяў - перасоўванне найбольш часта выкарыстоўваюцца дадзеныя на самае хуткае прылада.

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

Самым галоўным недахопам Btrfs на сённяшні момант часу з'яўляецца яе статус. З аднаго боку, актуальная на момант напісання дадзенага артыкула версія v3.12 лічыцца стабільнай, з другога боку, распрацоўшчыкі адкрыта заяўляюць, што яна ўсё яшчэ знаходзіцца ў стадыі тэставання і яе не рэкамендуецца выкарыстоўваць у прамысловых мэтах.

Атрымліваецца, што пад час выкарыстаньня ранніх версій Btrsf дадзеныя знікалі нестабільна, цяпер будуць знікаць стабільна (жарт).

Што тычыцца хуткасці, то рэсурсам Phoronix яшчэ ў 2011 годзе былі апублікаваныя дадзеныя прадукцыйнасці файлавай сістэмы Btrfs пры працы без сціску дадзеных, з выкарыстаннем кампрэсіі метадам ZLib і з выкарыстаннем кампрэсіі метадам LZO.

У двух з трох праведзеных тэстаў (Compile Bench і Dbench Btrfs) варыянт з LZO-сціскам упэўнена абагнаў як варыянт без сціску, так і варыянт з ZLib-сціскам. Прычым у некаторых выпадках розніца ў хуткасці адрознівалася амаль на парадак (!).

У цесцю Threaded IO Tester LZO прайграў і варыянту без сціску і ZLib ад 10% да 33%.

Наогул вымярэнне рэальных хуткасных характарыстык прылады захоўвання з'яўляецца задачай няпростай. Некаторы час таму я спрабаваў ацаніць ўплыў ntfs-сціску на хуткасць чытання дадзеных у Windows 7. Вынік апынуўся неадназначным, як гэта ні дзіўна, залежных ад тыпу назапашвальніка. Гэта не дазволіла зрабіць адназначных высноў.

Значны выйгрыш у хуткасці ФС па выніках двух тэстаў і нязначны правал у адным з іх схіляюць да вырашэння выканаць ўстаноўку аперацыйнай сістэмы Linux на тым Btrfs з уключаным сціскам.

Ўстаноўка Linux на тым Btrfs з уключанай кампрэсіяй

У якасці паддоследнага труса тэставага стэнда зноў будзе выступаць старэнькі ASUS Eee PC 900. Чаго ён толькі ні пабачыў за мінулыя гады. Цікава, ці шмат у каго сёння захаваўся гэты першы прадстаўнік канчаткова вымерлага сёння сямейства нетбуков?

Для запланаванага эксперыменту з Btrfs гэта проста ідэальны ўзор.

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

Па-другое, само прылада на працэсары Intel Celeron M 900 Мгц ну вельмі няхутка, што адразу ж дазволіць нават без усялякіх тэстаў проста візуальна ацаніць поспех або няўдачу дадзенага эксперыменту.

Першапачаткова я планаваў усталяваць на Eee PC 900 Linux Mint-17.1 xfce. Аднак вельмі хутка з гэтай ідэяй прыйшлося развітацца. Ўсталёўнік Linux Mint патрабаваў мінімум 8.2 Гб вольнага месца на дыску і ва ўпор не хацеў бачыць ні другі дыск, ні загадзя сабраны з двух назапашвальнікаў тым Btrfs аб'ёмам амаль 12 Гб. Пра тое, каб растлумачыць усталёўніку, што ўстаноўка будзе выконвацца на сціснуты тым і на самай справе аднаго дыска аб'ёмам 4 Гб будзе дастаткова, гаворка наогул не ішла.

Наступная праверка ў віртуальнай машыне VirtualBox паказала, што для ўстаноўкі 32-разраднай зборкі Linux Mint-17.1 xfce на сціснуты з дапамогай LZO тым, трэба ўсяго 2,6 Гб

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

Гэта выключна праблема дадзенага нетбука, абумоўленая маленькім памерам дыскаў. Наўрад ці яна паўторыцца на якім-небудзь іншым кампутары. Хоць у дыстрыбутыве Linux Mint хацелася б бачыць ўсталёўнік разумнешым.

Калі памкняцеся ўсталёўваць Linux Mint на файлавую сістэму Btrfs, майце на ўвазе, што ў дыстрыбутыў, па меншай меры ў той, пра які тут ідзе гаворка, падтрымка гэтай файлавай сістэмы не ўключана. Для таго, каб мець магчымасць адфарматаваць раздзелы з Btrfs, неабходна ўсталяваць btrfs-tools:

sudo apt-get install btrfs-tools

Так як падтрымка Btrfs ўключана ў ядро, Mint пасля ўстаноўкі загрузіцца, але для таго, каб можна было рабіць нейкія маніпуляцыі з тамамі, ўстаноўку btrfs-tools прыйдзецца паўтарыць.

У якасці альтэрнатывы я выбраў лёгкую воблачна-арыентаваную Peppermint OS з асяроддзем працоўнага стала LXDE (Lightweight X11 Desktop Environment). Раней яна ўжо згадвалася ў аглядзе дыстрыбутываў Linux.

Далейшыя падзеі паказалі, што выбар аказаўся вельмі ўдалым. Палегчаны набор прыкладанняў і шустрае асяроддзе - гэта як раз тое, што трэба для марудлівага нетбука.

Апошняя на момант напісання дадзенага артыкула 5-я версія гэтай АС грунтуецца на Ubuntu 14.04 LTS з пяцігадовым тэрмінам падтрымкі. Магчымасць працы з файлавай сістэмай Btrfs прысутнічае адразу.

Праблема ўстаноўкі складалася ў тым, што кампрэсія ўключаецца ў Btrfs на стадыі мантавання файлавай сістэмы (-o compress = lzo / zlib), а стандартны ўсталёўнік Linux, па меншай меры ў Ubuntu і заснаваных на ёй сістэмах, не дае выбіраць пашыраныя опцыі.

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

  • ствараем загрузачны флешку з дапамогай Universal USB Installer. Загружаем кампутар з яе і заходзім у тэрмінал:

sudo -i

  • Пераназываем выкананы файл mount ў mount.bin

mv / bin / mount /bin/mount.bin

  • Ствараем файл скрыпту mount

gedit / bin / mount

Замест gedit вы можаце выкарыстоўваць любы тэкставы рэдактар, які ўваходзіць у склад Live CD.

Ўпісваем у mount наступны код:

#! / Bin / sh
if echo [Email protected] | grep "btrfs"> / dev / null; then
/bin/mount.bin [Email protected] -o compress-force = lzo
else
/bin/mount.bin [Email protected]
fi

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

  • Захоўваем файл і робім яго выкананым:

chmod 755 / bin / mount

  • Прыступаем да ўсталёўкі.

Яна нічым не адрозніваецца ад апісанай, напрыклад тут .

Разбіццё дыска трэба выканаць самастойна. Для гэтага на этапе "Тып ўстаноўкі" выбіраем "Іншы варыянт".

Пад / boot неабходна абавязкова стварыць у пачатку дыска раздзел памерам прыкладна 200 Мб. У адваротным выпадку сістэма са сціснутага кружэлкі не загрузіцца.

У дадзеным выпадку пад / home асобны раздзел выдзяляць не трэба - у працэсе ўстаноўкі для гэтага каталога будзе аўтаматычна створаны падтэму (subvolum - / @ / home).

Калі сістэма усталёўваецца на звычайны (не SSD) дыск, трэба зрабіць частка падпампоўкі аб'ёмам 2 х RAM.

Аб прызначэнні каталогаў аперацыйнай сістэмы Linux можна прачытаць тут .

  • Працягваем стандартную працэдуру ўстаноўкі і чакаем яе завяршэння.

Да першай перазагрузкі можна адразу ж адрэдагаваць fstab (file systems table). Для гэтага прыйдзецца змантаваць выдзелены пры ўсталёўцы пад корань файлавай сістэмы падзел.

Калі гэта быў, напрыклад, sda2, то:

mount / dev / sda2 / mnt
gedit / mnt / @ / etc / fstab

Звярніце ўвагу, што каранёвая частка таксама трапіў на падтэму і шлях да яго ўключае ў сябе "@".

Знаходзім у fstab радкі, якія тычацца мантавання Btrfs тамоў і замяняем defaults на compress = lzo (канкрэтны прыклад fstab гл. Ніжэй).

  • Перазагружаем кампутар, зараз ужо з жорсткага дыска

Даданне другога дыска ў файлавую сістэму Btrfs

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

Дадатковыя дыскі можна падключыць або адключыць на працуе сістэме ў любы момант.

Па змаўчанні пры размяшчэнні дбаў на некалькіх дысках дадзеныя размяркоўваюцца без рэзервавання і памер ФС атрымліваецца роўным іх сумарным аб'ёме. Пры гэтым выконваецца люстраванне метададзеных на двух прыладах. Калі дыск адзін, то копія метададзеных размяшчаюцца на ім.

Дадамо ва ўжо створаную частку / dev / sda2 дадатковы дыск / dev / sdc

sudo btrfs device add / dev / sdb /

дзе "/" - кропка мантавання (path). Так як хатні каталог таксама змантаваны на тым Btrfs, можна выкарыстоўваць "/ home".

Калі sdc раней ужо быў адфарматаваны ў Btrfs, то, магчыма, каманда запатрабуе ключа -f.

Непасрэдна пасля дадання новага дыска захаваныя на першым дыску файлы застаюцца на месцы. Далучаны дыск будзе запаўняцца ў працэсе працы. Калі трэба адразу пераразмеркаваць файлы, выконваем балансаванне:
sudo btrfs balance start /
У залежнасці ад аб'ёму дадзеных і хуткасных характарыстык дыскаў гэты працэс можа быць працяглым.
Калі выкарыстоўваць дыскі (або раздзелы) аднолькавага памеру, то можна на хаду канвертаваць single device ў RAID масіў.
btrfs balance start -dconvert = raid1 -mconvert = raid1 /
У выніку атрымаецца RAID з люстраванне дадзеных і метададзеных. Аналагічным чынам можна пабудаваць RAID любога ўзроўню, не забываючы пры гэтым пра колькасць неабходных для гэтага дыскаў.

Ацаніць атрыманы вынік можна выканаўшы каманду:

sudo btrfs filesystem show /

sudo btrfs filesystem show /

Атрымаць інфармацыю аб аб'ёме, занятым метададзенымі:
btrfs filesystem df /
Атрымаць інфармацыю аб аб'ёме, занятым метададзенымі: btrfs filesystem df /

Балансаванне я выканаў не адразу, а праз некалькі дзён пасля пачатку актыўнай эксплуатацыі нетбука. Здзіўленне выклікаў той факт, што Btrfs нечакана перамясціла ~ 85% дадзеных на больш павольны дыск. Хацелася б думаць, што гэта правільнае рашэнне. У любым выпадку гэта вельмі цікавы вынік.

Дадатковая аптымізацыя аперацыйнай сістэмы Linux для працы на SSD

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

У якасці файлавай сістэмы для каталога / boot была не выпадкова выбрана нежурналируемая файлавая сістэма ext2. Журналіруемые ФС, з аднаго боку, з'яўляюцца ўстойлівымі да аварыйным сітуацыях, але з іншага боку, павялічваюць колькасць запісаў на жорсткі дыск.

Для частак Btrfs, размешчаных на SSD, дадаем опцыю ssd. Як зменіцца пасля гэтага алгарытм працы з дыскам дасканала невядома. Можна меркаваць, што пры старце або ў працэсе працы на назапашвальніку будуць адшуквалі незанятыя блокі і рэгулярна вызваляцца. Адным словам, горш не будзе.

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

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

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

Адключэнне atime не толькі падаўжае жыццё жорсткага дыска, але і як адзначаецца ў гэтай артыкуле, на 30% павялічвае хуткасць сістэмы. Аднак не ўсе прыкладання змогуць правільна працаваць з адключанымі часовымі пазнакамі.

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

Прапісваем relatime для ўсіх частак, размешчаных на SSD.

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

Канчаткова ў мяне атрымалася так:


# / Etc / fstab: static file system information.
#
# <File system> <mount point> <type> <options> <dump> <pass>
# / Was on / dev / sda2 during installation
UUID = 6bdc62a7-9964-4558-8594-8137271e4591 / btrfs compress = lzo, ssd_spread, relatime, [Email protected] 0 1
# / Boot was on / dev / sda1 during installation
UUID = 256ce960-d9fd-4b9f-b336-cdac0915a33d / boot ext2 relatime 0 2
# / Home was on / dev / sda2 during installation
UUID = 6bdc62a7-9964-4558-8594-8137271e4591 / home btrfs compress = lzo, ssd_spread, relatime, [Email protected] 0 2
#
tmpfs / tmp tmpfs rw, size = 250m 0 0
tmpfs / run tmpfs rw 0 0
tmpfs / var / lock tmpfs rw 0 0
tmpfs / var / log tmpfs rw, size = 10m 0 0

Захоўваем fstab і пераходзім да sysctl.conf

sudo gedit /etc/sysctl.conf

Дадаем у канец файла:

vm.dirty_writeback_centisecs = 15000

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

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

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

Опцыі мантавання файлавай сістэмы Btrfs для традыцыйных механічных жорсткіх дыскаў

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

compress - пакідаем. Згодна з тэстаў, прадстаўленых на сайце Phoronix яшчэ ў канцы 2010 года, кампрэсія дае галоўны выйгрыш у хуткасці дыскавых аперацый.

space_cache - уключае кэшаванне дадзеных аб свабодных блоках ў памяці. Без гэтай опцыі ў працэсе пошуку вольнага прасторы перад запісам Btrfs будзе кожны раз сканаваць ўсе дрэва. Па выніках большасці тэстаў Phoronix ўключэнне опцыі space_cache дае выйгрыш у хуткасці працы з дыскам, хоць і не гэтак істотны, як опцыя compress.

autodefrag - дэфрагментацыя файлаў на лета.

У канчатковым рахунку для HDD павінна атрымацца прыкладна так:

# / Etc / fstab: static file system information.
#
# <File system> <mount point> <type> <options> <dump> <pass>
# / Was on / dev / sda2 during installation
UUID = 6bdc62a7-9964-4558-8594-8137271e4591 / btrfs compress = lzo, space_cache, autodefrag, relatime, [Email protected] 0 1
# / Boot was on / dev / sda1 during installation
UUID = 256ce960-d9fd-4b9f-b336-cdac0915a33d / boot ext2 relatime 0 2
# / Home was on / dev / sda2 during installation
UUID = 6bdc62a7-9964-4558-8594-8137271e4591 / home btrfs compress = lzo, space_cache, autodefrag, relatime, [Email protected] 0 2
#

заключэнне

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

Агульнае ўражанне ад хуткасці і стабільнасці працы Peppermint OS 5 са ​​сціснутай з дапамогай LZO кампрэсіі файлавай сістэмай на Eee PC 900 самыя станоўчыя.

Калі я скажу, што сістэма лётае, вы мне не паверыце. І правільна зробіце. Гэта старэнькае прылада на 915-м чыпсэце з Celeron-M 900 лётаць не ўмее па азначэнні. Але ў параўнанні з самім сабой пад іншымі АС працуе сапраўды на здзіўленне хутка. Як гаворыцца, вынік перасягнуў чаканні. Мабыць што гэтая апошняя інсталяцыя апынулася пакуль самай удалай.

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

Для таго, каб вы мелі ўяўленне пра што ідзе гаворка, прывяду некалькі часовых характарыстык.

Загрузка кампутара з выключаны стану да поўнай загрузкі працоўнага стала займае прыкладна 60 секунд. З іх ~ 15 секунд займае POST, і таксама ~ 15 секунд - сканаванне файлавай сістэмы Btrfs. Розніцу ў хуткасці паміж опцыямі мантавання ssd і ssd_spread заўважыць не ўдалося.

Першы пасля ўключэння кампутара запуск браўзэра Google Chroome - 12 секунд да з'яўлення акна, 20 секунд загрузка пачатковай старонкі Google з падключэннем да ўліковага запісу і адмалёўка ўсіх малюнкаў.

Паўторны запуск браўзэра Chroome в е пачатковай старонкай Google - 10 секунд. Загрузка галоўнай старонкі Yandex - 7 секунд.

Адкрыццё электроннай кнігі ў FBReader - 2 секунды, запуск тэкставага рэдактара AbyWord - 4 секунды, электроннай табліцы Gnumeric - 2 секунды, адкрыццё папак з файламі ў файлавым мэнэджару PCManFM - імгненна.

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

Цікава, ці шмат у каго сёння захаваўся гэты першы прадстаўнік канчаткова вымерлага сёння сямейства нетбуков?