Изпечатай

[fraxinus]

Имам една идея и никак не ми светва как да я осъществя.

Говорим за файлова система с журнал. В нея всичко се пише по два пъти (представяме си случая data=journal за ext3).
Първа и очевидна оптимизация е да се постави журналът на друго устройство. Така спестяваме половината трафик за запис. Това е ясно как става. Може и върху flash устройство. Още по-добре ако няма хардуерен wear-leveling, но такива май няма в ширпотреб.

Следващата оптимизация, за която си мисля, е файловата система да пише синхронно само върху журнала. Върху файловата система да пише "когато му дойде времето" - тук има варианти, зависи дали искаме производителност, енергоспестяване или тишина. Примерно, писането да е подвластно на noflushd или другите вариации на тема laptop mode, за да си го управляваме от userspace.

Засега не съм се заровил в кода, защото не съм твърде вещ, но пробвах с noflushd (който официално отказва да се занимава с журнални файлови системи), с опцията commit при монтиране на ext3. Засега без успех.

Разсъждението тръгна от домашния компютър, който току развърти диска, за да запише кой се е показал на icq и в колко часа, а ако ги няма дребните записчета и почти всичко е в кеша, ще дреме дни наред.

Все си мисля, че е достатъчно просто, за да се е сетил някой преди мен, затова питам тук. Идеи как да стане?

[zeridon]

За ext3 голям commit интервал (30 сек), изключване на atime, пипване на настройките да се използва повечко кеш и други опции около dirty памет.

[gat3way]

Няма нужда да се пише нова файлова система или да се преправя такава

Журналът винаги се изписва *веднага*, не се минава през кеширане. Иначе нямаше да има особена файда от него

Относно това колко време и какъв обем dirty данни стоят преди да се изпишат, всичко това е въпрос на настройки (ls -l /proc/sys/vm).

Казвам *веднага* а не веднага, защото на ниво блоково устройство имаме още малко мероприятия свързани с I/O scheduling-a, поради които не е точно веднага, но да речем доста по-бързо, отколкото времето за което dirty данните ще се изпишат върху диска.

Прекаленото кеширане не е добра идея обаче, поради две важни причини - 1) изисква памет и 2) прави въстановяването след крашване на системата по-грозно.

Примерно ако сет-неш много голям интервал от време през което се flush-ва dirty кеша (dirty_expire_centisecs / dirty_writeback_centisecs) в един момент dirty данните ще надхвърлят определен процент от паметта (dirty_background_ratio) и pdflush ще тръгне да записва стотици мегабайти неща от рам-та върху диска. Ще заплатиш за това че прекалено дълго време си карал с бързо и безшумно писане със един груб период, в който по-голямата част от РАМ-та ти се изписва върху диска и през това време диска стърже и системата се влачи

[tarator]

fraxinus, отдавна има "журнални" файлови системи, в които данните се записват само веднъж. Остърхаут е написал първата за операционната система Спрайт.

Не съм абсолютно сигурен, но ми се струва, че грешиш с твърдението, че всички данни се записват два пъти, в това няма никаква логика. Доколкото знам в журнала се записват само промени в метаданните.

[fraxinus]

zeridon :
Точно това не искам да направя. commit=30 отлага и записа в журнала до 30 секунди. Аз искам журналът да е синхронен, за да не губя данни. А останалата част от файловата система да не е.

gat3way :
> Журналът винаги се изписва *веднага*, не се минава през кеширане.
категорично невярно, поне за ext3 - виж настройката commit при монтиране и отговора на zeridon. Нормално се записва веднъж на 5с, можеш да го накараш да се записва веднъж на половин час. Е, аз не искам на половин час, *веднага* напълно ме устройва. За ext3 към *веднага*  се добавя минимум секунда, но това също е приемливо. Reiser май наистина пише лога *веднага*.

Ще разгледам какво ми предлагат dirty_* нещата - може оттам да излезе заек. Не бях стигнал до тях, а звучат обещаващо.

Всъщност основната ми идея е не толкова за производителност (макар, че има смисъл), а за тих домашен компютър или лаптоп. Повечето време такъв компютър се използва със спорадична активност, с нискоинтензивни процеси (комуникатори, браузър, продължително четене или писане на текст, на разни системни процеси нещо им хрумва да логнат). Всичко, което искаш да четеш, все едно е в кеша, а всичко, което искаш да пишеш (кеш на браузера, история на комуникатора, --mark-- на syslog, поздравите на apcupsd към майката на ЧЕЗ), е 100кБ/час, но не наведнъж, а по 1-5к на всеки 1-5 минути. Заради това, обаче, той развърта диска всеки път. Ако може, да го събира в журнала, който е на flash, и да го преписва веднъж на ден, където му е мястото. Това преписване я му отнеме секунда, я не (защото данните са малко).

Другото приложение на идеята би бил голям mail сървър, който, поради естеството на работата си, страда от периодични изблици на четене и писане (отделно), а също и периоди на относителен покой. Е, като се съберат изблик на четене и изблик на писане заедно, четенето страда (файловата система има основтелна причина да дава приоритет на писането, а дисковият тракт има идиотска латентност между четене и писане, особено, ако е хардуерен raid). От бавното четене страда потребителят. Който пък се старае да разпространи това си страдание върху мен. Е, супер ще е, ако попречим на писателния трафик да смачква четенето, без да изгубим надеждността. Например като събираме писането в журнала и го връщаме на диска в периодите на покой.

И в двата случая, спирането на системата няма да доведе до загуба на данни (те са си в журнала), а записът ще е много по-добре организиран.

tarator:
Знам, че има такива файлови системи. В линукс например има jffs2. По ред причини изобщо не ги бива за диск, освен за някакъв много необичаен access pattern.
Това дали всички данни или само метаданните да се пишат в журнала е настройка, поне за ext3. Аз ДЪРЖА всички данни да отиват в журнала. Искам консистентност не само на метаданните, но и на съдържанието. Е, поне за този случай, двукратното писане ми е сигурно.

[gat3way]

Хм...прав си, като гледам, журналът се изписва през някакъв интервал.

Обаче под "data" не вярвам да се разбират всичките dirty pages, а предполагам само съдържанието на суперблоковете. Иначе би било брутално, прекалено голямо изключение от установените неща.

[smelkomar]

При тези цени на твърдите дискове е смешно да нямаш RAID 1 дори на домашната бракма. Те т'ва е бекъп...

[gat3way]

Хммм сега прочетох това:

Е, като се съберат изблик на четене и изблик на писане заедно, четенето страда (файловата система има основтелна причина да дава приоритет на писането, а дисковият тракт има идиотска латентност между четене и писане, особено, ако е хардуерен raid). От бавното четене страда потребителят. Който пък се старае да разпространи това си страдание върху мен. Е, супер ще е, ако попречим на писателния трафик да смачква четенето, без да изгубим надеждността. Например като събираме писането в журнала и го връщаме на диска в периодите на покой.

На ниво блоково устройство за такива сценарии се грижи I/O scheduling-a, отделно SATA дисковете хардуерно имат нещо подобно, наречено NCQ. Има няколко алгоритми за това, ако искаш виж това:

http://en.wikipedia.org/wiki/CFQ

[tarator]

Да разчиташ на RAID1 за backup е доста малоумно, да не говорим, че не защитава от изтриване на данните погрешка. Аз например имам копие на всичките си данни от 2005 насам, всеки ден и мога да "гледам" как се е променяла файловата система. При това имам копия на хард диск и DVD-R.

[teh]

Нахвърлям и аз някакви мисли върху мнения от постовете ...

Това с натоварения мейл сървър и страдащия клиент изглежда малко преувеличено. Какъвто и да е scheduler-а за работа с блоковото устройство едва ли ще има фрапантно забележима разлика при клиента. Ако трябва да скалираш нещо такова определено според мен по-добрия вариант да добавиш повече ресурс (след допустимото стандартно "оптимизиране" на FS) под формата на повече едновременни обслужени requests за писане/четене е просто добавянето на повече  spindles/disks. Един средностатистически SATA диск повече от 200-250 такива request-а трудно прави ;-) Обслужването на такива пикове според мен не се забелязва значително ... стига наистина да са кратки.

Другото нещо за което се сещам е, че за консистенция при ext3 само journal data опцията не е достатъчна. Имат значение barrier опцията (която пък не работи през md/dm в linux) и write cache на диска дали е включен. Т.е. или едното или другото ... по-сигурния вариант е с изключен write cache.

Отделно пък ако пишеш по някакъв начин metadata + data наистина синхронно някъде, за какво ще ги пишеш втори път след това?

Дискусията е интересна.

[senser]

не защитава от изтриване на данните погрешка

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

[tarator]

Защитата я казах -- бакъп на DVD-R, забележи не DVD-RW

[bnight]

tarator тук ми стана интересно може ли да предоставиш някакви материяли по темата как точно си изградил backup системата си така че да пази данните ти от 2005-та на сам по дни както се е променяла файловата система. Би ми било интересно да видя такова решение добре докоментирано. Предварително ти благодаря за отделеното време да ми отговориш.

[tarator]

За архивна система използвам Venti. Първоначално venti e писан за Plan9, но е включен в порта на Plan9 приложения за Posix Plan9Port (http://swtch.com/plan9port/). Как работи venti и начини да се използва са описани в статията на двамата Шоновци (които са и автори на първата версия) http://plan9.bell-labs.com/sys/doc/venti/venti.pdf

Venti от гледна точка на потребителя

За потребителя venti e програма, която архивира колекция от файлове и връща идентификатор, с който те могат да бъдат четени по-късно. Файловете се архивират с командата vac.

Код:

$ export venti=192.168.0.10
$ vac work
vac:0d3fc5aad2621af41abc8f661facc34fdebba57b

Резултатът от vac e 20 байтово число, наречено score. То може да бъде използвано по два начина за достъп до данните. Командите по-долу предполагат, че score-a e записан във файла vacfile.

1. С командата unvac може да се извлекат всички файлове.

Код:

$ unvac vacfile

2. С командата vacfs те могат да бъдат представени като 9P2000 файлов сървър и след това да се монтират в Линукс използвайки v9fs (aka 9p).

Код:

$ vacfs vacfile
$ mount -t 9p /tmp/ns.$USER/vacfs.t /mnt/vac -o trans=unix
$ ls /mnt/vac

Интересното при venti е, че нов запис на същите данни не заема (почти) никакво място в архивната система. Например ако в мрежата има 10 компютъра с Федора и единствените разлики са малки промени в конфигурациите, архивирането им в Venti ще заеме малко повече място отколкото архивирането на един компютър. Ако директорията ми work e 10GB и я архивирам днес, променя 100К в няколко файла и я архивирам пак, второто архивиране отнема само 100К. Но ако използвам втория score-a ще виждам _всички_ файлове, които са били в work, а не само променените.

Друга интересна черта на venti е, че след като запишеш нещо, никога повече не можеш да го изтриеш. Venti поддържа добавяне на данни и извличането им, но не триенето им. Една от причините е да може да поддържа инкременталното архивиране. Това може да е неприятно (например ако погрешка запишеш колекцията от порно в архива), но пък има и предимства. Дори и погрешка не можеш да изтриеш архивни данни, които да се окаже, че ти трябват по-късно.

Та моята бакъп система е проста. Всеки ден (да кажем 8 декември 2008) в определен час правя vac на всички файлове, които искам да запазя и записвам score-a в /archives/2008/12/08/all.vac. Ако искам да видя файловете от този ден, мога просто да монтирам (с vacfs и 9p) съответния vacfile. За удобство, след това изпълнявам vac още веднъж върху директорията /archives със специалната опция -m, която "залепя" дърветата представени от .vac файловете в съответната директория на мястото на самия файл. По този начин получавам един vac file -- /archive.vac. Ако го монтирам в /mnt/vac и искам да видя какво е съдържанието на файловете на 3 януари 2006, просто правя

Код:

cd /mnt/vac/2006/01/03

и виждам всички файлове точно както са изглеждали на този ден.

Venti не направен така, че да е удобно данните в архива да се копират на външен носител. Дисковото му пространство е разделено на 512МБ арени.  Понеже от venti не може да се трие, когато една арена се напълни, venti я "запечатва" и тя никога повече не се променя. В този момент арената може да бъде записана на външен (непроменяем) носител за по-голяма сигурност. В добавка, може да се запише SHA1 сумата на всички данни от арената на непроменяем носител и от време на време да се сравнява с SHA1 сумата на арената на диска (в случай, че някой хахор все пак реши да промени съдържанието на архива).

Аз имам скрипт, който пускам на ръка и създава iso файлове на всички арени, които не съм записал от последния път когато съм изпълнявал скрипта. След това записвам всички ISO-та ръчно на DVD-R дискове, освен последния (непълен), който записвам на DVD-RW. Засега имам някъде към 70 DVD-та с копие на архива, което е по-малко от DVD на седмица откакто съм започнал да архивирам.

Освен че записвам archive.vac на харддиска, също така го изпращам на email адрес, който е напълно независим от домашната ми система. Ако (чукам на дърво) някой ден се случи нещо вкъщи, от този score и съдържанието на DVD-тата мога да възстановя всички данни, освен тези които не съм записал още на външен носител. След 2 години ще презапиша всички DVD-та на нови носители за да съм сигурен, че няма да се повреди някое от тях.

Във venti в момента пазя архив на 3 компютъра -- сървъра вкъщи, служебния лаптоп и стария ми личен лаптоп (който отскоро е Plan9 сървъра ми вкъщи). Скоро ще пусна да се архивира и новия ми личен лаптоп.

Venti от гледна точка на администратора му

Инсталирането на venti е сравнително лесно, няма да го описвам в подробности. Venti изисква три партишъна/файла -- index file, arenas file и bloom filter. Arenas файла/дяла съдържа всички данни и трябва да е колкото може по-голям. Аз започнах с 30GB диск, след това го преместих на 300GB диск, скоро добавих още един 750GB диск. Ако дяла/файла започне да се пълни, в конфигурацията на Venti може да се добави нов arenas file и venti ще започне да използва и двата (или повече). Index файла съдържа хеш таблица, която позволява на venti да работи бързо (виж по-долу кратко описание как работи venti). Размерът му трябва да е около 5-10% от размера на arenas файла. Данните в index файла не са жизнено важни, ако се изгубят могат да бъдат генерирани от arenas файла. Venti може да работи с повече от един index файл, но при добавянето на нов трябва да се регенерира целия индекс (отнема десетина минути). Bloom файла пази стойностите на Блуум филтъра, който се използва от venti да ускори работата още повече. Обикновено файлът е 32 или 64МБ, зависи от конфигурацията.

Аз имам дялове на отделен диск за index и arenas, bloom е обикновен файл на основната ми файлова система.

Как работи Venti

Venti може да изпълнява две операции: архивиране на блок и извличане на вече архивиран блок. След като архивира даден блок, venti връща уникален адрес, който идентифицира блока в архивната система. Този адрес зависи от данните в блока, всъщност той е точно SHA1 сумата на данните. Ако впоследствие на venti бъде изпратен друг блок, проверката дали тези данни са вече в архивната система е лесна -- смяташ SHA1 сумата на новия блок и проверяваш дали резултатът го има в index файла. Ако отговорът е да, отговаряш че блокът е архивиран без да правиш нищо. Иначе записваш новия блок в активната арена и добавяш score-a му в индекса. Ако клиентът иска да прочете даден блок по score-a му, намираш го в индека, проверяваш в коя арена е той (пише го в индекса), четеш и връщаш резултата. Интересното е, че клиентът може независимо от сървъра да провери дали върнатите данни са това, което е поискал -- просто смята SHA1 от получения блок и ако резултатът е различен от score-a, знае, че някой го е излъгал (това за параноиците, които се страхуват от хахори ). Блоковете са с размери до 56К (не знам защо точно толкова). Ако трябва да се запишат по-големи файлове, те се разделят на блокове (обикновено 8К), записват се, след това score-овете на тези блокове се организират в нови блокове, които се записват и така рекурсивно докато накрая се получи единствен score, който е адрес за целия файл. По-подробно описание има в статията, която споменах по-горе.

Ако на някой му е интересно, мога да му пратя скриптовете, които използвам. Елементарни са, няма нищо сложно в нито един от тях.

Мързи ме да прочета всичкия текст дето съм написал, предварително се извинявам за правописните грешки

[bnight]

tarator мерси за подробното описание на системата която ползваш за backup струва ми се доста интересно и ще разгледам как мога да го приложа в средата която аз ползвам. Още веднъж много благодаря за отделеното време и подробните разяснения.