Merge remote-tracking branch 'github-origin/stable-v2.0' into stable-…

…v2.0

.circleci/config.yml

@@ -61,10 +61,10 @@ jobs:
         <<: *shared
         docker:
             - image: library/ubuntu:jammy
-    ubuntu2210:
+    ubuntu2310:
         <<: *shared
         docker:
-            - image: library/ubuntu:kinetic
+            - image: library/ubuntu:mantic
 
 workflows:
   build-deb:
@@ -74,4 +74,4 @@ workflows:
       - debian12
       - ubuntu2004
       - ubuntu2204
-      - ubuntu2210
+      - ubuntu2310

.github/ISSUE_TEMPLATE/Bug_report.yml

@@ -67,7 +67,7 @@ body:
 - type: textarea
   id: additional-info
   attributes:
-      label: Additional informations
+      label: Additional information
       description: Add any additional information related to the issue here.
 
 

.github/workflows/Linux.yml

@@ -24,7 +24,7 @@ jobs:
       fail-fast: false
 
     steps:
-      - uses: actions/checkout@v3
+      - uses: actions/checkout@v4
 
       - name: Install packages required
         run: |

.github/workflows/build-other-archs.yml

@@ -22,18 +22,19 @@ on:
 jobs:
   build_job:
     # The host should always be linux
-    runs-on: ubuntu-20.04
+    runs-on: ubuntu-22.04
     name: ${{ matrix.arch }}
 
     strategy:
+      fail-fast: false
       matrix:
         include:
           - arch: aarch64
           - arch: ppc64le
           - arch: s390x
           - arch: armv7
     steps:
-      - uses: actions/checkout@v3
+      - uses: actions/checkout@v4
       - uses: uraimo/run-on-arch-action@v2
         name: Build
         id: build

CONTRIBUTING.md

@@ -17,7 +17,7 @@ kernel documentation, comments in source code etc...
 
 Testing is important to have a quality software, see related part in [README](README.md#tests)
 and the [README](https://github.com/veeam/blksnap/blob/master/doc/README-upstream-kernel.md) related to upstream kernel integration
-for some informations.
+for some information.
 
 ## Contributing to Source Code
 

doc/blksnap.md

@@ -45,7 +45,7 @@ A change tracker map is created for each block device. One byte of this map corr
 
 The byte of the change tracking map stores a number from 0 to 255. This is the sequence number of the snapshot for which there have been changes in the block since the snapshot was taken. Each time a snapshot is taken, the number of the current snapshot increases by one. This number is written to the cell of the change tracking map when writing to the block. Thus, knowing the number of one of the previous snapshots and the number of the last one, we can determine from the change tracking map which blocks have been changed. When the number of the current change has reached the maximum allowed value for the map of 255, when creating the next snapshot, the change tracking map is reset to zero, and the number of the current snapshot is assigned the value 1. The tracker of changes is reset and a new UUID — a unique identifier of the generation of snapshots — is generated. The snapshot generation identifier allows to identify that a change tracking reset has been performed.
 
-The change map has two copies. One is active, and it tracks the current changes on the block device. The second one is available for reading while the snapshot is being held, and it contains the history of changes that occured before the snapshot was taken. Copies are synchronized at the moment of taking a snapshot. After the snapshot is released, a second copy of the map is not needed, but it is not released, so as not to allocate memory for it again the next time the snapshot is created.
+The change map has two copies. One is active, and it tracks the current changes on the block device. The second one is available for reading while the snapshot is being held, and it contains the history of changes that occurred before the snapshot was taken. Copies are synchronized at the moment of taking a snapshot. After the snapshot is released, a second copy of the map is not needed, but it is not released, so as not to allocate memory for it again the next time the snapshot is created.
 
 ### Copy-on-write
 Data is copied in blocks, or rather in chunks. The term "chunk" is used not to confuse it with change tracker blocks and I/O blocks. In addition, the "chunk" in the blksnap module means about the same as the "chunk" in the dm-snap module.

include/blksnap/TrackerCtl.h

@@ -23,6 +23,7 @@
  * flexibility. Uses structures that are directly passed to the kernel module.
  */
 
+#include <stdint.h>
 #include <string>
 #include <uuid/uuid.h>
 #include <vector>

include/linux/blksnap.h

@@ -379,7 +379,7 @@ struct blksnap_snapshot_event {
  * While holding the snapshot, the kernel module can transmit information about
  * changes in its state in the form of events to the user level.
  * It is very important to receive these events as quickly as possible, so the
- * user's thread is in the state of interruptable sleep.
+ * user's thread is in the state of interruptible sleep.
  *
  * Return: 0 if succeeded, negative errno otherwise.
  */

lib/blksnap/TrackerCtl.cpp

@@ -19,6 +19,7 @@
 #include <blksnap/TrackerCtl.h>
 #include <errno.h>
 #include <fcntl.h>
+#include <stdint.h>
 #include <stdio.h>
 #include <stdlib.h>
 #include <sys/ioctl.h>

tools/blksnap/main.cpp

@@ -641,7 +641,7 @@ class SnapshotAddArgsProc : public IArgsProc
     SnapshotAddArgsProc()
         : IArgsProc()
     {
-        m_usage = std::string("Add device fo snapshot.");
+        m_usage = std::string("Add device for snapshot.");
         m_desc.add_options()
             ("device,d", po::value<std::string>(), "Device name.")
             ("id,i", po::value<std::string>(), "Snapshot uuid.");