Linux 为什么在使用 dd 克隆磁盘时使用 conv=notrunc？

Why using conv=notrunc when cloning a disk with dd?

提问by Undo

If you look up how to clone an entire disk to another one on the web, you will find something like that:

如果您在网上查找如何将整个磁盘克隆到另一个磁盘，您会发现如下内容：

dd if=/dev/sda of=/dev/sdb conv=notrunc,noerror

While I understand the noerror, I am getting a hard time understanding why people think that notruncis required for "data integrity" (as ArchLinux's Wikistates, for instance).

虽然我理解noerror，但我很难理解为什么人们认为这notrunc是“数据完整性”所必需的（例如ArchLinux 的 Wiki所述）。

Indeed, I do agree on that if you are copying a partition to another partition on another disk, and you do not want to overwrite the entire disk, just one partition. In thise case notrunc, according to dd's manual page, is what you want.

事实上，我确实同意，如果您将一个分区复制到另一个磁盘上的另一个分区，并且您不想覆盖整个磁盘，只需覆盖一个分区。在这种情况下notrunc，根据 dd 的手册页，这就是您想要的。

But if you're cloning an entire disk, what does notruncchange for you? Just time optimization?

但是，如果您要克隆整个磁盘，notrunc对您有什么影响？只是时间优化？

采纳答案by rkyser

TL;DR version:

TL；DR 版本：

notruncis only important to prevent truncation when writing into a file. This has no effect on a block device such as sdaor sdb.

notrunc仅在写入文件时防止截断很重要。这对块设备（例如sda或 ）没有影响sdb。

Educational version

教育版

I looked into the coreutilssource code which contains dd.cto see how notruncis processed.

我查看了包含dd.c的coreutils源代码，看看是如何处理的。notrunc

Here's the segment of code that I'm looking at:

这是我正在查看的代码段：

int opts = (output_flags
            | (conversions_mask & C_NOCREAT ? 0 : O_CREAT)
            | (conversions_mask & C_EXCL ? O_EXCL : 0)
            | (seek_records || (conversions_mask & C_NOTRUNC) ? 0 : O_TRUNC));

/* Open the output file with *read* access only if we might
need to read to satisfy a `seek=' request.  If we can't read
the file, go ahead with write-only access; it might work.  */
if ((! seek_records
    || fd_reopen (STDOUT_FILENO, output_file, O_RDWR | opts, perms) < 0)
    && (fd_reopen (STDOUT_FILENO, output_file, O_WRONLY | opts, perms) < 0))
        error (EXIT_FAILURE, errno, _("opening %s"), quote (output_file));

We can see here that if notruncis notspecified, then the output file will be opened with O_TRUNC. Looking below at how O_TRUNCis treated, we can see that a normal file will get truncated if written into.

在这里我们可以看到，如果notrunc是没有指定，那么输出文件将与O_TRUNC打开。看看下面是如何O_TRUNC处理的，我们可以看到如果写入普通文件会被截断。

O_TRUNC

O_TRUNC

If the file already exists and is a regular file and the open mode allows writing (i.e., is O_RDWR or O_WRONLY) it will be truncated to length 0. If the file is a FIFO or terminal device file, the O_TRUNC flag is ignored. Otherwise the effect of O_TRUNC is unspecified.

如果文件已经存在并且是一个普通文件并且打开​​模式允许写入（即，是 O_RDWR 或 O_WRONLY），它将被截断为长度 0。如果文件是 FIFO 或终端设备文件，则忽略 O_TRUNC 标志。否则 O_TRUNC 的效果是未指定的。

Effects of notrunc/ O_TRUNCI

的影响notrunc/O_TRUNC我

In the following example, we start out by creating junk.txtof size 1024 bytes. Next, we write 512 bytes to the beginning of it with conv=notrunc. We can see that the size stays the same at 1024 bytes. Finally, we try it without the notruncoption and we can see that the new file size is 512. This is because it was opened with O_TRUNC.

在以下示例中，我们首先创建junk.txt大小为 1024 字节的文件。接下来，我们将 512 字节写入它的开头conv=notrunc。我们可以看到大小保持不变，为 1024 字节。最后，我们在没有notrunc选项的情况下试了一下，我们可以看到新的文件大小是 512。这是因为它是用O_TRUNC.

$ dd if=/dev/urandom of=junk.txt bs=1024 count=1
$ ls -l junk.txt
-rw-rw-r-- 1 akyserr akyserr 1024 Dec 11 17:08 junk.txt

$ dd if=/dev/urandom of=junk.txt bs=512 count=1 conv=notrunc
$ ls -l junk.txt
-rw-rw-r-- 1 akyserr akyserr 1024 Dec 11 17:10 junk.txt

$ dd if=/dev/urandom of=junk.txt bs=512 count=1
$ ls -l junk.txt
-rw-rw-r-- 1 akyserr akyserr 512 Dec 11 17:10 junk.txt

Effects of notrunc/ O_TRUNCII

的影响notrunc/ O_TRUNCII

I still haven't answered your original question of why when doing a disk-to-disk clone, why conv=notruncis important. According to the above definition, O_TRUNCseems to be ignored when opening certain special files, and I would expect this to be true for block device nodes too. However, I don't want to assume anything and will attempt to prove it here.

我仍然没有回答您最初的问题，即为什么在进行磁盘到磁盘克隆时为什么conv=notrunc很重要。根据上面的定义，O_TRUNC在打开某些特殊文件时似乎会被忽略，我希望这对于块设备节点也是如此。但是，我不想假设任何事情，并会尝试在这里证明这一点。

openclose.c

打开关闭文件

I've written a simple C program here which opens and closes a file given as an argument with the O_TRUNCflag.

我在这里编写了一个简单的 C 程序，它打开和关闭作为带有O_TRUNC标志的参数给出的文件。

#include <stdio.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <time.h>

int main(int argc, char * argv[])
{
    if (argc < 2)
    {
        fprintf(stderr, "Not enough arguments...\n");
        return (1);
    }

    int f = open(argv[1], O_RDWR | O_TRUNC);

    if (f >= 0)
    {
        fprintf(stderr, "%s was opened\n", argv[1]);
        close(f);
        fprintf(stderr, "%s was closed\n", argv[1]);
    } else {
        perror("Opening device node");
    }

    return (0);
}

Normal File Test

普通文件测试

We can see below that the simple act of opening and closing a file with O_TRUNCwill cause it to lose anything that was already there.

我们可以在下面看到，打开和关闭文件的简单操作O_TRUNC将导致它丢失任何已经存在的内容。

$ dd if=/dev/urandom of=junk.txt bs=1024 count=1^C
$ ls -l junk.txt 
-rw-rw-r-- 1 akyserr akyserr 1024 Dec 11 17:26 junk.txt

$ ./openclose junk.txt
junk.txt was opened
junk.txt was closed

$ ls -l junk.txt
-rw-rw-r-- 1 akyserr akyserr 0 Dec 11 17:27 junk.txt

Block Device File Test

块设备文件测试

Let's try a similar test on a USB flash drive. We can see that we start out with a single partition on the USB flash drive. If it get's 'truncated', perhaps the partition will go away (considering it's defined in the first 512 bytes of the disk)?

让我们在 U 盘上尝试类似的测试。我们可以看到我们从 USB 闪存驱动器上的单个分区开始。如果它被“截断”，那么分区可能会消失（考虑到它是在磁盘的前 512 个字节中定义的）？

$ ls -l /dev/sdc*
brw-rw---- 1 root disk 8, 32 Dec 11 17:22 /dev/sdc
brw-rw---- 1 root disk 8, 33 Dec 11 17:22 /dev/sdc1

$ sudo ./openclose /dev/sdc
/dev/sdc was opened
/dev/sdc was closed

$ sudo ./openclose /dev/sdc1
/dev/sdc1 was opened
/dev/sdc1 was closed

$ ls -l /dev/sdc*
brw-rw---- 1 root disk 8, 32 Dec 11 17:31 /dev/sdc
brw-rw---- 1 root disk 8, 33 Dec 11 17:31 /dev/sdc1

It looks like it has no affect whatsoever to open either the disk or the disk's partition 1 with the O_TRUNCoption. From what I can tell, the filesystem is still mountable and the files are accessible and intact.

使用该O_TRUNC选项打开磁盘或磁盘的分区 1 似乎没有任何影响。据我所知，文件系统仍然可以挂载，并且文件可以访问且完好无损。

Effects of notrunc/ O_TRUNCIII

的影响notrunc/ O_TRUNCIII

Okay, for my final test I will use ddon my flash drive directly. I will start by writing 512 bytes of random data, then writing 256 bytes of zeros at the beginning. For the final test, we will verify that the last 256 bytes remained unchanged.

好的，对于我的最终测试，我将dd直接在我的闪存驱动器上使用。我将首先写入 512 字节的随机数据，然后在开头写入 256 字节的零。对于最终测试，我们将验证最后 256 个字节是否保持不变。

$ sudo dd if=/dev/urandom of=/dev/sdc bs=256 count=2
$ sudo hexdump -n 512 /dev/sdc
0000000 3fb6 d17f 8824 a24d 40a5 2db3 2319 ac5b
0000010 c659 5780 2d04 3c4e f985 053c 4b3d 3eba
0000020 0be9 8105 cec4 d6fb 5825 a8e5 ec58 a38e
0000030 d736 3d47 d8d3 9067 8db8 25fb 44da af0f
0000040 add7 c0f2 fc11 d734 8e26 00c6 cfbb b725
0000050 8ff7 3e79 af97 2676 b9af 1c0d fc34 5eb1
0000060 6ede 318c 6f9f 1fea d200 39fe 4591 2ffb
0000070 0464 9637 ccc5 dfcc 3b0f 5432 cdc3 5d3c
0000080 01a9 7408 a10a c3c4 caba 270c 60d0 d2f7
0000090 2f8d a402 f91a a261 587b 5609 1260 a2fc
00000a0 4205 0076 f08b b41b 4738 aa12 8008 053f
00000b0 26f0 2e08 865e 0e6a c87e fc1c 7ef6 94c6
00000c0 9ced 37cf b2e7 e7ef 1f26 0872 cd72 54a4
00000d0 3e56 e0e1 bd88 f85b 9002 c269 bfaa 64f7
00000e0 08b9 5957 aad6 a76c 5e37 7e8a f5fc d066
00000f0 8f51 e0a1 2d69 0a8e 08a9 0ecf cee5 880c
0000100 3835 ef79 0998 323d 3d4f d76b 8434 6f20
0000110 534c a847 e1e2 778c 776b 19d4 c5f1 28ab
0000120 a7dc 75ea 8a8b 032a c9d4 fa08 268f 95e8
0000130 7ff3 3cd7 0c12 4943 fd23 33f9 fe5a 98d9
0000140 aa6d 3d89 c8b4 abec 187f 5985 8e0f 58d1
0000150 8439 b539 9a45 1c13 68c2 a43c 48d2 3d1e
0000160 02ec 24a5 e016 4c2d 27be 23ee 8eee 958e
0000170 dd48 b5a1 10f1 bf8e 1391 9355 1b61 6ffa
0000180 fd37 7718 aa80 20ff 6634 9213 0be1 f85e
0000190 a77f 4238 e04d 9b64 d231 aee8 90b6 5c7f
00001a0 5088 2a3e 0201 7108 8623 b98a e962 0860
00001b0 c0eb 21b7 53c6 31de f042 ac80 20ee 94dd
00001c0 b86c f50d 55bc 32db 9920 fd74 a21e 911a
00001d0 f7db 82c2 4d16 3786 3e18 2c0f 47c2 ebb0
00001e0 75af 6a8c 2e80 c5b6 e4ea a9bc a494 7d47
00001f0 f493 8b58 0765 44c5 ff01 42a3 b153 d395

$ sudo dd if=/dev/zero of=/dev/sdc bs=256 count=1
$ sudo hexdump -n 512 /dev/sdc
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
0000100 3835 ef79 0998 323d 3d4f d76b 8434 6f20
0000110 534c a847 e1e2 778c 776b 19d4 c5f1 28ab
0000120 a7dc 75ea 8a8b 032a c9d4 fa08 268f 95e8
0000130 7ff3 3cd7 0c12 4943 fd23 33f9 fe5a 98d9
0000140 aa6d 3d89 c8b4 abec 187f 5985 8e0f 58d1
0000150 8439 b539 9a45 1c13 68c2 a43c 48d2 3d1e
0000160 02ec 24a5 e016 4c2d 27be 23ee 8eee 958e
0000170 dd48 b5a1 10f1 bf8e 1391 9355 1b61 6ffa
0000180 fd37 7718 aa80 20ff 6634 9213 0be1 f85e
0000190 a77f 4238 e04d 9b64 d231 aee8 90b6 5c7f
00001a0 5088 2a3e 0201 7108 8623 b98a e962 0860
00001b0 c0eb 21b7 53c6 31de f042 ac80 20ee 94dd
00001c0 b86c f50d 55bc 32db 9920 fd74 a21e 911a
00001d0 f7db 82c2 4d16 3786 3e18 2c0f 47c2 ebb0
00001e0 75af 6a8c 2e80 c5b6 e4ea a9bc a494 7d47
00001f0 f493 8b58 0765 44c5 ff01 42a3 b153 d395

Summary

概括

Through the above experimentation, it seems that notruncis only important for when you have a file you want to write into, but don't want to truncate it. This seems to have no effect on a block device such as sda or sdb.

通过上面的实验，似乎notrunc只有当您有一个要写入的文件但又不想截断它时才重要。这似乎对 sda 或 sdb 等块设备没有影响。