В допълнение на интересуващия ни склад store, трябва да се даде и големината на блоковете block_size. Може да се даде препоръка колко да е голям кешът на блоковете cache_size_hint, т.е. общия обем за данни, заеман от буферите. Аргументът bucket указва къде да се сложи портовото право за изваждане на обекта за памет на използвания страницатор. Може да бъде NULL, при което библиотеката си създава собствен bucket.

Освобождаване на кеш на буфери.

Тази функция връща буфер, който съдържа истинския блок. Броячът на потребителите на буфера се увеличава. Единствената легална употреба на получения буфер е използване на полето-указател data, което сочи съдържанието на блока.

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

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

Има само една функция, която пряко работи със сенки:

Функцията прави копие на буфера buffer. Копието може да бъде в друг кеш target_scache, или в същия, което може да бъде отбелязано чрез предаване на NULL. Копирането може да запише съдържанието на един блок в друг блок с номер target_block, или в същия номер на блок, което може да бъде отбелязано чрез предаване на SCACHE_NO_BLOCK. И накрая, целевият буфер може да бъде нов буфер-сянка, което се задава чрез ненулева стойност на want_shadow. Ако се иска сянка, тя винаги е нова сянка, а ако се иска истински буфер, той винаги е единственият буфер за този блок в целевия кеш. На получения буфер се увеличава брояча на потребителите, но както вече беше казано, за да се освободи буфер-сянка, не само броячът на потребителите трябва да е нула, но и буфера-сянка да не е в нито една група.

Създаване на нова група от буфери.

Унищожава групата от буфери bufset. Преди това всички буфери от групата се изключват от групата

Добавяне на буфера buffer към групата от буфери bufset. Буферът трябва да е от същият кеш, какъвто е и на групата. Също така в групата не трябва вече да има друг буфер за същия блок, т.е. един и същ буфер може да се добавя много пъти в групата, но ако се добави друг буфер за същия блок, например буфер-сянка, ще бъде върната грешка EEXIST.

Буферът buffer се изключва от групата буфери bufset.

Проверява дали буферът buffer е в групата bufset. Ако е там, връща се buffer, иначе се връща NULL. Буферът buffer трябва да е отчетен като потребител, но това не се консумира.

Търси дали в групата bufset има буфер за блок block, дори и да е буфер-сянка. Ако има, увеличава му се броячът за потребителите и буферът се връща като резултат. Ако няма, връща се NULL.

Връща взетия от групата bufset чрез scache_bufset_get буфер buffer.

Функцията func се извиква за всеки буфер на групата bufset. Аргументът arg се предава като втори аргумент на func.

Всички буфери с променено съдържание от групата bufset се записват в склада. Ако wait не е нула, при връщането от функцията всички буфер са синхронизирани. Буферите-сенки не се влияят от тази функция.

Игнорира промените във всички буфери от групата bufset. Следващият достъп до който и да е буфер ще прочете оригиналното непроменено съдържание на блока. Ако wait не е нула, при връщането от функцията всички промени в буферите са игнорирани, иначе ефектът може да дойде малко по-късно. Буферите-сенки не се влияят от тази функция.

Структурата scache представя един кеш на буфери. Броят на буферите се определя при създаването на кеша и не може да се променя по-късно. Винаги се използва препоръчвания размер, който се дава на scache_open. Този размер се разделя на исканата големина на блок и така се получава броя на буферите.

Полето buffer сочи към масив от всички налични буфери. Съответните им данни са в соченото от image пространство. Така, имайки номера на буфера, лесно може да се изчисли къде са неговите данни, както и имайки указател към данни, да се изчисли на кой буфер съответстват. Обаче буферите-сенки не пазят данните си в image.

Главната причина за поставянето на всички данни в непрекъсната област от адресното пространство е, за да може да се използва libe3pager. Така libscache напълно определя какво съдържание ще има всяка страница от тази област. За целта са определени потребителски функции scache_pager_* за всички нужни потребителски функции pager_*, които се използват от libe3pager. Това позволява потребителят да има собствени страницатори. Потребителят трябва да определи функциите pager_*, които винаги приемат като един от параметрите си pager_info, който е указател към тип struct pager_info. Ако първата 32-битова дума, сочена от указателя, е SCACHE_PAGER_INFO_MAGIC, то потребителят трябва да остави libscache да обработи извикването чрез съответната функция scache_pager_*.

Изображението от номер на блок към истински буфер се пази в полето hash. Буферите-сенки не се отразяват по никакъв начин на това изображение, а могат да бъдат достигнати само чрез групите от буфери.

При искане на блок, който го няма в кеша, scache_get трябва да пренастрои някой буфер така, че да съдържа искания блок. Тази операция е същността на библиотеката. Първо, трябва да се намери подходящ буфер. Преди всичко той не трябва да се използва в момента, т.е. броячът на потребителите му трябва да е нула. След това трябва да е такъв, че да е не е използван наскоро. Това се постига чрез търсене на буфер, чието съдържание е изтласкано от адресното пространство. Страницатор на libscache чрез scache_pager_notify_pageout се грижи винаги да поддържа информация кой буфер е изтласкан и кой – не. Търсенето на такъв буфер започва от буфер hint и продължава последователно. Ако се стигне последния буфер, преминава се към първия. След като се намери буфер, hint става следващия буфер. По този начин винаги се търси първо измежду най-старите буфери, защото за да се стигне до току-що избрания буфер, hint трябва да обиколи всички останали буфери.

Ако все пак не се намери буфер, отговарящ на условията, прави се опит да се изтласкат всички буфери, който имат нулев брояч на потребителите. После се пробва пак.

Полето block е номерът на блока, съдържащ се в буфера, а data сочи към данните на буфера. Тези две полета е позволено да се използват от потребителите, но само за четене. При истински буфер data може да се изчисли, но когато буферът е сянка, това е допълнително заделена чрез mmap памет. Това изисква и допълнителни действия, когато буферът се свързва с друг блок от диска. За улеснение буферите-сенки се освобождават веднага, след който никой вече не ги използва. Условието за това е броячът на потребителите да е нула и те да не са в никоя група от буфери. В момента, когато това стане изпълнено, например чрез scache_put или scache_bufset_remove, буферът-сянка става истински буфер, който обаче не сочи към блок.

Полето bufsets е изображение и служи като множество на групите, в които буферът е включен. Ключът и стойността в това изображение съвпадат и те са групата.

Полета flags показва дали буферът е в паметта (SCB_INCORE) и дали е сянка (SCB_SHADOW). Флагът SCB_UNREAD се използва при свързване на буфера с друг блок от диска. Проблемът е, че трябва буферът за малко да се отключи. През това време може някоя друга нишка също да търси буфер и да използва този буфер, който сме избрали. За да се избегнат проблемите, буферът се отбелязва като недокосван, отключва се и след като пак се заключи, проверява се дали някой не го е докосвал. Ако е докосван, този буфер се оставя и търсенето на подходящ буфер за блока продължава.

Последното поле е ref_count и то съдържа броя на потребителите, които използват в момента този буфер.

Полето buffers е изображение и служи като множество на буферите в групата. Ключът е номерът на блока, а стойността е буферът на този блок. В една група не може да има два буфера за един и същ блок, но може да има буфери-сенки.

Библиотеката очаква да работи в многонишкова среда. За целта трябва да се изгради дисциплина за достъп до структурите. Всяка структура има поле-ключалка lock. За достъп до всяко поле, което търпи промяна, трябва структурата да е заключена. Пример за поле, което не се променя, е scache на bufset. Редът на заключване винаги трябва да е scache, bufset и накрая buffer. Ако не се използва някоя от тези структури, заключването й може да се прескача, но, например, не може да се заключва buffer и после, докато той е заключен, да се заключва scache. Обратният ред е забранен за да се избегне мъртва хватка (deadlock).

#define JSTORE_OPEN_RECOVER   (1 << 0)
#define JSTORE_OPEN_READONLY  (1 << 1)

Отваряне на журнала, съхраняван в journal_scache. Данните, които се журнализират, са в data_scache. Аргументът flags настройва отварянето. Флагът JSTORE_OPEN_RECOVER разрешава автоматичното възстановяване на съгласуваността на журнализираните данни, ако в журнала има информация за това. Флагът JSTORE_OPEN_READONLY отваря журнала в режим само за четене. Това забранява връщането на буфери чрез jstore_block_put на променени блокове.

Промяна на режима на журнала – дали журналът ще е само за четене, или и за четене, и за промяна. При режим само за четене е забранено връщането на променени буфери чрез jstore_block_put. При този режим журналът е напълно „чист“ и не е строго необходимо да се изпълни jstore_close, за да изглежда журналът празен.

Затваряне на журнала jstore.

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

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

Завършване на атомарната промяна update.

#define JSTORE_GET_CREATE     (1 << 0)
#define JSTORE_GET_COMMITTED  (1 << 1)
#define JSTORE_GET_DATA       (1 << 1)

Връща буфер за блока block, който да се чете и/или променя като част от атомарната промяна update. По подразбиране се приема, че се искат метаданни, освен ако не е зададен флагът JSTORE_GET_DATA. Ако е зададен флагът JSTORE_GET_CREATE, предишното съдържание на блока няма значение и той трябва да се получи нулиран. Това е малка оптимизация. Ако е зададен флагът JSTORE_GET_COMMITTED, иска се съдържанието на метаданни както вече са записани в завършена транзакция. Този флаг не трябва да се използва с друг флаг.

#define JSTORE_PUT_NOTMODIFIED  (1 << 0)
#define JSTORE_PUT_FORGET       (1 << 1)
#define JSTORE_PUT_REVOKE       (1 << 2)
#define JSTORE_PUT_CLEAN        (1 << 3)

Връщане на буфера buffer, взет за атомарната промяна update. Ако не е променян, това трябва да се отбележи със задаването на флага JSTORE_PUT_CLEAN. Ако промените в буфера трябва да се игнорират, задава се флагът JSTORE_PUT_FORGET. Ако буферът е взет като метаданни и с тази атомарна промяна вече няма да се използва като метаданни, т.е. вече може да се използва за данни, трябва да се зададе флагът JSTORE_PUT_REVOKE.

Полетата journal_scache и data_scache сочат кешовете на журнала и на файловата система, съответно. Полето is_readonly показва дали режимът на журнала е само за четене.

Главният блок на журнала често се променя. Затова има полета за него. Буферът е superblock_buffer, като съдържанието му се сочи от superblock. За да може лесно да се записва, superblock_bufset е група, включваща само буфера на главния блок. Така записването на блока се състои в извикването на scache_bufset_return.

Транзакциите са от 3 типа: текуща, записваща се и изчакваща. Текущата е running_transaction, записващата е committing_transaction, а групата от изчакващите транзакции се слага в изображението checkpointed. В него ключът и стойността са самата транзакция.

Полето checkpointed_holes е вектор на освободените места в журнала, които са след tail_block. Полетата checkpointed_holes_count и checkpointed_holes_size са съответно текущата големина на вектора и заделената му големина.

Полето next_sequence е следващия номер, който да бъде използван за транзакция. Най-старият все още използван номер е tail_sequence.

Първият и последният блок от журнала са first_block и last_block-1, съответно. Следващият блок за заделяне е head_block, а tail_block е последният заделен блок. Така че заетите блокове в журнала са от tail_block до head_block-1, като при достигане на края на журнала (last_block), се продължава с началото (first_block). Незаетите блокове са free_nblocks на брой.

Кодът на фаталните грешки (като лош блок например) се пази в err.

При поискване на блок от страна на потребителя, важно е да знаем в коя транзакция се намира буферът, съдържащ този блок. За целта all_blocks е изображение от номер на блок към група от буфери, където се намира буфера на този блок. Имайки групата, сравнително лесно е да определим и самия буфер, както и транзакцията, в която е той. Обаче е възможно да не намерим блока в дадената група. Причината е, че той може автоматично да е изключен от групата, ако е в изчакваща транзакция. За ранно откриване на такива проблеми се използва групата all_blocks_bufset, която обхваща всички буфери, използвани от журнала.

Полето condition се използва за „разгласяване“ (broadcast), че има промяна в running_transaction или committing_transaction.

„Условието“ (condition) condition служи за синхронизиране. Чакането за промяна в ref_count се заключава в чакане на това условие, което се „разгласява“ (broadcast) след извършване на промяна в ref_count. Това се използва, когато заявка за commit на текущата транзакция чака всички атомарни промени в текущата транзакция да завършат.

В полето jstore е журналът, към който принадлежи транзакцията.

Номерът на транзакцията се съдържа в полето sequence.

Полето revoked е хеш-таблица, представяща множество от revoked блокове в тази транзакция. Ключът и стойността са номера на блокове.

Транзакциите обхващат няколко групи от буфери. Тези групи са:

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

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

Checkpoint транзакциите трябва да съдържат информация за това кой отрязък от журнала са ангажирали, за да се знае кои части от журнала са свободни за повторна употреба. Началото и края се пазят в полетата begin и end.

В тази структура няма почти нищо. Държат се указатели към журнала и транзакцията в полетата jstore и transaction съответно.

Важното поле е credits, което показва колко блока са дадени на разположение на тази атомарна промяна.

Нека файл е само в една директория, т.е. няма твърди връзки от други директории. Ако някой процес отвори този файл и той се изтрие преди затварянето му, тогава продължава да съществува на диска, въпреки че не се реферира от никоя директория. Това е специфична семантика на изтриването на файл във всички UNIX варианти. При внезапно спиране на транслатора и последващо преиграване на журнала ние ще получим файл, който заема блокове с данни и не може да бъде достигнат по никакъв начин, понеже го няма в никоя директория. Файловата система не е съгласувана.

Този проблем не може да бъде избягнат единствено със средствата на журнала. За целта в ext3 се поддържа едносвързан списък на файлови описатели, които не се реферират от никоя директория и трябва да бъдат изтрити след преиграване на журнала, когато транслаторът е бил прекъснат внезапно. Тези файлови описатели се наричат осиротели (orphaned) и функциите за тяхната обработка се намират в ext3fs/orphan.c.

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

За предотвратяване на този случай се използва списъка на осиротелите файлови описатели. Семантиката на осиротелите файлови описатели се променя по следния начин: