ConfD User Community

One question about the disk IO write rate


#1

Hi,
In order to test the confD performance, I edit-config several hundreds XML files to write data to the running datastore.
For the several hundreds XML files, nearly 200 files is written to the running datastore successfully and nearly 400 files will report the error-message.
For the disk IO write rate result, I have a question about it. I think when the edit-config response is OK, the disk IO rate could be higher, and when the edit-config response error-message, the disk IO rate could be lower, but now overrall the diso IO rate is on average, so what is the mechanism for confD to write the datastore?


#2

Hi,

You hint that you observe some issue when doing hundreds of NETCONF edit-configs to the running datastore without giving away any details besides a picture that you don’t describe. Can you describe the issue and picture in detail?

Regarding your question, CDB by default store the entire configuration in RAM as well as on disk. The configuration is persisted (written to disk) in the “WRITE” step of a write transaction. If you have the candidate enabled, it may also be stored on disk.

Here’s an example of the phases of a successful transaction to the running datastore (e.g. a NETCONF edit-config with target running):

                  +-------+
                  | START |
                  +-------+
                      | 
                      |
                      v
                  +------+           
                  | READ |
                  +------+
                      |
                      | trans lock
                      v
                 +----------+       
                 | VALIDATE | 
                 +----------+
                      | 
                      |
                      v
                  +-------+           
                  | WRITE | 
                  +-------+
                      | 
                      |
                      v
                 +----------+   
                 | PREPARED | 
                 +----------+              
                      |                   
                      |                          
                      v                          
                  +-----------+                   
                  | COMMITTED |                 
                  +-----------+
                      | 
                      | trans unlock 
                      v
                    START

CDB store configuration data by default persistently in a file called “A.cdb”. This file is a journal file, i.e. each transaction (e.g. NETCONF edit-config with target running) is just appended to this file and when the transaction has been completed ConfD adds a “magic marker”.

If ConfD is killed/crash and subsequently restarted at some point during an ongoing transaction, ConfD will read the transaction that has been committed and if there is a transaction at the end of the file with a missing “magic marker”, the transaction will be considered incomplete and the transaction will be ignored.

A transaction is either committed or not. A transaction cannot be partially committed. Even though there is a power outage either the writing of the “magic marker” succeeds or fail, so just a part of a transaction cannot make it into the journal file.

Since just adding data to journal file would lead to that we eventually would run out of disk space, ConfD run an algorithm that handle compacting it automatically by default.

ConfD perform a compaction by writing the data it has stored in RAM to a file named, for example, A.cdb.tmp and then rename the file from *.cdb.tmp to *.cdb. Hence, the compaction cannot fail since, even though if there is a power outage, the renaming of the file either succeeds or fail.

After a successful compaction the journal file will contain one single transaction that can be applied in one go if ConfD is restarted.


#3

Hi @cohult,
Thank you so much for the detailed response. Now I know the basic knowledge of the edit-config.
But I still have two questios,
1. Question 1,
I use a simple example to show my question as I couldn’t send the hundres of XML files,
when write the XML file1, the A.cdb will contain data about XML file1, when write the XML file 2, the a-list isn’t changed, whether it will be rewritten? i.e., whether the disk IO write rate will be affected by the size of A.cdb or only be affected bu the XML file.

  1. root.yang
module root {
        namespace "http://test/root";
        prefix root;
        container ph {
                list a-list {
                        key "x";
                        leaf x {
                                type uint8;
                        }
                }
        }
}
  1. child1.yang
module child1 {
        namespace "http://test/child1";
        prefix child1;
        import root { prefix root;}
        augment "/root:ph" {
                container inner1 {
                  list b-list1 {
                    key p1;
                        leaf p1 {
                                type uint8;
                        }
                        leaf q {
                           type string
                           } 
                        }
                }
            }
        }
}
  1. XML file1
<ph xmlns="http://test/root">
        <a-list>
            <x>3</x>
        </a-list>
        <a-list>
            <x>1</x>
        </a-list>
        <inner1 xmlns="http://test/child1">
            <b-list1>
                    <p1>5</p1>
                     <q>5</q>
                </b-list1>
        </inner1>
</ph>
  1. XML file 2
<ph xmlns="http://test/root">
        <a-list>
            <x>3</x>
        </a-list>
        <a-list>
            <x>1</x>
        </a-list>
        <inner1 xmlns="http://test/child1">
            <b-list1>
                    <p1>5</p1>
                     <q>4</q>
                </b-list1>
        </inner1>
</ph>

2. Question 2:

  1. As the above picture about the disk IO I provided, the time 16:00:30-16:02:00 for picture1(Apps.pwrite), I ran 10 XML files, 3 XML files response OK and other XML files response error-message, my question is, seems the disk IO Apps pwrite rate is similar, whether the XML files responsing OK should have a higher pwrite rate?

Thanks


#4
  1. ConfD will write only the minimum diff to the running datastore. I.e. /ph/inner1/b-list1[p1=5]/q 4 from file 2 if the running datastore contained the configuration in file 1.
  2. What’s the error message?

#5

Hi @cohult,
Thanks very much for the response.
Maybe there is some confusion on my description, there isn’t error-message and it isn’t a issue, I need to think more about the confD usage.