fixed error in readme.

4 files changed, 11 insertions, 11 deletions

diff --git a/src/cowtest/readme.md b/src/cowtest/readme.md
index b6286d1..3225bc9 100644
--- a/src/cowtest/readme.md
+++ b/src/cowtest/readme.md
@@ -17,14 +17,14 @@ This test suit is for verifying that the fuse cow implementation works correctly
 ### Parameters
 - `-c <path>` generates a test image at given path. This image should be loaded for the tests to work.
 - `-t <path>` runs the tests on the image at the given past.
-- `-v <path>` verifies that previous tests on the image were successfully (also reads the image completely).
+- `-v <path>` verifies that previous tests on the image were successful (also reads the image completely).
 
 ### Example Usage
 
-1. generate the test image with `-c <path>` and copy it to the image location of the dnbd3 server. Also make sure that the cow servers `OriginalImageDirectory` points to the same Directory or copied in that Directory too. This step is only needed once for set up.
+1. Generate the test image with `-c <path>` and copy it to the image location of the dnbd3 server. Also make sure that the cow servers `OriginalImageDirectory` points to the same Directory or copied in that Directory too. This step is only needed once for  setting up.
 2. Start the dnbd3 and cow server.
 3. Mount the image in cow mode.
-4. Run the test with `-t <path>`, where path points to the mounted image.
+4. Run the test with `-t <path>`, where the path points to the mounted image.
 5. Optional verify again with `-v <path>`.
 6. Optional unmount the image and then load it again (with `-L <path>` in the fuse client). Then verify the loaded image with `-v <path>`.
 7. Unmount and merge the image.
@@ -44,7 +44,7 @@ Then it sets a single Bit in the second block to 1, to verify padding works corr
 
 
 ### WriteOverTwoBlocks
-tests that continuous writes over two DNBD3_BLOCK's are possible.
+Tests that continuous writes over two DNBD3_BLOCK's are possible.
 
 | offset | size | 
 | -------| -----| 
@@ -86,7 +86,7 @@ Tests file size changes. First in increases the file size with a truncate by 2 *
 the original size + 2 * l2Capacity and verifies that the again all bits in the new allocated space are 0 (so that the before written data is set to 0 again).
 
 ### LongNonAlignedPattern
-This test writes writes an long pattern over 3 l2 borders. The pattern are repeating chars from 0 to 254, so it's not a multiple of 4096, which therefore results that all Blocks are filled with different data. Also this test is not block aligned.
+This test writes writes an long pattern over 3 l2 borders. The pattern repeats chars from 0 to 254, so it's not a multiple of 4096, which therefore results that all Blocks are filled with different data. Also, this test is not block aligned.
 | offset | size | 
 | -------| -----| 
 |l2Capacity * 3 - 1|l2Capacity + 2|
diff --git a/src/fuse/cowDoc/img/Bild1.jpg b/src/fuse/cowDoc/img/Bild1.jpg
deleted file mode 100644
index 3171c9a..0000000
--- a/src/fuse/cowDoc/img/Bild1.jpg
+++ /dev/null
diff --git a/src/fuse/cowDoc/img/datastructure.jpg b/src/fuse/cowDoc/img/datastructure.jpg
new file mode 100644
index 0000000..d471d2a
--- /dev/null
+++ b/src/fuse/cowDoc/img/datastructure.jpg
diff --git a/src/fuse/cowDoc/readme.md b/src/fuse/cowDoc/readme.md
index f707bff..607f9e1 100644
--- a/src/fuse/cowDoc/readme.md
+++ b/src/fuse/cowDoc/readme.md
@@ -10,20 +10,20 @@
 
 # Introduction
 
-This extension to the fuse dnbd3 client allows it to mount images writable. The changes to a writable mounted image will be stored in a separate file (also called Copy on Write (Cow)) on the client computer. These changes are uploaded in the background to the cow server. Once the user unmounts the images, all remaining changes will be uploaded. Then the image will be merged on the server (if set so in the startup parameters).
-
+This extension to the fuse dnbd3 client allows images to be mounted writable. The changes are saved in a separate file (also called Copy on Write, cow for short) on the client computer. These changes are uploaded to the cow server in the background. Once the user unmounts the image, any remaining changes are uploaded. As soon as all changes have been uploaded, the changes can be merged into a copy of the original image on the cow server (this can be set in the start parameters).
 
+A typical use case is updating or adding software to an existing image.
 
 # Usage
 
 ### New Parameters
-- `-c <path>` Enables the cow functionality, the argument sets the path for the temporary `meta` and `data` file in which the writes are stored
+- `-c <path>` Enables the cow functionality, the argument sets the path for the temporary `meta` and `data` file in which the writes are stored.
 - `-C <address>` sets the address of the cow server. The cow server is responsible for merging the original image with the changes from the client.
 - `-L <path>` Similar to `-c <path>` but instead of creating a new session, it loads an existing from the given path.
 - `-m` if set, the client will request a merge after the image is unmounted and all change are uploaded.
 
-- `--cowStatStdout` creates a status file at the same location as the data and meta file. The file contains information about the current session, for more information see [here](#status).
-- `--cowStatFile` similar to `--cowStatStdout` but the information will be printed in the stdout.
+- `cowStatFile` creates a status file at the same location as the data and meta file. The file contains information about the current session, for more information see [here](#status).
+- `--cowStatStdout` similar to `--cowStatFile` but the information will be printed in the stdout.
 
 Example parameters for creating a new cow session:
 ```
@@ -44,7 +44,7 @@ The data structure is split in two main parts. The actual data from the write on
 
 ### Blockmetadata
 
-![Datastructure](img/Bild1.jpg)
+![Datastructure](img/datastructure.jpg)
 
 The data structure for storing metadata cow blocks contains a Layer 1(L1) and a Layer 2 (L2). L1 contains pointers to the L2's.
 The whole L1 array is initialized at the beginning and cannot be resized, so the size of the L1 array limits the total size of the image.