devmapper: Do not check for pool transaction id during old metadata migration

Current code is associating a transaction id with each device and if pool
transaction id is greater that value, then current code assumes that device
is there in pool.

Transaction id of pool is a mechanism so that during device creation and
removal one can define a transaction and during startup figure out if
transaction was complete or not. I think we are using transaction id 
throughout the code little inappropriately.

For example, if a device is being deleted, it is possible that we deleted
the device from pool but before we could delete metafile docker crashed.
When docker comes back it will think that device is in the pool (due to
device transaction id being less than pool transaction id) but device
is not in the pool.

Similary, it could happen that some data in the pool is corrupted and
during pool repair some devices are lost (without docker knowing about
it). In that case tool pool transaction id will be higher than device
transaction id and there are no guaratees that device is actually in
the pool.

So move away from this model where we think that a device is in pool if pool
transaction id is greater than device transaction Id. Per device
transaction Id just says that after device creation this should be pool's
transaction Id and nothing more.

Transaction id is per pool property (as opposed to per device property) and
will be used internally to figure out if last transaction was complete or
not and recover from failure during docker startup.  

If for some reason metafile is present but device is not in pool, then 
device activation will fail later.

Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
devmapper: Do not check for transaction id during device metadata loading

Again, just because device transaction id is greater than pool transaction
id, it does not guarantee that device is in the pool. So do not check
of this during loading of device metadata.

Docker needs to deal with it. And device activation will fail when we try
to activate a device for whom metafile is present but there is no device
in the pool.

Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
devmapper: Remove unnecessary call to allocateTransactionId() during device removal

Remove call to allocateTransactionId() during device removal. This seems to
be unnecessary and it is not clear what this call is doing.

Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
devmapper: Remove transaction Id update from saveMetaData()

Right now saveMetaData() is kind of little overloaded function. It is
supposed to save file metadata to disk. But in addition if user has
bumped up NewTransactionId before calling saveMetaData(), then it will
also update the transaction ID in pool.

Keep saveMetaData() simple and let it just save the file. Any update
of pool transaction ID is done inline in the code which needs it.

Also create an helper function updatePoolTransactionId() to update pool
transaction Id.

Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
devmapper: Move pool id query and migration of old data in separate function

Right now initMetaData() first queries the pool for current transaciton Id
and then it migrates the old metafile.

Move pool transaction Id query and file migration in separate functions
for better code reuse and organization.

Given we have removed device transaction Id dependency from saveMetaData(),
we don't have to query pool transaction Id before migrating files.
 
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
devmapper: Do not add back device into hash map if meta file removal failed

When we are deleting a device, we also delete associated metadata file. If
that file removal fails, we are adding back the device in in-memory
table. I really can't see what's the point. When next lookup takes place
it will be automatically loaded if need be. Remove that code.

Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
devmapper: Use device id as specified by caller

Currently devicemapper CreateDevice and CreateSnapDevice keep on retrying
device creation till a suitable device id is found. 

With new transaction mechanism we need to store device id in transaction
before it has been created.

So change the logic in such a way that caller decides the devices Id to
use. If that device Id is not available, caller bumps up the device Id
and retries.

That way caller can update transaciton too when it tries a new Id. Transaction
related patches will come later in the series.
  
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
devmapper: Provide a function unregisterDevice()

Currently registerDevice() adds a device to in-memory table, saves metadata
and also updates the pool transaction ID.

Now move transaciton Id update out of registerDevice() and provide a new
function unregisterDevice() which does the reverse of registerDevice().
This will simplify some code down the line and make it more structured.

This is just code reorganization and should not change functionality.
 
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
devmapper: Create new helper function for device and snap creation

Create two new helper functions for device and snap device creation. These
functions will not only create the device and also register the device.

Again, makes the code structure better and keeps all transaction logic
contained to functions instead of spilling over into functions like
setupBaseImage or AddDevice().

Just the code reorganization. No functionality change.

Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
devmapper: Remove unnecessary condition check in updatePoolTransactionId()

Currently updatePoolTransactionId() checks if NewTransactionId and
TransactionId are not same only then update the transaction Id in pool. This
check is redundant. Currently we call updatePoolTransactionId() only from
two places and both of these first allocate a new transaction Id.

Also updatePoolTransactionId() should only be called after allocating
new transaction Id otherwise it does not make any sense.

Remove the redundant check and reduce confusion.

Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
devmapper: Allocate new transaction Id using current transaction Id

Currently new transaction Id is created using allocateTransactionId()
function. This function takes NewTransactionId and bumps up by one 
to create NewTransactionId.

I think ideally we should be bumping up devices.TransactionId by 1
to come up with NewTransactionId. Because idea is that devices.TransactionId
contains the current pool transaction Id and to come up with a new
transaction Id bump it up by one.

Current code is not wrong as we are keeping NewTransactionId and
TransactionId in sync. But it will be more direct if we look at
devices.TransactionId to come up with NewTransactionId. That way
we don't have to even initialize NewTransactionId during startup
as first time somebody wants to do a transaction, it will be
allocated fresh.

So simplify the code a bit. No functionality change.
 
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
devmapper: Rename NewTransactionId to OpenTransactionId

Very soon we will have the notion of an open transaction and keep its
details in a metafile.

When a new transaction is opened, we allocate a new transaction Id, 
do the device creation/deletion and then we will close the transaction.

I thought that OpenTransactionId better represents the semantics of
transaction Id associated with an open transaction instead of NewtransactionId.

This patch just does the renaming. No functionality change.

I have also introduced a structure "Transaction" which will keep all
the details associated with a transaction. Later patches will add more
fields in this structure.

Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
devmapper: Use a common delete function for all device deletion operation

Right now setupBaseImage() uses deleteDevice() to delete uninitialized
base image while rest of the code uses DeleteDevice(). Change it and
use a common function everywhere for the sake of uniformity.

I can't see what harm can be done by doing little extra locking done
by DeleteDevice().

Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
devmapper: Keep track of used device Ids in a bitmap

Currently devicemapper backend does not keep track of used device Ids in
the pool. It tries a device Id and if that device Id exists in pool, it
tries with a different Id and keeps on doing this in a loop till it succeeds.

This worked fine so far but now we are moving to transaction based
device creation and deletion. We will keep deviceId information in 
transaction which will be rolled back if docker crashed before transaction
was complete.

If we store a deviceId in transaction and later figure out it already
existed in pool and docker crashed, then we will rollback and remove
that existing device Id from pool (which we should not have).

That means, we should know free device Id in pool in advance before
we put that device Id in transaction.

Hence this patch creates a bitmap (one bit each for a deviceId), and
sets the bit if device Id is used otherwise resets it. This patch
is just preparing the ground right now. Actual usage will follow
in later patches.

Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
devmapper: Construct initial device Id map from device meta files

When docker starts, build a used/free Device Id map from the per
device meta files we already have. These meta files have the data
which device Ids are in use. Parse these files and mark device as
used in the map.

Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
devmapper: Provide a helper function getNextDeviceId()

Right now we are accessing devices.NextDeviceId directly and also 
incrementing it at various places.

Instead provide a helper function which is responsile for
incrementing NextDeviceId and return next deviceId. 

This is just code structuring. This will help later once we
convert this function to find a free device Id and it goes
through a bitmap of used/free device Ids.

Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
devmapper: Open code createDevice() and createSnapDevice()

Open code createDevice() and createSnapDevice() and move all the logic
in the caller.

This is a sheer code reorganization so that all device Id allocation
logic is in one function. That way in case of erros, one can easily
cleanup and mark device Id free again. (Later patches benefit from
it).

Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
devmapper: Find a free device Id to use for device creation

Finally, we seem to have all the bits to keep track of all used device
Ids and find a free device Id to use when creating a  new device. Start
using it.

Ideally we should completely move away from retry logic when pool returns
-EEXISTS. For now I have retained that logic and I simply output a warning.
When things are stable, we should be able to get rid of it.

Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
devmapper: Use transaction mechanism during device or snap device creation

Finally this patch uses the notion of transaction for device or snapshot
device creation. 

Following is sequence of event.

- Open a trasaction and save details in a file.
- Create a new device/snapshot device
- If a new device id is used, refresh transaction with new device id details.
- Create device metadata file
- Close transaction.

If docker crashes anywhere in between without closing transaction, then
upon next start, docker will figure out that there was a pending transaction
and it will roll back transaction. That is it will do following.

- Delete Device from pool
- Delete device metadata file
- Remove transaction file to mark no transaction is pending.

Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
devmapper: Use transactions during device deletion

Use transaction logic during device deletion and do rollback if transaction
is not complete. Following is the sequence of events.

- Open transaction and save to metafile
- Delete device from pool
- Delete device metadata file from disk
- Close Transaction

If docker crashes without closing transaction then rollback will take
place upon next docker start.
 
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>