Покажи Публикации - fraxinus
* Виж публикациите на потр. | Виж темите на потр. | Виж прикачените файлове на потр
Страници: [1]
1  Linux секция за напреднали / Начини за увеличаване на бързодействието / Re: "полу-отложен" запис -: Nov 29, 2008, 22:58
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. Аз ДЪРЖА всички данни да отиват в журнала. Искам консистентност не само на метаданните, но и на съдържанието. Е, поне за този случай, двукратното писане ми е сигурно.
2  Linux секция за напреднали / Начини за увеличаване на бързодействието / "полу-отложен" запис -: Nov 29, 2008, 13:32
Имам една идея и никак не ми светва как да я осъществя.

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

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

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

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

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