Replies: 2 comments 1 reply
-
|
Space varying isn't totally unbelievable even with raw replication - some metadata is going to vary in size based on what wrote it when and to what, and notably, the metadata for userobj_accounting isn't, I believe, going to replicate, it's going to be regenerated on mount, so those would be my blind guesses about the USED delta on the live FS. I've got no guesses about showing a substantial USED on the snapshot when you didn't have a delta between them other than a bug, but I've not heard of one doing that, and I don't have any good guesses about how it might occur. |
Beta Was this translation helpful? Give feedback.
-
|
It would be nice to see the full list. The USED part for the snapshot is
used exclusively by this snapshot. If you have two snapshots which are very
close, both of them will show USED ~0 as the data is actually shared
between them and no exclusive part. The USED column for a snapshot is the
amount of data you will free when deleting just this snapshot.
…On Mon, Mar 14, 2022 at 6:45 PM akandi ***@***.***> wrote:
I have a few questions about some things I observed during a recent raw
replication of an encrypted dataset. So far I don't have any data on the
pool that I don't have backed up somewhere else, but I'm about to leave
this state by using the pool to temporarily hold my laptop's data while I
reinstall the OS. The recent bug reports about encrypted datasets and raw
replication make me a bit queasy. I didn't observe any data corruption,
only some unexpected numbers that might be perfectly normal. I'm not a ZFS
expert, but I'm sure someone here can give me an insight. (My ZFS versions
are zfs-0.8.3-1ubuntu12.13 and zfs-kmod-2.0.6-1ubuntu2).
I have one encrypted dataset on a pool (let's call it oldpool/fs). I
created a snapshot ***@***.*** I then proceeded to replicate
this snapshot to a new dataset on a different pool using raw replication
mode (zfs send -w ***@***.*** | zfs recv newpool/fs). After the
replication completed, I looked at the sizes used. I don't remember all
numbers, I'll just fill in those that surprised me:
NAME USED
oldpool 2.85T
oldpool/fs 2.85T
***@***.*** 0
newpool 2.83T
newpool/fs 2.83T
***@***.*** 1.92T
The first thing that surprised me was that the new dataset took up less
space than the old one. The other thing was the size of the baseline
snapshot in the newpool, which I assumed would have had to be 0. I
considered an rsync -c of all the data from oldpool/fs to newpool/fs (which
would have given me absolute trust that the data in the datasets was
equal), but I didn't want to wait for it to complete. In the end, I just
verified that the number of files was equal on the old and new dataset and
I also did a zfs diff ***@***.*** newpool/fs, which returned an
empty result (i.e. all equal, I guess). I then deleted the
***@***.*** snapshot and recreated it to get a baseline snapshot
of 0 size. Since then I destroyed the oldpool (since I needed the disk and
I have all the data backed up elsewhere).
—
Reply to this email directly, view it on GitHub
<#13211>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABXQ6HIGQI7O7VBVPHTQBE3U73VCPANCNFSM5QUWCANA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Actually, this is the full list. "baseline" was the only snapshot. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I have a few questions about some things I observed during a recent raw replication of an encrypted dataset. So far I don't have any data on the pool that I don't have backed up somewhere else, but I'm about to leave this state by using the pool to temporarily hold my laptop's data while I reinstall the OS. The recent bug reports about encrypted datasets and raw replication make me a bit queasy. I didn't observe any data corruption, only some unexpected numbers that might be perfectly normal. I'm not a ZFS expert, but I'm sure someone here can give me an insight. (My ZFS versions are zfs-0.8.3-1ubuntu12.13 and zfs-kmod-2.0.6-1ubuntu2).
I have one encrypted dataset on a pool (let's call it oldpool/fs). I created a snapshot oldpool/fs@baseline. I then proceeded to replicate this snapshot to a new dataset on a different pool using raw replication mode (
zfs send -w oldpool/fs@baseline | zfs recv newpool/fs). After the replication completed, I looked at the sizes used. I don't remember all numbers, I'll just fill in those that surprised me:The first thing that surprised me was that the new dataset took up less space than the old one. The other thing was the size of the baseline snapshot in the newpool, which I assumed would have had to be 0. I considered an rsync -c of all the data from oldpool/fs to newpool/fs (which would have given me absolute trust that the data in the datasets was equal), but I didn't want to wait for it to complete. In the end, I just verified that the number of files was equal on the old and new dataset and I also did a
zfs diff newpool/fs@baseline newpool/fs, which returned an empty result (i.e. all equal, I guess). I then deleted the newpool/fs@baseline snapshot and recreated it to get a baseline snapshot of 0 size. Since then I destroyed the oldpool (since I needed the disk and I have all the data backed up elsewhere).Beta Was this translation helpful? Give feedback.
All reactions