Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

zfs receive - invalid stream format on receive with dedup processing enabled on send #432

Closed
dblacknc opened this issue Nov 2, 2011 · 2 comments
Closed

zfs receive - invalid stream format on receive with dedup processing enabled on send #432

dblacknc opened this issue Nov 2, 2011 · 2 comments
Milestone
0.6.0-rc7

Comments

@dblacknc
Copy link

dblacknc commented Nov 2, 2011

First - I'm running zfsonlinux 0.6.0-rc6, on CentOS 6.0 x86_64.

OpenSolaris 10 snv_137 machine does a zfs send -DRp of a filesystem containing multiple snapshots. This is a replication package, with dedup processing enabled on the stream but not necessarily the filesystem itself. (Doesn't seem to matter.)

I'm receiving on zfsonlinux. The first snapshot is created, then the receive aborts with "invalid backup format", I think it is.

I can restart the transfer at the snapshot where it aborted and it will transfer one more snapshot, then again stop.

Removing the -D flag on send avoids the above behavior; I can successfully transfer the entire filesystem with all snapshots. This is an apparent issue with zfsonlinux, because I have successfully replicated several filesystems including the -D flag, to a Solaris 11 Express machine.
@gunnarbeutner
Copy link
Contributor

Hi dblacknc,

I believe this is a duplicate of #372 - could you try and see if the patch for that bug fixes your problem?

Regards,
Gunnar

@dblacknc
Copy link
Author

dblacknc commented Nov 2, 2011

It does look that way - sorry I missed #372. Will try the patch and report back.

@dblacknc dblacknc closed this as completed Nov 3, 2011
@kernelOfTruth kernelOfTruth mentioned this issue Jan 16, 2016
Closed
ahrens added a commit to ahrens/zfs that referenced this issue Sep 9, 2021
@ahrens
type checking for {Object,Block}BasedLogPhys (openzfs#432)
7bb68c7 
We can have additional type safety by using generics and PhantomData to associate the type of the ObjectBasedLogPhys and BlockBasedLogPhys with the type of the entries stored in it. This prevents us from loading an ObjectBasedLogPhys that stores one type of entries into a ObjectBasedLog that stores a different type of entry (same for BlockBasedLog).
sdimitro added a commit to sdimitro/zfs that referenced this issue May 23, 2022
@sdimitro
DLPX-81156 zettacache discovery fails on duplicate device entries (op…
ed656c8 
…enzfs#432)

Use `/dev/disk/by-path/` instead of `/dev/disk/by-id` as the zcachedb
default cache directory. The former doesn't have duplicate symlinks to
the same cache device.

Furthermore, even if the cache directory specified by the user does have
duplicate entries, then uniquify them.

Side-Change: Remove `-c` option from zcachedb and fix the UX for
`superblocks` command to be like this:
```
$ zcachedb superblocks /dev/sdb
```
instead of this:
```
$ zcachedb -c /dev/sdb superblocks
```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
0.6.0-rc7
Development

No branches or pull requests
2 participants
@gunnarbeutner @dblacknc