Hello,

here is a patch to add support for timestamps with nanoseconds for dump and restore.

For this struct dinode in compat/include/bsdcompat.h is extended with nanoseconds timedata.

As a consequence dumpfiles (or -tapes) from previous versions of dump are not compatible with the new version of restore.

In order to prevent a version mismatch it would be desireable to have a version information at the beginning of dumpfiles. I did not manage to find the code locations where dump begins to write resp. where restore begins to read. Maybe someone else copes with this.

Markus

severity 1053535 wishlist
tags 1053535 + moreinfo
thanks

On Thu, 05 Oct 2023 21:51:40 +0200, markus writes:
...

i'm not at all convinced that this is a useful change, in particular
in a backup/restore tool.

please provide more information as to what benefits this change is
expected to provide, and how those benefits are supposed to outweight
the massive downside of complete incompatibility with existing backups.

regards
az

Hello,

A restore tool should, as its name says, restore the backup as most pristine as possible. Currently dump/restore (on linux) restores timestamps only with seconds, dropping micro- or nanoseconds.

For more than a decade linux kernels and ext2/3/4 filesystems support timestamps with nanoseconds. Most userland utilities have been updated to use it. dump/restore is overdue. It is a severe deficit loosing a part of time information when restoring a backup. I believe nowadays most expect that a backup tool uses all facilities the underlying system supports.

Incompatibility with existing backups is an issue only, if backups are archived. Usually backups are overwritten regularly. (In my case every two months.)

In order to prevent a mismatch a version information at the beginng of a dumpfile (or tape) would be useful. I did not manage to find the code locations where dump begins to write resp. where restore begins to read.

I have found restore contains some code to convert "old headers". I could not figure out, what this means. The code for opening and reading a dumpfile is rather complicated and not well documented.

Please note the patch does not introduce a "complete incompatibility". I did some tests with mixed combinations with old/new dumps and old/new restores. Directories and files where restored correctly but with erroneous timestamps.

Please note there already is a mismatch between sizeof(dinode) and sizeof(ext2_inode) before applying the patch. assert(sizeof(dinode_old) <= sizeof(ext2_inode)) failes. See compat/include/bsdcompat.h and dump/traverse.c.

I have sent my patch in in order to share it with the community.
May be someone else picks it up and adds version information to the dumpfile.

Markus

tags 1053535 + wontfix
thanks

after further consideration i've decided taht i'm not going
to apply this patch: i do not want to change the on-disk format of dumps
for the minimal benefit of archiving files with
nanosecond timestamps.