On Mon, 5 Aug 2024 at 05:03, Udo Grabowski (IMK) <udo.grabow...@kit.edu> wrote:
> On 05/08/2024 10:57, Toomas Soome via illumos-discuss wrote:
> > So one test scenario would be to test newer build, but with those features
> > disabled, if receive is good, then enable one feature and re-test, till we
> > have
> > suspect:)
> Doesn't help at all, so that problem does not seem to be related to features:
Whether features are turned on or off, the _code_ has changed in the
meantime. It seems like it would be possible on some level to bisect
back to previous package versions, but I expect it would be very
tedious, especially if they've been pruned from the repository in the
meantime, etc.
> # cat /home/lsdf/SAT/Processor/Results/imk/32@20100825 | zfs receive -d test
> cannot receive new filesystem stream: invalid backup stream
As I suggested earlier, I think it's best to start by looking at what
the current version of the software is actually doing and work
backwards to the problem; e.g.,
* What code produces that error message?
(presumably in zfs, the command, or libzfs)
* What causes it to produce that error message?
(presumably some errno returned from the kernel)
* What causes the errno to be returned by the kernel?
(presumably it's occuring in the attempt to process
one of the stream records being fed in from usermode)
* etc, until we find the reason it's confused
You should be able to catch the issue as it occurs with DTrace and a
little reading of the code, etc. I would start by locating in the
source the specific error message you see, i.e., "invalid backup
stream", and see where it is printed, etc.
Cheers.
--
Joshua M. Clulow
http://blog.sysmgr.org
------------------------------------------
illumos: illumos-discuss
Permalink:
https://illumos.topicbox.com/groups/discuss/T575f82eecd117456-M2c4a2c89bdfdebff15f7680a
Delivery options: https://illumos.topicbox.com/groups/discuss/subscription
