相关疑难解决方法(0)

在很多地方，人们可以看到如今被指责为完全用词不当的“粘滞位”，因为它现在的功能是影响目录的写入权限并充当受限删除标志。

在 AskUbuntu 的回答中，回答者写道“粘性位通常适用于目录”。我观察到确实现代系统在实践中似乎从未将它应用于文件，但很久以前通常的情况是将它应用于（可执行程序映像）文件而不是目录。（当谈到现代文件很少使用时，在当前文件系统中是否未使用粘性位中有一个相关问题。）

这引发了一个问题：

什么做应用到可执行文件做了粘滞位？是不是像 setuid 那样？

注意过去时。这不是粘性位如何工作？现在。这就是它过去的工作方式。

我有 200 GB 的可用磁盘空间、16 GB 的 RAM（其中约 1 GB 被桌面和内核占用）和 6 GB 的交换空间。

我有一个 240 GB 的外部 SSD，使用了 70 GB ¹，其余的免费，我需要将其备份到我的磁盘。

通常，我会dd if=/dev/sdb of=Desktop/disk.img先创建磁盘，然后对其进行压缩，但是首先制作映像不是一种选择，因为这样做需要比我拥有的磁盘空间多得多的磁盘空间，即使压缩步骤会导致可用空间被压缩，因此最终存档可以很容易地放在我的磁盘上。

dd默认情况下写入 STDOUT，并且gzip可以从 STDIN 读取，所以理论上我可以写入dd if=/dev/sdb | gzip -9 -，但gzip读取字节所需的时间比dd产生它们的时间要长得多。

来自man pipe：

写入管道写端的数据由内核缓冲，直到从管道的读端读取。

我将 a 想象|成一个真正的管道——一个应用程序将数据推入，另一个应用程序尽可能快地从管道队列中取出数据。

当左侧的程序写入的数据比管道的另一侧希望处理的数据多时，该怎么办？它会导致极端的内存或交换使用，还是内核会尝试在磁盘上创建一个 FIFO，从而填满磁盘？或者SIGPIPE Broken pipe如果缓冲区太大它会失败吗？

基本上，这归结为两个问题：

1. 将多于一次读取的数据推入管道的含义和结果是什么？
2. 将数据流压缩到磁盘而不将整个未压缩的数据流放在磁盘上的可靠方法是什么？

_{注 1：我不能仅仅复制前 70 个使用的 GB 并期望获得一个工作系统或文件系统，因为碎片和其他需要完整内容完整的东西。}

如果我有一根管道：

process1 | process2

进程 1 非常快地生成数千兆字节的数据，但进程 2 需要通过网络发送该数据，因此速度要慢得多，执行以下操作：

• 减慢process1的执行速度？；或者
• 将数据缓冲在某处，直到进程 2 可以读取它？

如果数据正在缓冲，是由内核缓冲的吗？是在内存中，还是在磁盘上？这个缓冲区有多大？当缓冲区溢出时会发生什么？

当一个命令以什么方式或以什么格式通过管道传输到另一个命令时，管道输出存在/发送？是临时文件吗？是字符串吗？接收管道输出的命令如何解码/读取该输出？

例子：

echo "Someone string" | ./program | tail

程序“ program”是否echo以文件形式接收输出？程序将如何读取该输入？