相关疑难解决方法(0)

根据以下问题：
什么是安装时的“循环设备”？
循环设备是充当基于块的设备的文件。虽然我可以从概念上理解这一点，但这与挂载任何其他文件有什么不同？例如，如果我获取 ext2 文件系统的 dd 映像然后挂载它，则不必使用循环选项 -mount -t ext2 file.dd /mnt/mount-point成功。

我什么时候应该使用 loop 选项，使用 loop 选项进行安装和不使用它进行安装有什么区别？

我正在寻找“正确”的方法将音频 CD 的内容转储到硬盘，而不会丢失任何信息，如 CD 标识符、提示列表等......

我并不是在寻找从 CD 到压缩音频的一体化解决方案，例如 ABCDE，因为我目前无法确定未来可能需要的所有音频格式和数据结构。未来。也没有必要在转储时查询在线 CD 信息源，例如 CDDB 或 Musicbrainz。这个想法更多的是获得完整、完美质量、无损（显然）的 CD 转储，在一组文件中，我可以根据需要使用各种现有或未来软件的不同参数对这些文件进行多次后处理，用于将部分或全部库批量转换为特定格式。我主要是想避免不得不多次播放超过一千张 CD 的物理磁盘骑师。

获得整个音频数据的二进制转储以及提示时间、CD 文本数据、CD 标识符等的最佳程序和选项集是什么......好吧，磁盘上的任何内容？

我有编程技能，编写必要的脚本来批处理转储的内容不是问题，只要我们谈论的是线性音频 (.wav) 和文本文件。

我还想知道将整个 CD 音频作为单个轨道或单个轨道是否会更好。我有很多现场录音，对于这些录音来说，单轨可能更有用，因为这通常是我听它们的方式。对此的任何建议也将不胜感激。

到目前为止，我已经尝试了 cdda2wav 和 cdrdao，我发现以下一组命令可能给我提供了很多我需要的数据：

cdda2wav -D /dev/cdr0 -B
cdda2wav -D /dev/cdr0 -t all -cuefile
cdda2wav -D /dev/cdr0 -J
cd-info -C /dev/cdr0
cdrdao read-cd toc_file

运行所有这些命令会导致大量冗余信息被转储，当然还会多次读取整张 CD。我无法清楚地确定其中一个命令提供的数据是另一个命令的严格子集，因此我提出了问题。

我在带有 4 个 SATA CD 驱动器的桌面上使用 Linux slackware 15.0。除了上述内容之外，您是否认为使用多个 CD 驱动器并行转储最多 4 张 CD（节省时间）会导致更高的错误风险（例如，在有划痕的介质上）？

硬件：2 个 8GB USB 闪存驱动器
发行版：Mint 9 Xfce 持久性 Live Cd

一个 U 盘有两个分区：
1) FAT32 700MB Mint 9 分区
2) ext3 7.3GBcasper-rw分区

目标：
我想复制那个 USB 闪存驱动器，因为我不想再次经历从头开始安装和配置的时间。

经验：
1) 我发现这dd不适用于这项工作，因为如果我的一个闪存驱动器的大小甚至有 1MB 不同（有时确实如此），那么副本就会损坏。

2) 我发现gparted像第一个驱动器一样使用和预格式化第二个驱动器，然后rsync单独对每个分区进行格式化是行不通的，因为出于某种原因，某些文件没有被复制并且驱动器仍然无法启动。

我想保留我的工作棒，只是复制它并为我的朋友配置棒。这样，如果我弄坏了另一根棍子，我将始终让我的基本棍子坐在那里等待。

循环设备一词的词源是什么

描述：维基百科：循环设备

我正在阅读理解安装概念的麻烦并遇到了这个解释：

通过使用mount -t iso9660 /dev/cdrom /media/cdrom，您告诉系统：“将您在 中的这个非常长的字节串，/dev/cdrom按照iso9660格式解释为目录树，并允许我在该位置下访问它/media/cdrom”

以及沿着这条线的其他答案。这是有道理的，从这个逻辑中，我了解到挂载本质上是将文件系统耦合到设备，该设备以内核可以将其放入现有文件系统层次结构中的方式解释设备的内容。

如果确实如此，为什么需要循环安装？

由于 amount -o loop在技​​术上与该操作mount的目的相同：读取文件并在文件系统的上下文中解释其内容，为什么我们不能在不创建特殊设备的情况下概括挂载操作？

编辑：我知道循环设备为文件提供了块设备 API。然而，我的问题更笼统。从普通文件（iso或类似的磁盘映像格式）读取与从特殊文件读取（如果它们包含相同的数据）有何不同？

我关于mount工作原理的心智模型是这样的：给定由/dev/device文件公开的一组任意字节，这些字节随后由文件系统驱动程序（ext4例如）解释，mount命令将其与根层次结构相关联，以便它对最终用户看起来是透明的.

但是，这组任意字节可以出现在任何地方。如果由文件系统驱动程序解释，它们应该被识别为有效的文件系统。什么限制文件系统驱动程序只能从特殊文件而不是常规文件中读取？