Description of problem:
The dump/restore utilities are long neglected upstream with no meaningful update for about 4 years now. It is not being properly tested and should not be relied upon for backup purposes especially.
Looking at the code it is very much outdated and will not support current ext4 features, in some cases leading to corrupted files without dump/restore even noticing any problems.
After offline discussion with maintainer, he confirmed that he is no longer working on it and does not have any plans to resurrect it.
I've also raised the issue on the ext4 list and ext4 maintainer seems to share the sentiment that dump/restore has been on life support for a long enough and pulling the plug on it is overdue.
Let's dump the dump already.
I agree with Lukas. Due of lack of upstream activity and support for new file system features, we're going to remove dump from future RHEL/CentOS releases as well.
Jeff, what's your opinion?
Dump remains viable for ext2 and ext3 file systems and it seems reasonable to continue to provide it for them. Would documenting the ext4 deficiencies in the BUGS section of the man page be sufficient? How about a warning in the RPM description?
Even if we choose to drop dump(8), I think we should continue to provide restore(8) for a very long time to support restoring from existing old backups.
Rather than documenting flaws that may corrupt data, it would be far better to use the compatibility flags and reject any filesystem that has a feature flag dump/restore doesn't understand, I think.
(given that we didn't reject them for quite some time, perhaps documentation + safeguarding in the future would both be wise)
But I guess that requires an active upstream to push that change to ....
(In reply to Jeff Makey from comment #2)
> Dump remains viable for ext2 and ext3 file systems and it seems reasonable
> to continue to provide it for them. Would documenting the ext4 deficiencies
> in the BUGS section of the man page be sufficient? How about a warning in
> the RPM description?
> Even if we choose to drop dump(8), I think we should continue to provide
> restore(8) for a very long time to support restoring from existing old
documenting ext4 deficiencies does not excuse us from shipping deprecated software with know bugs for backup purposes of all things - that's not something I am willing to get behind. I'd go as far as to say don't use it for backup at all. But if there is still enough interest we can perhaps say it's not supported on ext4 at all and leave it for ext2/3 file system while checking and rejecting unsupported features. But even then, there is no active upstream, it's not being tested upstream and I am not really sure how much (if any) testing it receives internally.
If we do make the commitment to support it further by at least checking for features and making sure we disallow anything that the tool will not recognize, or might have problems with (such as extents), then we have to make a decision whether it's something to push upstream (which is dead, it could be forked or we can talk to the last maintainer to make some arrangements), or we maintain it internally.
I think that far better option is to just drop it entirely. It is dead and people should move on. However you've made a very good and sensible point with restore(8) and I do agree we should keep it around for existing old backups.
This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle.
Changing version to 34.
This message is a reminder that Fedora Linux 34 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '34'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version'
to a later Fedora Linux version.
Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora Linux 34 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.
Fedora Linux 34 entered end-of-life (EOL) status on 2022-06-07.
Fedora Linux 34 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
Thank you for reporting this bug and we are sorry it could not be fixed.