period yeet

Author: Fallen-Breath

docs/chunking/fixed_size.md

@@ -6,22 +6,22 @@ title: 'Fixed-Size Chunking'
 
     Fixed-size chunking is currently a proof of concept and is in alpha status.
     It is not recommended for production use.
-    Use [CDC Chunking](chunking_cdc.md) instead unless you have a specific reason to use fixed-size chunking.
+    Use [CDC Chunking](chunking_cdc.md) instead unless you have a specific reason to use fixed-size chunking
 
 Fixed-size chunking splits files at predictable byte-offset boundaries, with every chunk being exactly the configured size
-(the last chunk may be smaller if the file size is not a multiple of the chunk size).
+(the last chunk may be smaller if the file size is not a multiple of the chunk size)
 
 ## What Fixed-Size Chunking Is
 
 Fixed-size chunking is conceptually simple: the file is divided into equal-sized pieces from start to end.
-Each piece is hashed and stored independently, just like CDC chunks.
+Each piece is hashed and stored independently, just like CDC chunks
 
 Unlike CDC, chunk boundaries do not shift when content is inserted or deleted in the middle of the file.
 Any edit before the end of a chunk changes that chunk's hash entirely, and any insertion or deletion causes all subsequent chunks to shift,
-potentially invalidating a large number of previously stored chunks.
+potentially invalidating a large number of previously stored chunks
 
 This means fixed-size chunking is generally inferior to CDC for files with arbitrary edits.
-Its benefit is only realized in scenarios where the file's write pattern is well-aligned to chunk boundaries.
+Its benefit is only realized in scenarios where the file's write pattern is well-aligned to chunk boundaries
 
 For example, with `fixed_4k` applied to a Minecraft region file:
 
@@ -36,7 +36,7 @@ For example, with `fixed_4k` applied to a Minecraft region file:
 
 Each 4 KiB chunk corresponds to one internal page of the region file.
 When only a few game chunks change between backups, only the corresponding pages are dirtied,
-and the rest of the chunks are identical to those already stored.
+and the rest of the chunks are identical to those already stored
 
 ## Available Algorithms
 
@@ -50,25 +50,25 @@ and the rest of the chunks are identical to those already stored.
 
 The 4KiB chunk size aligns with the internal page structure of Minecraft's Anvil region files (`.mca`).
 In theory, modifying a small number of chunks in the game only dirties a limited number of 4 KiB pages,
-making `fixed_4k` capable of the finest-grained deduplication for region files.
+making `fixed_4k` capable of the finest-grained deduplication for region files
 
 However, `fixed_4k` has serious practical drawbacks:
 
 - extremely high metadata overhead: a 1 GiB file requires roughly 262 144 chunk records
 - poor I/O performance: each chunk requires a separate read-write cycle during backup
 
-Unless the file is very large and only a tiny number of pages change per backup, `fixed_4k` is unlikely to be worth the cost.
+Unless the file is very large and only a tiny number of pages change per backup, `fixed_4k` is unlikely to be worth the cost
 
 ### fixed_32k
 
-A middle-ground option. Metadata overhead is 32× lower than `fixed_4k` but granularity is also much coarser.
+A middle-ground option. Metadata overhead is 32× lower than `fixed_4k` but granularity is also much coarser
 
 ### fixed_128k
 
 The 128 KiB chunk size is well-suited for files that grow by appending data at the end.
-When new data is appended, only the trailing chunks change; all preceding chunks retain the same hash and are reused.
+When new data is appended, only the trailing chunks change; all preceding chunks retain the same hash and are reused
 
-This makes `fixed_128k` a reasonable alternative to CDC for pure append-write files.
+This makes `fixed_128k` a reasonable alternative to CDC for pure append-write files
 
 ## Poor Candidates
 
@@ -81,5 +81,5 @@ Fixed-size chunking is a poor choice for:
 ## No Extra Dependencies
 
 Fixed-size chunking has no additional Python dependency requirements.
-It is available as long as Prime Backup is installed.
+It is available as long as Prime Backup is installed
 

docs/chunking/index.md

@@ -8,10 +8,10 @@ Split large files into smaller chunks for better deduplication across backups
 
 File chunking is a storage strategy where a large file is split into smaller pieces called chunks before being stored.
 Each chunk is hashed and deduplicated independently, so when only part of a large file changes between backups,
-only the modified chunks need to be written anew. The unchanged chunks are reused directly from existing storage.
+only the modified chunks need to be written anew. The unchanged chunks are reused directly from existing storage
 
 In Prime Backup, restoring a chunked file is transparent to users.
-The original file is reconstructed automatically when the backup is read or exported.
+The original file is reconstructed automatically when the backup is read or exported
 
 ## When It Is Applied
 
@@ -25,7 +25,7 @@ A rule matches when both conditions are true:
 - the file size is at least `file_size_threshold`
 - the file path relative to `source_root` matches the rule's `patterns`
 
-If no rule matches, the file is stored as a regular direct blob without chunking.
+If no rule matches, the file is stored as a regular direct blob without chunking
 
 The default configuration is:
 
@@ -45,11 +45,11 @@ The default configuration is:
 ```
 
 Changing these options only affects files newly stored in future backups.
-Existing direct blobs or chunked blobs will not be converted automatically.
+Existing direct blobs or chunked blobs will not be converted automatically
 
 ## How It Is Stored
 
-Prime Backup still creates one blob record for the whole file, but the blob uses the `chunked` storage method instead of `direct`.
+Prime Backup still creates one blob record for the whole file, but the blob uses the `chunked` storage method instead of `direct`
 
 The current implementation works in the following order:
 
@@ -78,13 +78,13 @@ so the implementation groups consecutive chunks into chunk groups and stores two
 +--------+--------+--------+--------+--------+--------+--------+--------+--------+
 ```
 
-This reduces metadata overhead without changing the logical model.
+This reduces metadata overhead without changing the logical model
 
-Chunk hashes and chunk group hashes always use `blake3`, while the whole-file blob hash still follows `backup.hash_method`.
+Chunk hashes and chunk group hashes always use `blake3`, while the whole-file blob hash still follows `backup.hash_method`
 
 ## Compression and Performance
 
-Chunking does not disable compression.
+Chunking does not disable compression
 
 For a chunked blob:
 
@@ -94,7 +94,7 @@ For a chunked blob:
 
 Compared with direct blob storage, chunked storage is slower on the first backup of a file,
 because Prime Backup needs extra work to cut the file, calculate hashes, and process each chunk.
-The benefit becomes apparent on subsequent backups where many chunks can be reused.
+The benefit becomes apparent on subsequent backups where many chunks can be reused
 
 ## Available Algorithms
 
@@ -114,7 +114,7 @@ See the detailed pages for each approach:
 ## Observation
 
 Prime Backup maintenance logic already understands chunked storage.
-You can inspect the effect with `!!pb database overview`, which includes a dedicated chunk statistics section.
+You can inspect the effect with `!!pb database overview`, which includes a dedicated chunk statistics section
 
 If Prime Backup finds that one chunked file produced many brand new chunks in a single backup, it will emit a warning in logs.
-That usually means the file is not a good chunking target, unless this is the first backup containing that file.
+That usually means the file is not a good chunking target, unless this is the first backup containing that file

docs/feature/database_inspect.md

@@ -2,7 +2,7 @@
 title: 'Database Internal Object Inspection'
 ---
 
-View and inspect object information in the database.
+View and inspect object information in the database
 
 ## Overview
 
@@ -87,7 +87,7 @@ View detailed information for a specific file in a fileset:
 !!pb database inspect file2 <fileset_id> <file_path>
 ```
 
-Displays the same content as above.
+Displays the same content as above
 
 ## Fileset Inspection
 
@@ -129,7 +129,7 @@ View complete information for a specific blob:
 !!pb database inspect blob <hash>
 ```
 
-The parameter `<hash>` can be a prefix of the complete hash string, as long as it uniquely identifies the object.
+The parameter `<hash>` can be a prefix of the complete hash string, as long as it uniquely identifies the object
 
 Example:
 

docs/feature/database_operation.md

@@ -2,7 +2,7 @@
 title: 'Database Operations'
 ---
 
-Configuration migration and data modification operations.
+Configuration migration and data modification operations
 
 ## Hash Algorithm Migration