Architecture - Llog over OSD

WORK IS PROGRESS

Definitions
The following terms are used in this design. Please read to avoid confusion.


 * device stack - list of devices (or device layers) connected to each other in specificorder to allow passing control from one layer to another layer. Layers are connected in the order specific for the operations executed on this particular stack. Note that in thisHLD we use this term for usual device stacks, used for regular FS operations as well as for device stacks needed for carrying control flow for llog operations. That is, evenstacks built for llog called here device stack;
 * device layer - part of device stack, providing specific functionality which is logicallyseparated from the functionality provided by other layers;
 * initiator - server
 * replicator - client

Requirements

 * 1) Re-implement llog API to use OSD device as backend device instead of fsfilt;
 * 2) make mountconf works with new llog;
 * 3) make llog working on DMU (optional) design new llog API to make possible llog usage from different parts of Lustre. This API should be suitable for the following use-cases:
 * 4) unlink/setattr llog
 * 5) changelogs
 * 6) size-on-mds llogs

Low-level llog API changes
Llog API is moved from using lvfs/fsfilt to using dt_device as back store. This requiresre-implementation of basic llog methods to open llog file and read/write data from it using methods of osd_device(dt_device). The network llog API should be also changed. The virtual dt_device may be build overnetwork connection with basic methods to read/write data and open/close llog object via network.

Transactions
The most important change is new transaction API and prohibited nested transaction.Current llog API uses transactions transparently due to nested transactions in ldiskfs. The llog API should be changed in following manner:


 * 1) Change llog API to accept transaction handler for write methods. 2. Declare that transaction is going to use llog at upper layers and pass trans-action handler to Llog API
 * 2) declare exact object(s) involved in transaction and place in llog to write. This is most brain-damaging issue because current llog API hides fully all transaction mechanisms and everething is done on low-level.
 * 3) Declare that llog catalog operation can create new plain llog. Possibly we may know about that before calling llog catalog method?

Create/open llogs by name
Llog uses ability to create/open files on bottom fs but OSD has no name operations. Such operations must be implemented in llog like they did in MDD. Another possible way is to use MDD instead of OSD

Mountconf
Mountconf should do the following:


 * 1) Start OSD device on super_block taken from 'mount'. OSD stars in some minimal configuration just to allow access to llog objects;
 * 2) start MGC/MGS which uses that OSD as backend;
 * 3) MGC starts working as usual and build whole stack, OSD is re-configured to full state in accordance with config llog