Tim Asked: 2018-04-30 14:05:02 +0800 CST2018-04-30 14:05:02 +0800 CST 2018-04-30 14:05:02 +0800 CST Duplicity 是否在备份时修改时间？ 772 我的数据位于 SSD 上，并且由于重写和写入放大，对 atime 的任何修改不仅会导致 inode 被修改，而且它所在的整个块都被擦除和重写。这显然是不受欢迎的，因为它会导致驱动器出现大量不必要的磨损。 Duplicity在备份文件时，是否修改了进程中源文件的atime属性？ 如果它确实修改了 atime，它是在初始（完整）备份、增量备份还是两者上都这样做？ backup ssd 2 个回答 Voted Best Answer Tim 2018-05-28T08:06:44+08:002018-05-28T08:06:44+08:00 答案是肯定的。Duplicity 会在初始备份过程中修改每个文件的 inode 的 atime。这会触发大量 SSD 重新写入和写入放大。 在随后的（增量）备份中，会重写小得多（但数量仍然很大）的 inode（当然还有更改的文件）。 Duplicity 不会尝试保留文件的时间。 公平地说，Duplicity 处理这个问题的方式非常传统，不会给 HDD 带来特别大的负担。重写和写入放大的问题特别是 SSD 问题。因此，关于 Duplicity 可以说的就是它没有针对 SSD 进行优化，并且（所有其他条件相同）如果使用 Duplicity，SSD 的磨损速度会比 HDD 快。 正如frostschutz 在评论中指出的那样，可以通过使用 noatime 设置安装文件系统来解决此问题……因此可以相对轻松地缓解它。 随着 HDD 的消亡和 SSD 的接管，文件系统将越来越多地针对 SSD 进行优化，我们可以预期由时间变化、重写和写入放大引起的磨损/性能问题将得到解决。像F2FS这样的新文件系统就是以身作则。 Mukunda Modell 2018-10-31T13:35:21+08:002018-10-31T13:35:21+08:00 不，说软件应用程序修改atime文件是不正确的。用户模式程序几乎没有办法控制是否atime更新。那是操作系统的责任，或者更具体地说，是文件系统驱动程序的责任。此外，Linux 上当前的默认挂载选项将最小化时间戳更新，因此它们对性能或ssd寿命的影响很小。 现代Linux发行版的现状如下： 使用挂载选项noatime完全消除了atime更新，代价是维护atime元数据提供的任何实用程序。 默认relatime选项使问题最小化 最近推出的选项lazytime应该完全消除时间戳更新对 SSD 寿命的任何剩余影响。
答案是肯定的。Duplicity 会在初始备份过程中修改每个文件的 inode 的 atime。这会触发大量 SSD 重新写入和写入放大。
在随后的（增量）备份中，会重写小得多（但数量仍然很大）的 inode（当然还有更改的文件）。
Duplicity 不会尝试保留文件的时间。
公平地说，Duplicity 处理这个问题的方式非常传统，不会给 HDD 带来特别大的负担。重写和写入放大的问题特别是 SSD 问题。因此，关于 Duplicity 可以说的就是它没有针对 SSD 进行优化，并且（所有其他条件相同）如果使用 Duplicity，SSD 的磨损速度会比 HDD 快。
正如frostschutz 在评论中指出的那样，可以通过使用 noatime 设置安装文件系统来解决此问题……因此可以相对轻松地缓解它。
随着 HDD 的消亡和 SSD 的接管，文件系统将越来越多地针对 SSD 进行优化，我们可以预期由时间变化、重写和写入放大引起的磨损/性能问题将得到解决。像F2FS这样的新文件系统就是以身作则。
不，说软件应用程序修改
atime文件是不正确的。用户模式程序几乎没有办法控制是否atime更新。那是操作系统的责任，或者更具体地说，是文件系统驱动程序的责任。此外，Linux 上当前的默认挂载选项将最小化时间戳更新，因此它们对性能或ssd寿命的影响很小。现代Linux发行版的现状如下：
noatime完全消除了atime更新，代价是维护atime元数据提供的任何实用程序。relatime选项使问题最小化lazytime应该完全消除时间戳更新对 SSD 寿命的任何剩余影响。