|
From: Tim W. <sou...@wo...> - 2025-03-19 20:09:37
|
Hi everyone, The 0.4b50 release of dump/restore has been published. (The date in the manpages says "version 0.4b50 of 22 Mar 2025". I didn't expect to get time to publish until the weekend but all the tests completed last night and I got a bit of spare time today so you get it early) For most people there's little of interest here unless you're having problems restoring old dumps where there's a few fixes: 1. A new command line option --ignore-compression-flag-for-0.4b45-dumps for restore that allows dumps writen with "compression" by v0.4b45 to be restored. This flag should not be used in any other context - it won't help! Thankyou to Greg for his update on bug #169 which lead to this. 2. The Archive file was not padded to a whole number of tape blocks. This means that 0.4b49 could not use archive files unless they happened to be the correct length. 3. Tapes written with compression header bitfields that are not in amd64 gcc order can now be read. This was supposed to work in 0.4b49 but a bug meant that it only worked for amd64 gcc ordered bitfields. 0.4b49 removed the compiler dependency and ensured the bitfields were always written in the amd64 gcc order. There's one bugfix - which has been patched in debian for ages: QFAfiles for real tapes always had a zero tape position. I inadvertently dropped this completely while bringing in the debian fixes to 0.4b49. Thankyou to Alexander Zangerl for spotting my mistake. And there's two new command line options to dump: --filesys-name - which lets you set the text of the dump to replace the default "an unlisted filesystem". This is particularly aimed at people who dump from snapshots which do not appear in fstab or mtab. --dumpdates-time - which sets the time of the dump to that supplied on the command line instead of dump using the current time when it starts. There's a race condition related to dumping from snapshots that this resolves (see below for details of the race condition for anyone who thinks they might be impacted) See NEWS for more details of the changes in this release. I haven't fully tested all the long command line options. They should all be documented in the man pages. I'll give a credit in the next NEWS file for anyone who finds any where I've made a mistake and it doesn't work the same way as the single character option. File a bug on the sourceforge page or email me or one of the dump lists. ------- Race condition related to dump timestamps and snapshots: Day 1 level 0 dump: (assume this starts at 00:00:00 on day 1) 1. Take a snapshot of the filesystem at D1-00:00:00 A file now changes on the underlying filesystem - this change is not visible in the snapshot - the file has the modification time of D1-00:00:01 2. Dump starts at D1-00:00:02 and writes this timestamp into dumpdates. The level 0 dump completes and verifies correctly against the snapshot. Day 1 level 1 dump: (assume this starts at 00:00:00 on day 2) 1. Take a snapshot of the filesystem at D2-00:00:00 2. Take the level 1 dump. All files that have changes between D1-00:00:02 and D2-00:00:00 will be included in the dump. The file with the D1-00:00:01 timestamp is missed and never gets included in any incremental dump (unless the file changes again) In order to avoid this issue, --dumpdates-time should be set to the time of the snapshot (which will likely be a few seconds earler than dump would have written to dumpdates. N.B. There are plenty of other issues related to taking a dump of a live filesystem that this commandline flag doesn't solve but many of us do take snapshots of a live file system to dump it. |