qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] blobstore disk format (was Re: Design of the blobstore)


From: Michael S. Tsirkin
Subject: [Qemu-devel] blobstore disk format (was Re: Design of the blobstore)
Date: Thu, 15 Sep 2011 15:28:43 +0300
User-agent: Mutt/1.5.21 (2010-09-15)

So the below is a proposal for a directory scheme
for storing (optionally multiple) nvram images,
along with any metadata.
Data is encoded using BER:
http://en.wikipedia.org/wiki/Basic_Encoding_Rules
Specifically, we mostly use the subsets.

We use a directory as a SET in a CER format.
This allows generating directory online without scanning
the entries beforehand.

The rest of the encoding uses a DER format.
This makes for fast parsing as entries are easy to skip.

Each entry is encoded in DER format.
Each entry is a SEQUENCE with two objects:
1. nvram
2. optional name - a UTF8String

Binary data is stored as OCTET-STRING values on disk.
Any RW metadata is stored as OCTET-STRING value as well.
Any RO metadata is stored in appropriate universal encoding,
by type.

On the context below, an attribute is either a IA5String or a SEQUENCE.
If IA5String, this is the attribute name, and it has no value.
If SEQUENCE, the first entry in the sequence is an
IA5String, it is the attribute name. The rest of the entries
represent the attribute value.

Mandatory/optional attributes: depends on type.
tpm will have realsize as RW mandatory attribute.

Each nvram is built as a SEQUENCE including 4 objects
1. type - an IA5String. downstreams can use other types such as
                     UUIDs instead to ensure no conflicts with upstream
2. SET of mandatory attributes
3. SET of optional attributes
4. data - a RW OCTET-STRING

It is envisioned that attributes won't be too large,
so they can easily be kept in memory.


-- 
MST



reply via email to

[Prev in Thread] Current Thread [Next in Thread]