linux – 我如何tarball proc文件系统？

/ dev文件系统具有真正的i节点,可以备份它们.除了他们没有内容,只有一个主要和次要的号码,权限和名称.备份特殊设备文件的工具仅记录这些参数,从不尝试打开(2)设备.但是,由于设备的主要和次要数字仅对它们所构建的精确系统有意义,因此几乎没有理由对它们进行备份.

尝试tar / proc伪文件系统导致tar崩溃的原因是因为/ proc具有有趣的文件行为：像只写伪文件这样的东西似乎具有读取权限,但如果程序尝试则返回错误指示打开(2)它进行备份.这肯定会驱使一个天真的焦油来获得持久性.

添加以回应评论

tar对读取/ proc / kmsg有问题并不让我感到惊讶,因为它有一些有趣的属性：

# strace cat /proc/kmsg
execve("/bin/cat",["cat","kmsg"],open("kmsg",O_RDONLY|O_LARGEFILE)      = 3
// ok,no problem opening the file for reading
fstat64(3,{ st_mode=S_IFREG|0400,st_size=0,// looks like a normal file of zero length
// but cat does not pay attention to st_size so it just
// does a blocking read
read(3,"<4>[103128.156051] ata2.00: qc t"...,32768) = 461
write(1,461) = 461
// ...forever...
read(3,"<6>[103158.228444] ata2.00: conf"...,32768) = 48
write(1,48) = 48
+++ killed by SIGINT +++

因为/ proc / kmsg是内核消息的运行列表,所以它永远不会返回0(EOF)它只是一直持续到我感到无聊并按^ C.

有趣的是,我的tar与/ proc / kmsg没有问题：

$tar --version
tar (GNU tar) 1.22
# tar cf /tmp/junk.tar /proc/kmsg
$tar tvf /tmp/junk.tar
-r-------- root/root         0 2010-09-01 14:41 proc/kmsg

如果你看看strace输出,GNU tar 1.22看到st_length == 0并且甚至没有打开文件进行读取,因为那里没有任何东西.

我可以想象你的tar看到长度为0,使用malloc(3)分配了那么多(无)空间,它尽职地将指针传回零长度缓冲区.您的tar从/ proc / kmsg读取,读取的长度非零,并尝试将其存储在零长度缓冲区中并导致分段违规.

那只是一个在/ proc中等待焦油的老鼠洞.还有多少人？不知道.他们会表现得一样吗？可能不是.哪些~1000左右的文件不是/ proc /< pid> psuedo文件会有奇怪的语义吗？不知道.

但也许是最有说服力的问题：你对/ proc / sys / vm / lowmem_reserve_ratio有什么意义,下周会有什么不同,你能从这个差异中学到什么吗？