【问题标题】:overwrite a file on tape覆盖磁带上的文件
【发布时间】:2020-07-20 02:01:50
【问题描述】:

我正在尝试编写一个程序来在磁带上存储大量数据(100 PB)。我正在使用 tar 将文件组合在一起,但出于技术原因,我决定在一个磁带中写入多个 tar。

为了轻松找到磁带上的数据,我决定创建一个小型索引并将其写入磁带的开头。所以我正在做这样的事情:

# create an empty index file
head -c 1M < /dev/urandom > index.txt

# rewind tape
mt -f /dev/nst0 rewind

# write index to the beginning of the tape
dd bs=4k if=index.txt of=/dev/nst0


# write tar file to tape
dd bs=4k if=one.tar of=/dev/nst0
...

复制完所有 tar 文件后,我创建一个大小完全相同的新 index.txt 并将其复制到磁带的开头:

mt -f /dev/nst0 rewind
dd bs=4k if=index.txt of=/dev/nst0

但它会破坏其余数据。损坏是指如果我倒带磁带并尝试从中读取,我只能读取 index.txt 文件,之后它无法读取更多数据,mt status 导致:

SCSI 2 tape drive:
File number=1, block number=-1, partition=0.
Tape block size 0 bytes. Density code 0x5c (LTO-7).
Soft error count since last status=0
General status bits on (9010000):
 EOD ONLINE IM_REP_EN

一开始我虽然 dd 以某种方式破坏了 index.txt 末尾的 EOF 标记,所以我尝试只编辑文件的开头:

dd conv=notrunc count=10 bs=4k if=index.txt of=/dev/nst4

有线的事情是在那之后,我在磁带中的第一个条目将只有 40K! (每个 4k 10 个块)

我是否遗漏了 tape 和 dd 命令的行为?

P.S:数据作为对象存储在 Ceph 上,我需要下载它们,但我没有足够的空间来存储 1 个磁带

【问题讨论】:

  • 这就是磁带的工作方式。它只能附加到。你最后一次停止写入的地方就是你的数据的结束。
  • 如果您正在写入大量数据,您应该尝试写入磁带标记,因为许多系统可以向前或向后定位到磁带标记比定位到文件结尾快得多。
  • 进一步的忠告...确保在磁带的开头写上标签(磁性,而不是用笔),这样如果您的外部条形码脱落或被损坏。
  • 如果您不知道,有一个 ANSI/ISO 标准 80 字节磁带标签 ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/…

标签: tar dd data-persistence


【解决方案1】:

我有同样的想法,我遇到了同样的问题。我正在开发一个简单的磁带备份程序,它基本上是 tar 的包装器,它还包括一个开头的目录,可以使用 list 函数检索。它还具有验证功能,可检查存档中的文件是否仍与其原始校验和匹配,或者是否已损坏。

我想实现一个真正的附加功能,但令我惊讶的是,在开始更新 TOC 之后,似乎无法阻止系统写入文件标记(在错误的位置,在存档中)。

但是,我的备份程序(名称为“TOCTAR”)也具有安全检查功能,如果未提供磁带文件索引选项,管理员将无法覆盖磁带上的第一个存档。它还具有自动附加功能,它会尝试查找所有存档(由该程序创建),使它们保持不变并在最后创建一个新的磁带文件。也许它对您的用例有用。如果您发现有问题或遗漏的内容,请随时打开 Github 问题。

简而言之:我无法在不截断磁带的情况下覆盖一段磁带。但是您可以在磁带上创建尽可能多的存档,而我的磁带备份程序“TOCTAR”可能会帮助您。 (无耻的自我推销。)

我会在此处发布 Github 网址,但 Github 目前已关闭(504 网关超时)。多么悲伤的一天。

更新:https://github.com/c0xc/toctar.git

【讨论】:

    【解决方案2】:

    既然您是在 LTO-7 上写作,为什么不使用 LTFS?它完全符合您的要求,只是做得更好。它适用于 LTO>=5。

    简而言之,您可以将磁带挂载为文件系统,然后像任何其他文件系统一样创建目录并在其上写入文件。唯一的区别是,在磁带上进行备份可以获得非常高的传输率和非常长的寻道时间。

    【讨论】:

    • 我不使用 LTFS 的原因是 LTFS 是为“多次读取,多次写入”的情况而设计的,但我的工作负载更多的是“一次写入,多次读取”类型。因为 LTFS 是为这个更广泛的目标而设计的,所以它必须做一些权衡。具体来说,我不喜欢 LTFS 存储它的索引目录的方式。
    猜你喜欢
    • 2016-05-17
    • 2021-04-06
    • 2023-03-17
    • 2023-02-03
    • 2019-02-20
    • 1970-01-01
    • 2014-08-29
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多