KitLog A Generic Logging Service Un service de journalisation g?en?erique Michel Ruffin Projet SOR Institut National de Recherche en Informatique et en Automatique & Laboratoire de M?ethodologie et Architecture des Syst?emes Informatiques , Universit?e Pierre et Marie Curie , Paris VI | | | | | | | | Tel : +33 -LRB- 1 -RRB- 39 63 54 26 , E-mail : ruffin@sor.inria.fr May 1992 Rapport de Recherche INRIA Nffi1678 Abstract Many applications use a log to store state , either to \ redo '' past actions , or to correct possible faults , errors or loss of consistency . A generic logging service should cater to the variable and even antagonistic needs of applications , without imposing overhead on applications which do not use all its functions . For instance , a transaction manager needs a different degree of reliability than a debugger . KitLog provides an original solution to this problem by decomposing and encapsulating logging functions . Five main mechanisms are distinguished : buffering policy , distribution of records , replication of records , sharing and multiplexing mechanisms , and management of physical media . Each mechanism is embodied in an object class . For each class , multiple policy implementations can be provided . Instances of these classes are stackable in any appropriate number or order . An application programmer customizes his logical log to a set of failure assumptions by selecting adequate classes , instantiating them , and connecting the instances together . Thus , the application pays only the cost of the logging functions it chooses . R?esum?e De nombreuses applications utilisent un journal pour stocker des ? etats , soit pour refaire des actions pass?ees , soit pour corriger les effets de pannes , d'erreurs ou de pertes de coh?erence dues au parall?elisme . Un service g?en?erique de journalisation doit s ` adapter aux besoins variables , voir antogonistes , des applications , sans imposer un surco ^ ut aux applications qui n'utilisent pas toutes ses fonctions . Par exemple , un gestionnaire de transactions n?ecessite un degr?e de fiabilit?e diff?erent d'un d?ebogueur . KitLog fournit une solution originale ? a ce probl?eme en d?ecomposant et en encapsulant les diff?erentes fonctions de la journalisation . Cinq principaux m?ecanismes sont distingu?es : la politique de gestion des tampons , la distribution d'enregistrements , leur r?eplication , les m?ecanismes de partage et de multiplexage , et la gestion des ressources physiques . Chaque m?ecanisme est repr?esent?e par une classe d'objets . Pour chaque classe , diff?erentes r?ealisations peuvent ^ etre fournies . Les instances de ces classes sont composables dans n'importe quel ordre appropri?e et en n'importe quel nombre . Un programmeur d'applications adapte son journal logique ? a un ensemble d'hypoth ? eses de pannes , en choisissant les classes ad?equates , en les instanciant , et en connectant les instances ensemble . En cons?equence , l'application paye uniquement le co ^ ut des fonctions de journalisations qu'elle utilise . Mots clefs : Journalisation , service g?en?erique , composition d'objets , KitLog . II Requirements I Introduction Two main observations have motivated this work . The first one is that distributed operating systems provide different reliability levels . Most of the traditional algorithms that ensure fault tolerance -LRB- such as two step commitment -LSB- Baer et al. 81 -RSB- , recovery protocols -LSB- Gray et al. 81 -RSB- and concurrency control -LSB- Bernstein and Goodman 80 -RSB- -RRB- need a reliable log . Logs are the greatest common divisor of most reliability mechanisms . The second incentive stems from the increasing number of applications implementing logs customized to their specific needs . Until now , a generic logging tool satisfying all their requirements has not existed . Log management is hard to implement correctly and efficiently . A generic service would allow application programmers to save their time . As examples , Camelot -LSB- Daniels et al. 87 , Daniels 88 -RSB- and QuickSilver -LSB- Haskin et al. 87 -RSB- use a log for transactions management and failure recovery . Emacs uses an in-memory log to undo and redo file modifications . Instant Replay -LSB- Leblanc and Mellor-Crummey 87 -RSB- uses a log to replay debugging sessions . Isis -LSB- Birman et al. 89 -RSB- implements a log for communications reliability . Sprite -LSB- Rosenblum and Ousterhout 91 -RSB- stores its complete file system on a log increasing its write efficiency . This paper is composed of two parts . First , it describes a generic service for logging , a high-level object oriented design called the KitLog model . Then , it presents one of the possible log management policy design , corresponding to the current prototype . II Requirements Designing a generic logging service starts with a study of the application requirements . These have points in common and divergent features . Commonalities The common characteristic of all logs is the append-only storage semantics . In this section , we describe these semantics , illustrating them with an interface -LRB- see Figure 1 -RRB- . This interface is a basic log one . Operations names and arguments can be changed from one implementation to another but the operation semantics must be unchanged . For the sake of clarity , we supposed that a log storage unit exists called the record , and constituted of an opaque data block of any size . Because of the append-only semantics , records are stored in Appending records put -LRB- Lid , Rid , D , S -RRB- put -LRB- Lid , & Rid , D , S -RRB- Giving obsolete record list to the system for compaction invalidate records -LRB- ... -RRB- Reading records backward get last -LRB- Lid , & Rid , & D , & S -RRB- get prev -LRB- Lid , & Rid , & D , & S -RRB- Reading records forward get -LRB- Lid , & Rid , & D , & S -RRB- get next -LRB- Lid , & Rid , & D , & S -RRB- Forcing writes on storage medium flush -LRB- -RRB- Figure 1 : Basic log interface Lid : log identifier , Rid : record identifier , D : Opaque record data block , S : record size , & : reference . With the first put -LRB- -RRB- , applications choose the Rid value . With the second one , the logging service generates a Rid . Invalidate records -LRB- -RRB- supports different designations of obsolete records . Get -LRB- -RRB- with Rid of zero returns the first record of the log . the order they arrive . We also assume that records have a record identifier -LRB- Rid -RRB- that is unique within the log . Values of different Rid increase with time , reflecting the record arrival order . Write accesses appends records to the end of the log with the put -LRB- -RRB- operation . A log record may become obsolete : for instance , the record life time of an aborted transaction is that of the transaction . Useless records can be compacted out of the log whenever possible . The invalidate records -LRB- -RRB- operation allows clients to indicates obsolete records to the logging service . It can have mutliple forms depending on the indication method -LRB- developed in xV .5 -RRB- . For most applications , reads are uncommon compared to writes . Reads are generally needed when a problem occurs . Reads may be backward or forward . A backward read starts at the end of the log -LRB- get last -LRB- -RRB- operation -RRB- and are done in the reverse order of storage -LRB- get prev -LRB- -RRB- operation -RRB- . Backward reads support undoing past actions . Forward reads supports redo of past actions . By restoring a global state -LRB- or checkpoint -RRB- -LRB- with get -LRB- -RRB- -RRB- and reading records corresponding to further states modifications -LRB- with get next -LRB- -RRB- -RRB- , applications are able to recover all the different execution steps they need . Finally , a flush -LRB- -RRB- operation forces data writes onto the storage media . When this operation returns , all the data buffered in memory are guaran - III General architecture teed to be written on their final storage medium . KitLog supports logical logs . Logical logs are client-level logs , while physical logs are a set of records from different logical logs multiplexed on a single storage medium -LRB- for the sake of clarity , we suppose that there is a single physical log by storage medium -RRB- . For applications ,1 a log is represented by an unique log identifier -LRB- Lid -RRB- . An application may use multiple logs . A log may be shared , or not , between different processes of a particular application , or between separate applications . Records from different logs can be multiplexed , or not , on a storage medium . Differences Logs present several different features . The differences may be quantitative , e.g. different level of reliability , or may be antagonistic qualities , e.g. availability versus consistency . Depending of the application , the log provides a certain degree of reliability . This includes the types of faults which can be tolerated -LRB- e.g. site , disk or network -RRB- , as well as the number of simultaneous occurrences of the same fault type . For instance , some application might require resistance against 5 simultaneous disk faults . A log 's response to some failure should also be tailored to its client 's needs . For instance , an application replicating data with strong consistency semantics might impose strong consistency on log replica , whereas an application needing a high availability degree can choose a weak consistency protocol for its log replication . Records have variable lifetimes . A log can be composed of both persistent and transient records . For example , to ensure the transaction persistence property , old persistent record must be archived while transient records -LRB- for aborted transactions -RRB- have to be compacted out of the log . Finally , some applications require network transparency , whereas others need to control the location -LRB- site , disk -RRB- where the log is stored . 1We use an extended definition of the word application . Applications can be of high or low level -LRB- e.g. a financial software using audit trails , Emacs or a recovery manager -RRB- . For the logging service -LRB- implemented as a set of logging servers -RRB- , application are clients that communicate via a library . III General architecture III .1 Basic principles The KitLog model breaks down logging mechanisms into elementary logging functions like Ficus for file systems -LSB- Heidemann and Popek 91 -RSB- , x-Kernel for communications -LSB- Hutchinson and Peterson 88 -RSB- or System V for streams -LSB- Ritchie 84 -RSB- . Each function is encapsulated in a distinct object class , called a building block class or a block class . All block classes have the same interface , since they all implement the same log semantics . In object terms , all building block classes conform to a single block type . An application programer composes the block classes and instantiates them into a directed acyclic graph of objects . A process uses a particular entry point in the graph which defines the particular logical log properties of the process , depending on the different building blocks that can be reached by this entry point . In the remainder of this paper , a successor of an object is either one of the object 's direct successors in the graph , or by transitivity one of the successors of its successors . We define in the same way a predecessor by replacing in the previous definition the term successor by predecessor . Put -LRB- R -RRB- -LCB- -RCB- objectReplication Object Put -LRB- R -RRB- -LCB- -RCB- Put -LRB- R -RRB- -LCB- -RCB- -RCB- ... ... ... ... Successor 1 Successor 2 ... Object ObjectOp -LRB- ... -RRB- -LCB- Buffering Figure 2 : Object composition Block operations2 -LRB- like put -LRB- -RRB- , get -LRB- -RRB- , etc. -RRB- in block object composition behave in the following way : operations and arguments move from a graph head towards the final storage media -LRB- graph leaves -RRB- following the edges of the graph . When a record -LRB- or a set of records -RRB- crosses a block object , the function embodied by its class is applied to the record . This comportment is similar to that of System V streams operations . 2These operations include the operation of the previous described interface with some modifications and new private operations for inter-blocks invocations . The prototype block interface is describe in xV .2 . III General architecture For instance , in Figure 2 , a put -LRB- -RRB- of record R on a replication object generates a replicated invocation of its successors put -LRB- -RRB- operation . While , a put -LRB- -RRB- of record R on buffering object caches the record in memory . If the buffer is full , the put -LRB- -RRB- operation flushes the buffer by invoking some appropriate operation Op -LRB- -RRB- of its successor that allows it to transfer multiple records to its successor in a single operation . This operation will continue to propagate down the graph until it meets a buffer or a block interfacing a medium which is able to store data . Object composition is based on the separation of type and class . The composition is feasible because , the successor to any block class conforms to the same block type interface . Two kind of objects play a special r ^ ole as head and tail of a log composition graph . A non privileged client 's entry interface to its graph is a logging view object . The final exit interface from the graph onto a storage medium is a medium object . While logging views belong to a separate type -LRB- their interface is roughly that of Figure 1 -RRB- , medium objects are instance of the medium block class which conform to the block type . In the current implementation , using a minidescription language , a graph is described by two configuration files : one file for the server parts and one for each client address space part . Graph parts shared by different applications are protected by being in the server address space . We suppose that graphes are correctly build . Before servers create or reconfigurate the system part graph , instantiating and connecting objects together , it verifies very few things -LRB- no cycle , no unacceptable configuration , etc. -RRB- . Tools are provided to help graph building . III .2 Elementary block classes Log functions have been broken down into five elementary classes : buffering , medium , sharing , distribution and replication . Buffering A buffering class implements log semantics in memory . It may have multiple r ^ oles . The simplest is caching inputs and outputs . It may also act as filter . Cached records are temporary or permanent . If the client application has declared a list of obsolete records , they are compacted out of the buffer , before transferring records to the buffering block successor . Other r ^ oles are possible , such as data storage structuring . For example , it is possible to gather records of some particular kind contiguously , rather than in arrival order , by using a different buffering block object for each kind , and multiplexing the record packets with a sharing block object . If needed the flushing level -LRB- number of flushed successors -RRB- can be controled by clients applications . Medium Medium classes are the interface to resources which do not necessary conform to the block interface . Each medium sub-class drives a particular kind of resource , e.g. disk , tape , terminal , process or file . A medium object has no successor within the log graph . Sharing A sharing block class has multiple predecessors . It implements a sharing policy of its successor by its predecessors . It manages concurrent access , record multiplexing and access control . This control is perfomed at connexion time , i.e when connecting an object as a predecessor of a sharing object . Distribution A distribution class encapsulates distribution and communication between building blocks on different sites and address spaces . It establishes communication , and sends and receives records . Such a class encapsulates communication protocols and policies chosen in case of communication failures . This object class does not cache records . If one wants to gather records within a single message , a distribution object must have a buffering object as predecessor . When a buffer flush is necessary , the buffering object invokes the distribution object operation that transfers record packets between two blocks , initiating the emission , in a single message , of the buffer of records . Replication Finally , a replication class manages record replication on different successors . A replication class embodies a replication policy . It implements a recovery algorithm that depends on the replication protocol and the synchronization of operations on its successors . A replication block handles a fixed number of replica . This number is called its replication degree . Depending of the way successors are bound to the block -LRB- see xIII .4 -RRB- , their number can be greater or equal than the block replication degree and the replica can be stored by different subsets of successors . Implementation of different policies III General architecture A building block function may be implemented by several classes , each implementing a different protocol . For instance , various replication classes are possible , implementing strong , weak or release consistency . Other classes Client programmers can add new logging functions by adding new block classes . For example , an encryption class could enforce log security , or a class could multiplex client-level sub-logs into a single service-level log . These possibilities are open issues . III .3 Log example Figure 3 shows a complete example of a log instantiation . The log is replicated on two sites : site A is a storage site ; site B is a control site . A log server on site A enables different clients to share the logging media via a sharing object . On site A , log records are cached by a buffering object before being replicated on two disks . These objects are instantiated in the server , making disk sharing possible . D > TP SRD V D D M VBR D D SB DM R DM BR TM PM > T P View Terminal Process SharingReplication Distribution Key of figure Site A Site B Site A Disk Medium Storage server Control server B ClientsOther Client Buffering Figure 3 : Log example The second sit?es server buffers client records before displaying them on a terminal and transferring them to a monitoring process . Starting at the top of the graph , the client logging view transfers records to the two servers via a replication object . Distribution objects are needed , first to communicate with the remote server B , and second , to change the address space on site A . The buffer object gathers records before sending them to the servers to minimize the number of messages . III .4 Dynamic reconfiguration The graph can be re-configurated dynamically to react to faults of system elements , depending on the way objects have been bound together . The binding method is defined at graph configuration time by the successor method designation . Object successors can be designated in two different ways . First by identity : a client names sites and storage media on which the log will be stored . For instance , one can request something such as : \ a log replicated on disks X and Y of site A and on disks X and Z of site B '' .3 This designation method corresponds to static binding , which does not enable any reconfiguration . The second designation method is functional : successors are designated by their class name rather by their identity . Thus , a client could request : \ a log replicated on two sites , and on two disks of each site '' . In this case , the logging service chooses the sites and the disks among those available and reconfigures upon failure . Available resource knowledge comes from system graph part which describes the logging devices and their access mode -LRB- i.e. what part of graph must be interposed between an application object and the device -RRB- . Failure detection is provided by the logging service . We will not develop further this point which is beyong the scope of this paper . A block that can have different successors by dynamic reconfiguration must be able to write records on variable successors or to search for records among multiple possible successors . As this is typically a replication problem , we limit dynamic binding to the replication block class . If one does not need replication but wishes to use dynamic reconfiguration , a replication block with a replication degree of 1 can be used . For example -LRB- see Figure 4 -RRB- , a client has specified , using functional designation , a log replicated on two sites and on two disks on each site . Site C has three available disks , and three sites have at least two disks . The system has chosen two disks of site B and two of site C . When a disk fails on 3Currently , device names are unix ones -LRB- e.g. / dev/rsd0c -RRB- . Site names are standard machines ones . Objects are designated by a class name and a symbolic name arbitrary chosen by graph builders . IV Further examples D D D D D D D RR R DM DM DM DM DM DM DM D D R D Site A Site B Site C Site D ca d b Figure 4 : Automatic reconfiguration site C -LRB- dotted arrow \ a '' -RRB- an other one can be chosen by the system -LRB- dashed arrow \ c '' -RRB- . Similarly , a failure of site C -LRB- dotted arrow \ b '' -RRB- leads the logging service to elect site D -LRB- dashed arrow \ d '' -RRB- . If the site C had only two available disks , a disk failure would lead to the election of another site . Depending on the replication object class chosen , when a failure occurs , different reaction are possible . For instance , reachable log records can be copied in order to maintain two full copies of the logical log . IV Further examples In order to illustrate the properties of the KitLog model and its varied uses , we present two sample logging configurations . The first one illustrates some of the unusual possibilities allowed by the model . The second one simulates an existing logging tool . IV .1 Reliable Distributed Pipe As pipe semantics are very close to log semantics , the following example -LRB- see Figure 5 -RRB- shows how one can build a log graph to implement a reliable distributed pipe . A shared memory is obtained by multiplexing two logging views V on a buffering object B via a sharing block S. Distribution is provided by the intermediate distribution block D on site B . The D block on site A permits entering the site A server address space . If one client uses the put -LRB- -RRB- operation while an V V D DSB DM D Distributed Pipe Site A Site B Figure 5 : Reliable distributed pipe other one uses the get -LRB- -RRB- operations , a distributed pipe is obtained . The reliability is due to the addition of a medium block and can be enhanced by replicating the log on different sites and disks . IV .2 The Camelot Example This second example shows how to approximate the Camelot logging facilities -LSB- Daniels 88 -RSB- using the KitLog services . Figure 6 shows the corresponding graph . D D D D D D D D D SB DM D SB DM D SB DM D RV RV RV 222 Site A Site B Site C Figure 6 : A Camelot-like log Within Camelot , each record is replicated on N sites among the M sites that provide a logging service . In this example , N is 2 and M is 3 . Three V Log management policy client transaction managers , are logging on three different sites . Clients , via a view object , pass records to a replication object R dynamically bound to 2 distribution objects . In Figure 6 , dynamic binding is represented by dotted arrows ; the replication degree -LRB- 2 -RRB- is indicated by a number on the edges . Records are sent to the appropriate site successor with a distribution object and multiplexed in a buffer object with a sharing object , before being written on a disk with a medium object . If a site failure occurs , in Camelot , a new site is chosen to maintain the replica number . With KitLog , the system re-configurates the graph by binding a new successor to the replication object . Obviously the storage organization must be customized to Camelot needs and the five main classes must be written to implement particular Camelot logging algorithms . For instance , the Camelot recovery protocol should be implemented by the replication class . V Log management policy Within the KitLog model , multiple log management policies can be designed . A log management policy is characterized by a particular storage organization and the semantics of the block operations . Depending on this storage organization , a set of meta-data types are defined to manage the physical logs . This is reflected by a particular block interface definition . For instance , in the current prototype , we have defined Rids and Lids as specific structures . They are gathered -LRB- and stored -RRB- in a single other structure : the Trailer , appearing in most of the operation interfaces . Consequently for a given storage organization , a particular block interface is defined , and is characterized by a block abstract type . KitLog block abstract types are similar to the abstract interfaces of Lipto -LSB- Druschel et al. 91 -RSB- and their definition can be adapted from that of Emerald abstract types -LSB- Black et al. 87 -RSB- : A block abstract type defines the interface of a block object -LCB- the set of operations supported , their signatures and -LRB- in principle -RRB- their semantics . An operation signature includes the operation name and the types of the arguments and results . Consequently , no implementation is tied to a block abstract type . A block class is one of the possible implementation of the block abstract type . A single management policy does not meet all application requirements . Consequently , multiple block abstract types and sets of associated classes must be designed . This section describes the KitLog prototype log management policy : storage organization , block abstract type interface and semantics , and some algorithms : finding the log end , finding records , and compaction . V. 1 Storage organization Whatever the storage medium , e.g. memory , message , disk , the storage organization is the same . The storage medium is decomposed into fixed-size chunks or sectors . The sector length is a multiple of the physical disk sector length ,4 the unit for writing or reading . The sector is an exchange unit between objects in the graph , avoiding unnecessary copies when transferring data to each other . For data exchange , a block can pass to its successor or predecessor a pointer referencing the beginning of a sector in a buffer . This buffer belongs to the block or to one of its successors or predecessors . When moving through the graph , data must be copied in the following cases : when arriving in a buffering block -LRB- if these blocks do not manage a set of pointers on record contents -RRB- , when changing site or address space , and when being written on -LRB- or read from -RRB- a physical device . Records have two parts : the opaque data block -LRB- R -RRB- and a descriptor , called a Trailer -LRB- T -RRB- . A trailer is composed of a log identifier -LRB- Lid -RRB- , a record identifier -LRB- Rid -RRB- and the size of the opaque data block -LRB- S -RRB- . When writing a record , the opaque data block is appended . Then , the trailer is written at the end of the last sector enclosing a part of the record body . If there is not enough space within the sector , the trailer is written in the next one . R10 512 OffsetNb_rec 500496T1T2 468440 R2 Begin R3 M Figure 7 : Sector organization T : record trailer , R : record opaque data block , Nb rec : number of record trailers in the sector , Offset : number of bytes from the begining of the sector to the end of the last record ending in the sector . Dashed records are records split among several sectors . Every sector finishes with a marker , M -LRB- see Fig - 4The sector length is 512 bytes in the current implementation . We assume that an appropriate length can be found for all kinds of devices . V Log management policy ure 7 -RRB- . Markers for contiguous sectors are strictly increasing . They allow the logging service to find the physical log end on a medium at boot time , and to restore consistency after a failure during a medium compacting -LRB- see xV .3 -RRB- . Each sector also includes the number of trailers in the sector -LRB- Nb rec -RRB- and the offset corresponding to the first byte after the last end of opaque data block in the sector -LRB- Offset -RRB- . These data are sufficient to read the log forward or backward , given a random sector of a physical log . For instance , Figure 8 shows an example of record storage . Given the Rid and Lid values of record Rd , its contents is found by reading sectors 2 and 1 . In sector 2 , the number of trailers indicates two valid trailers . The size of each opaque data block ending in the sector is found by examination of the trailers . The Rd data block end is at the offset Offset -LRB- represented by the arrow -RRB- minus the size of Re data block minus one byte . Rd 's beginning is obtained by subtracting its size -LRB- modulo the sector length -RRB- . Finding the sectors 1 and 2 is another problem discussed in xV .4 . Ra Rb Rc Re Rf Rg Rf Rf Sector 0 Sector 1 Sector 2 Sector 3 Sector 4 Sector 5 M M M M M M Tg 1 Tf 1 2TdTe Tc 1 TaTb 2Fixed overhead Rc Rd Rd Figure 8 : Storage example After any partial medium failure , this organization enables the recovery of records on undamaged parts of the medium because there is no fixedplaced meta-data . The space overhead is low . In the current implementation , the fixed storage overhead per sector is 20 bytes -LRB- the sizes of marker M , Offset and Nb rec -RRB- , while the overhead per record -LRB- the size of a trailer -RRB- is 28 bytes . Fixed overhead can be reduced by increasing sector length , but the greater the sector length is , the greater is the probability of losing space in incomplete sectors . V. 2 Block interface Figure 1 describes the interface seen by a client application -LRB- e.g. the logging view interface -RRB- , while Figure 9 gives the most interesting parts of the building block abstract type interface . Logging view interfaces operate on logical logs while block ones manage physical logs . The symbol & is a reference passing operator . In the \ get operations '' -LRB- get -LRB- -RRB- , get last -LRB- -RRB- , etc. -RRB- , the Lid field of the Trailer structure is set by the caller , whereas the Rid field is only set to call the get -LRB- -RRB- operation itself and is a return value for other kinds of gets . Contents and Buffer are passed by reference , because their size is only known to the caller . These interface methods can only be called by a block object belonging to the same block abstract type , or by a logging view object . Attach -LRB- -RRB- and detach -LRB- -RRB- bind and un-bind a block object successor to the current object , respectively . Put -LRB- -RRB- is used to append a single record into a write buffer of a buffering block . If the current block is not a buffering one , the put -LRB- -RRB- operation is transmitted to its successor -LRB- s -RRB- . attach -LRB- & Block -RRB- detach -LRB- & Block -RRB- put -LRB- Trailer , & Contents -RRB- get -LRB- & Trailer , & Contents , Max size -RRB- get last -LRB- & Trailer -RRB- get prev -LRB- & Trailer -RRB- get first -LRB- & Trailer -RRB- get next -LRB- & Trailer -RRB- flush -LRB- Level -RRB- prefetch -LRB- Lid , Rid -RRB- invalidate records -LRB- : : : -RRB- infos -LRB- & Infos -RRB- multiple put -LRB- Nb sect , & Buffer -RRB- multiple get -LRB- Lid , Rid , Nb sect , & Buffer , Max size -RRB- Figure 9 : Block interface Get -LRB- -RRB- returns the contents of a record whereas get last -LRB- -RRB- , get prev -LRB- -RRB- , get first -LRB- -RRB- and get next -LRB- -RRB- methods only search record identifiers on medium , buffer , tables , etc. -LRB- depending on the block nature and implementation -RRB- . This V Log management policy separation between get operations reflects the difference between looking records up and getting their contents . Flush -LRB- -RRB- copies the contents of the current block write buffer -LRB- if there is one -RRB- into the first successor -LRB- s -RRB- that is -LRB- are -RRB- able to store data and call the flush operation of its successor -LRB- s -RRB- . If the level argument is set to -1 , a recursive flush on all the object successors is executed . Set to another value , the flush is limited to the equivalent level in the graph . For instance , a flush of level two will successively call a flush on the current object , on its successors and on all the successors of its successors . This allows clients to control the flush level when they use multiple buffers for structuring data -LRB- see the buffering block description in xIII .2 -RRB- . Prefetch -LRB- -RRB- is the converse operation . It asks its successors to load into their read buffer a \ log data segment '' enclosing a given record . This operation prepares future get operations . Invalidate records -LRB- -RRB- gives the logging service a list of obsolete records that can be compacted out of the log . Multiple record description forms are possible -LRB- explained in xV .5 -RRB- . Infos -LRB- -RRB- returns some information about the object : its class , the list of its inherited classes , the object state , its successors list , etc. . Finally , multiple put -LRB- -RRB- and multiple get -LRB- -RRB- operations pass multiple sectors at once . The former passes Nb sect sectors to its successors , whereas the latter asks successors for Nb sect contiguous sectors including a particular record . This chunk of data must be put in the buffer Buffer , whose length is Max size . These operations manage the copies of data chunks between building block objects . V. 3 Finding the log end Finding the end of a physical log is a current problem that log designers encounter . The problem stems from the fact that due to physical log reliability , information on the log must be sufficient to recognize log data . The log service must be able to identify beginnings and ends of records , to find the log end , to determine if a fault occurs during a compaction , etc. . The flush operation when returns , guarentees that every record written on the medium can be recovered . Consequently , once a write is done , the logging service must be able to find the new log end without any in-memory information . But , log end location can not be written at a fixed position of the storage medium . Such an approach would involve two writes on different medium places for each write of data on the physical log . The traditional solution to this problem is to fill the log free space with zeros and to find with a binary search the last non-zeroed sector . This solution 's drawback is the time cost , after a compaction or at medium initialization , needed to write zeros . Moreover , large records filled with zero complicate the searching algorithm . Our solution is to use the sector marker to avoid filling free sectors with zeros . At regular intervals -LRB- say , every 5 minutes -RRB- , the marker of the last sector of the physical log and its location are stored at the medium beginning . At boot time , the N first sectors of the log are read . If the device has been initialized , these N sectors have valid markers -LRB- marker validity is explained later -RRB- and they contain the location -LRB- sl -RRB- and marker -LRB- ml -RRB- of the last known log end . Then , a binary search looks up the last N contiguous sectors having increasing valid markers between the last known log end location and the medium end . Markers are composed of : their generation date , a site identifier , and a compaction counter . The site identifier is that of the device site . During a compaction , a set of records from different sectors can be compacted in a single sector . The new sector marker is the greatest of the markers of the compacted sectors with an incremented compaction counter . A valid marker contains the local site identifier and the current compaction counter . The current compaction counter is incremented at the end of the compaction after having written the new log end location at the medium beginning -RRB- . The probability of error in finding the log end depends on the value of N and on data representation -LRB- integer length , etc. -RRB- . In the current implementation , N is 4 and the probability of error is very low -LRB- range 10 ? 50 -RRB- . At boot time , the medium can be in three different states -LRB- see Figure 10 -RRB- . If the log has never been compacted , it is divided into two areas . The first one has valid increasing markers . The second one contains unspecified data . Finding the log end just requires being able to detect invalid markers If the medium has been compacted several times , values of markers are increasing and decreasing following a sawtooth-shaped curve . As in the previous case , finding the log end is easy with the knowledge of the current compaction counter value . The last case happens when a fault has occurred during a compaction . Before a compaction , additional information is written at the medium beginning : \ entering a compaction '' . With this information , we know that a compaction has been V Log management policy lm s l s l lm lm s l Sector M Log has never been compacted M 6 4 5 s s6 5 Sector M 4 5 Sector 6-5m Log has been compacted several times A fault has occured during a compaction Invalid Invalid Invalid Figure 10 : Marker values on the medium Numbers on the Figure are the compaction counter values . ml and sl : marker and sector number of the last checkpointed log end . s5 : end of the compaction zone , beginning of sectors that have still to be compacted out . s6 : end of the already compacted sectors . m6 ? 5 : the corresponding pair of markers -LRB- m6 , m5 -RRB- , they differ by their compaction counter . interrupted . Consequently , the medium beginning may contain markers which are not yet valid . Once the log end found , we search the beginning and the end of the compaction zone -LRB- between s6 and s5 -RRB- . s6 can easily be found with a binary search between the medium beginning and sl . Given the marker m6 , m5 is found by decrementating its compaction counter . Finally a binary search between s6 and sl finds s5 . Once these zone limits are known , compaction continues . If the first medium sectors , containing medium state and ml and sl values , are lost -LRB- we assume that this kind of event can be detected -RRB- , they can be reconstituted by reading the two first saw-teeth . V. 4 Finding records Within the above design description , a particular record look-up can only be done by reading a physical log from the beginning or the end in its entirety . In order to decrease the record search time , meta-data are maintained . For each logical log , the first record Rid and its location on the storage media are registered and , regularly , the last record Rid and its location are added to these data . As Rids increase with time , given a particular Rid , enables the logging service to find locations that define the limits of the records location . These data are regularly stored on a particular log : the meta-data log . The similar meta-data on this log are kept in a traditional file system . Because of the unreliability of their storage , they are used only as hints to find record sectors . In case of loss , by reading the log storage media directly , we are able to reconstitute this information . We have to study the interval of time for saving these data in order to balance the storage overload they produce and the time for searching records . More elaborate methods exist to accelerate records look-up -LSB- Finlayson and Cheriton 87 -RSB- but this one has the advantage of simplicity . V. 5 Compaction A list of obsolete records is necessary for physical log compacting . This list , produced by applications , is stored in the meta-data log , until compaction time occurs . Three methods have been selected to indicate these records to the logging service : p Lid , Rid : Records are declared one by one . This is the most flexible and fine grain method . p Lid : Delete a complete logical log . p Delete all records with Rids lesser or equal than some value . This is useful for applications that can discard records older than some particular point -LRB- e.g. checkpoint -RRB- . Other designation methods are planed . For instance , it could be usefull for nested transactions to group records of a set of subtransactions in order to invalidate all these records when the toplevel transaction is aborted . Before compaction , a list of obsolete records must be prepared . Multiple choices can be done : having a partial or complete list , for instance . We suppose in the remainder that the list is complete and sorted by record location in memory . A log compaction problem occurs when the compaction zone is not large enough to allow moving data by first coping it into a new place and then discarding the old copy . This method is necessary for avoiding data loss when a fault occurs during compaction . Compaction is done with the following algorithm : References p Write the new medium state : \ entering compaction '' at medium beginning . p Search the first sector that encloses a record to be removed . p Read it and some of the following sectors to fill a buffer . p Compact the buffer : The marker of a new sector is the greatest marker among those of the compacted record sectors . The marker compaction counter is incremented . p If there is enough space to write the buffer without corrupting valid data , write the new full sectors of the buffer in the compaction zone . p Else , ffl Write them at the end of the log as a record of the compaction log . ffl Write the buffer full new sectors in the compaction zone . ffl Invalidate the compaction record . p At compaction end , write the new physical log end information at the medium beginning and then , remove the compaction state information . This algorithm does not need to stop to write new records on the physical medium , but , it needs some space at the end of the log to write compaction records . If there are enough records to remove , writing compaction records will only be needed at the compaction beginning . VI Conclusion KitLog has three level of genericity . The first one is that of block abstract type . By choosing a storage organization and the semantics of block operations , a particular log management policy is selected . The second level , is that of the classes . Within a block abstract type and for each logging function , specific protocols can be used . The last level is that of the log configuration . The properties of a logical log are defined by the graph object nature and the way they are composed . KitLog is a good tool for policy experimentation . It is adaptable to application needs and system resources -LRB- characteristics and amount -RRB- . The cost an application pays for its log is related to the functions it uses . However , describing an appropriate graph is a difficult task . Adding new classes requires recompilation the different service parts . A prototype is currently under implementation . It is written in C and C++ over Unix -LRB- Sun OS -RRB- . The prototype is composed of a server , a client library , and a set of control programs . It implements only one block abstract type and one class of each kind of block -LRB- for medium block , only the disk class is written -RRB- . The replication block is simple ; it does not provide any consistency protocol . Compaction is not yet implemented . Future work will begin by exercising KitLog with real applications in order to do performance measurements and to validate the model and the log management policy . Then , we plan to study new classes -LRB- specifically , the implementation of different replication protocols -RRB- and new block abstract types . References -LSB- Baer et al. 81 -RSB- J. L. Baer , G. Gardarin , C. Girault , G. Roucairol : \ The Two-Step Commitment Protocol : Modeling Specification and Proof Methodology '' . Proc . IEEE , 5th International Conference on Software Engineering , San Diego , USA . 1981 . -LSB- Bernstein and Goodman 80 -RSB- Philip A. Bernstein , Nathan Goodman : \ Timestamp-Based Algorithms for Concurrency Control in Distributed Database Systems '' . Proceedings of the Sixth Internationnal Conference on Very Large Data Bases . Pages 285 -LCB- 300 . October 1980 . -LSB- Birman et al. 89 -RSB- Kenneth P. Birman , Robert Cooper , Thomas A. Joseph , Kenneth P. Kane , Frank Schmuck : \ ISIS - A Distributed Programming Environment , User 's Guide and Reference Manual '' . pages 191 -LCB- 215 . 19 June 1989 . -LSB- Black et al. 87 -RSB- A. Black , N. C. Hutchinson , E. Jul , H. M. Levy , L. Carter : \ Distribution and abstract types in Emerald '' . IEEE Transactions on Software Engineering , Vol . 13 , Nffi1 , pages 65 -LCB- 76 . January 1987 . -LSB- Daniels et al. 87 -RSB- Dean S. Daniels , Alfred Z. Spector , Dean S. Thompson : \ Distributed Logging for Transaction Processing '' . Proceedings of ACM Special Interest Group on Management of Data . San Francisco . May 27-29 , 1987 . SIGMOD Record , Vol . 16 , Nffi3 , pages 82 -LCB- 96 . December 1987 . -LSB- Daniels 88 -RSB- Dean Spencer Daniels : \ Distributed Logging for Transaction Process - References ing '' . PhD Thesis , CMU-CS-89-114 . December 1988 . -LSB- Druschel et al. 91 -RSB- Peter Druschel , Larry L. Peterson , Norman C. Hutchinson : \ Lipto : A Dynamically Configurable Object-Oriented Kernel '' . Newsletter of the IEEE Computer Society Technical Committee on Operating Systems and Application Environments ; Vol . 5 , Nffi1 , pages 11 -LCB- 16 . 1991 . -LSB- Finlayson and Cheriton 87 -RSB- Ross S. Finlayson , David R. Cheriton : \ Log Files : An Extended File Service Write-Once Storage '' . ACM 11th Symposium on Operating System Principles , Austin -LRB- TX -RRB- ; Pages 139 -LCB- 148 . November 1987 . -LSB- Gray et al. 81 -RSB- Jim Gray , Paul McJones , Mike Blasgen , Bruce Lindsay , Raymond Lorie , Tom Price , Franco Putzoli , Irving Traiger : \ The Recovery Manager of the System R Database Manager '' . Communications of the ACM , Computing Surveys , Vol 13 , Nffi2 , pages 223 -LCB- 243 . June 1981 . -LSB- Haskin et al. 87 -RSB- Roger Haskin , Yoni Malachi , Wayne Sawdon , Gregory Chan : \ Recovery Management in QuickSilver '' . Proceedings of the Eleventh ACM symposium on Operating Systems Principles ; Austin , Texas ; pages 75 -LCB- 86 . 8-11 November 1987 . -LSB- Heidemann and Popek 91 -RSB- John S. Heidemann , Gerald J. Popek : \ A Layyered Approach to File System Development '' . Technical Report , University of California , Los Angeles , CSD-910007 . March 1991 . -LSB- Hutchinson and Peterson 88 -RSB- Norman C. Hutchinson , Larry L. Peterson : \ Design of the x-Kernel '' . Proceedings of the SIGCOMM '88 Symposium . Stanford , CA -LRB- USA -RRB- , pages 65 -LCB- 71 . August 1988 . -LSB- Leblanc and Mellor-Crummey 87 -RSB- Thomas J. Leblanc and John M. Mellor-Crummey : \ Debugging Parallel Programs with Instant Replay '' . IEEE Transactions on Computers , Vol . C-36 , Nffi4 , pages 471 -LCB- 482 . April 1987 . -LSB- Ritchie 84 -RSB- Dennis M. Ritchie : \ A stream input-output system '' . AT&T Bell Laboratories Technical Journal , Vol . 63 , Nffi8 , pages 1897 -LCB- 1990 . October 1984 . -LSB- Rosenblum and Ousterhout 91 -RSB- Mendel Rosenblum and John K. Ousterhout : \ Design and Implementation of a Log-structured File System '' . Thirteenth ACM Symposium on Operating Systems Principles ; Pacific Grove , CA , USA . ACM Operating Systems Review , Vol . 25 , Nffi 5 , pages 1 -LCB- 15 . October 13-16 , 1991 .

B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O B O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O B O O O B I O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O

generic service
kitlog
log management
object composition