Skip to content

Commit 10b2a24

Browse files
authored
Merge pull request #7925 from alexs-sh/shred-minor-updates
shred: minor improvements and tests
2 parents 9fce1a1 + 14a8f3f commit 10b2a24

File tree

1 file changed

+11
-6
lines changed

1 file changed

+11
-6
lines changed

src/uu/shred/src/shred.rs

Lines changed: 11 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -49,11 +49,11 @@ const NAME_CHARSET: &[u8] = b"0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMN
4949
const PATTERN_LENGTH: usize = 3;
5050
const PATTERN_BUFFER_SIZE: usize = BLOCK_SIZE + PATTERN_LENGTH - 1;
5151

52-
/// Optimal block size for the filesystem. This constant is used for data size alignment,
53-
/// similar to the behavior of GNU shred. Usually, optimal block size is a 4K block, which is why
52+
/// Optimal block size for the filesystem. This constant is used for data size alignment, similar
53+
/// to the behavior of GNU shred. Usually, optimal block size is a 4K block (2^12), which is why
5454
/// it's defined as a constant. However, it's possible to get the actual size at runtime using, for
5555
/// example, `std::os::unix::fs::MetadataExt::blksize()`.
56-
const OPTIMAL_IO_BLOCK_SIZE: usize = 4096;
56+
const OPTIMAL_IO_BLOCK_SIZE: usize = 1 << 12;
5757

5858
/// Patterns that appear in order for the passes
5959
///
@@ -514,12 +514,17 @@ fn wipe_file(
514514
}
515515

516516
fn split_on_blocks(file_size: u64, exact: bool) -> (u64, u64) {
517+
// OPTIMAL_IO_BLOCK_SIZE must not exceed BLOCK_SIZE. Violating this may cause overflows due
518+
// to alignment or performance issues.This kind of misconfiguration is
519+
// highly unlikely but would indicate a serious error.
520+
const _: () = assert!(OPTIMAL_IO_BLOCK_SIZE <= BLOCK_SIZE);
521+
517522
let file_size = if exact {
518523
file_size
519524
} else {
520-
// The main idea here is to align the file size to the OPTIMAL_IO_BLOCK_SIZE, and then split it into
521-
// BLOCK_SIZE + remaining bytes. Since the input data is already aligned to N * OPTIMAL_IO_BLOCK_SIZE,
522-
// the output file size will also be aligned and correct.
525+
// The main idea here is to align the file size to the OPTIMAL_IO_BLOCK_SIZE, and then
526+
// split it into BLOCK_SIZE + remaining bytes. Since the input data is already aligned to N
527+
// * OPTIMAL_IO_BLOCK_SIZE, the output file size will also be aligned and correct.
523528
file_size.div_ceil(OPTIMAL_IO_BLOCK_SIZE as u64) * OPTIMAL_IO_BLOCK_SIZE as u64
524529
};
525530
(file_size / BLOCK_SIZE as u64, file_size % BLOCK_SIZE as u64)

0 commit comments

Comments
 (0)