Different size after zfs send receive

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Different size after zfs send receive

kc atgb
Hi,

Some days ago I had a need to backup my current pool and restore it after pool destroy and create.

The pool in my home server is a raidz1 with 4 disks. To backup this pool I grabbed two 4TB disks (single disk pools) to have a double backup (I have just one
sata port left I can use to plug a disk).

The whole process of backup and restore went well as I can say. But looking at the size reported by zfs list make me a little bit curious.

storage/datas/ISO                                                        35420869824  381747995136    35420726976  /datas/ISO
storage/datas/ISO@backup_send                                                 142848             -    35420726976  -
storage/datas/ISO@backup_sync                                                      0             -    35420726976  -

b1/datas/ISO                                                        35439308800  2176300351488    35439210496  /datas/ISO
b1/datas/ISO@backup_send                                                  98304              -    35439210496  -
b1/datas/ISO@backup_sync                                                      0              -    35439210496  -

b2/datas/ISO                                                        35439308800  2176298991616    35439210496  /datas/ISO
b2/datas/ISO@backup_send                                                  98304              -    35439210496  -
b2/datas/ISO@backup_sync                                                      0              -    35439210496  -

storage/datas/ISO                                                        35421024576  381303470016    35420715072  /datas/ISO
storage/datas/ISO@backup_send                                                 142848             -    35420715072  -
storage/datas/ISO@backup_sync                                                  11904             -    35420715072  -


storage/usrobj                                                            5819085888  381747995136     5816276544  legacy
storage/usrobj@create                                                         166656             -         214272  -
storage/usrobj@backup_send                                                   2642688             -     5816228928  -
storage/usrobj@backup_sync                                                         0             -     5816276544  -

b1/usrobj                                                            5675081728  2176300351488     5673222144  legacy
b1/usrobj@create                                                         114688              -         147456  -
b1/usrobj@backup_send                                                   1744896              -     5673222144  -
b1/usrobj@backup_sync                                                         0              -     5673222144  -

b2/usrobj                                                            5675188224  2176298991616     5673328640  legacy
b2/usrobj@create                                                         114688              -         147456  -
b2/usrobj@backup_send                                                   1744896              -     5673328640  -
b2/usrobj@backup_sync                                                         0              -     5673328640  -

storage/usrobj                                                            5820359616  381303470016     5815098048  legacy
storage/usrobj@create                                                         166656             -         214272  -
storage/usrobj@backup_send                                                   2535552             -     5815098048  -
storage/usrobj@backup_sync                                                     11904             -     5815098048  -

As you can see the numbers are different for each pool (the initial raidz1, backup1 disk, backup2 disk and new raidz1). I mean in the USED column. I have
nearly all my datasets in the same situation (those with fixed data that have not changed between the beginning of the process and now). backup1 and backup2
are identical disks with exactly the same configurations and have different numbers. I used the same commands for all my transfers except the name of the
destination pool.

So, I wonder what can cause these differences ? Is it something I have to worry about ? Can I consider this as a normal behavior ?

Thanks for your enlightments,
K.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Different size after zfs send receive

Mark Saad-5
Hi kc
  This has to do with how data blocks are replicated when stored on a raidzN . Moving them to a mirror removes replicated blocks . This is way over simplified but imagine you store a file of 10gb on a raidz1 . The system splits the file into smaller chunks; of say 1mb , and stores one extra chunk for each chunk that us striped around the raidz1 . Storing on a mirror is just write the chunk once on each disk . However with a mirror since you only see 1/2 the number of disks you never see the extra chunks in the used field .

Hope this helps .

---
Mark Saad | [hidden email]

> On May 18, 2017, at 3:36 PM, kc atgb <[hidden email]> wrote:
>
> Hi,
>
> Some days ago I had a need to backup my current pool and restore it after pool destroy and create.
>
> The pool in my home server is a raidz1 with 4 disks. To backup this pool I grabbed two 4TB disks (single disk pools) to have a double backup (I have just one
> sata port left I can use to plug a disk).
>
> The whole process of backup and restore went well as I can say. But looking at the size reported by zfs list make me a little bit curious.
>
> storage/datas/ISO                                                        35420869824  381747995136    35420726976  /datas/ISO
> storage/datas/ISO@backup_send                                                 142848             -    35420726976  -
> storage/datas/ISO@backup_sync                                                      0             -    35420726976  -
>
> b1/datas/ISO                                                        35439308800  2176300351488    35439210496  /datas/ISO
> b1/datas/ISO@backup_send                                                  98304              -    35439210496  -
> b1/datas/ISO@backup_sync                                                      0              -    35439210496  -
>
> b2/datas/ISO                                                        35439308800  2176298991616    35439210496  /datas/ISO
> b2/datas/ISO@backup_send                                                  98304              -    35439210496  -
> b2/datas/ISO@backup_sync                                                      0              -    35439210496  -
>
> storage/datas/ISO                                                        35421024576  381303470016    35420715072  /datas/ISO
> storage/datas/ISO@backup_send                                                 142848             -    35420715072  -
> storage/datas/ISO@backup_sync                                                  11904             -    35420715072  -
>
>
> storage/usrobj                                                            5819085888  381747995136     5816276544  legacy
> storage/usrobj@create                                                         166656             -         214272  -
> storage/usrobj@backup_send                                                   2642688             -     5816228928  -
> storage/usrobj@backup_sync                                                         0             -     5816276544  -
>
> b1/usrobj                                                            5675081728  2176300351488     5673222144  legacy
> b1/usrobj@create                                                         114688              -         147456  -
> b1/usrobj@backup_send                                                   1744896              -     5673222144  -
> b1/usrobj@backup_sync                                                         0              -     5673222144  -
>
> b2/usrobj                                                            5675188224  2176298991616     5673328640  legacy
> b2/usrobj@create                                                         114688              -         147456  -
> b2/usrobj@backup_send                                                   1744896              -     5673328640  -
> b2/usrobj@backup_sync                                                         0              -     5673328640  -
>
> storage/usrobj                                                            5820359616  381303470016     5815098048  legacy
> storage/usrobj@create                                                         166656             -         214272  -
> storage/usrobj@backup_send                                                   2535552             -     5815098048  -
> storage/usrobj@backup_sync                                                     11904             -     5815098048  -
>
> As you can see the numbers are different for each pool (the initial raidz1, backup1 disk, backup2 disk and new raidz1). I mean in the USED column. I have
> nearly all my datasets in the same situation (those with fixed data that have not changed between the beginning of the process and now). backup1 and backup2
> are identical disks with exactly the same configurations and have different numbers. I used the same commands for all my transfers except the name of the
> destination pool.
>
> So, I wonder what can cause these differences ? Is it something I have to worry about ? Can I consider this as a normal behavior ?
>
> Thanks for your enlightments,
> K.
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "[hidden email]"
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Different size after zfs send receive

kc atgb
Le Thu, 18 May 2017 21:53:23 +0000,
Mark Saad <[hidden email]> a écrit :

Hi,

I see what you are talking about I thing. You refer to "raid" splitting, right ? In this case this is something in the "internals" of the raid system. Isn't
zfs list suppose to report raw data sizes (without metadata, checksums, ... ) ?

I don't really think it is related to what I'm refering.

Look, for the same pool configuration (one 4 disks raidz1 vdev) with the same disks and the same data, it reports for storage/usrobj
5819085888 before backup and
5820359616 after restore to the recreated pool.

Even for pools with one single disk vdev (again same disks, same configuration, same data as above...) for the same dataset
5675081728 in backup1 disk and
5675188224 in backup2

The difference isn't so big but the numbers differ and I would imagine numbers to be the same.

K.

> Hi kc
>   This has to do with how data blocks are replicated when stored on a raidzN . Moving them to a mirror removes replicated blocks . This is way over
> simplified but imagine you store a file of 10gb on a raidz1 . The system splits the file into smaller chunks; of say 1mb , and stores one extra chunk for
> each chunk that us striped around the raidz1 . Storing on a mirror is just write the chunk once on each disk . However with a mirror since you only see 1/2
> the number of disks you never see the extra chunks in the used field .
>
> Hope this helps .
>
> ---
> Mark Saad | [hidden email]
>
> > On May 18, 2017, at 3:36 PM, kc atgb <[hidden email]> wrote:
> >
> > Hi,
> >
> > Some days ago I had a need to backup my current pool and restore it after pool destroy and create.
> >
> > The pool in my home server is a raidz1 with 4 disks. To backup this pool I grabbed two 4TB disks (single disk pools) to have a double backup (I have just
> > one sata port left I can use to plug a disk).
> >
> > The whole process of backup and restore went well as I can say. But looking at the size reported by zfs list make me a little bit curious.
> >
> > storage/datas/ISO                                                        35420869824  381747995136    35420726976  /datas/ISO
> > storage/datas/ISO@backup_send                                                 142848             -    35420726976  -
> > storage/datas/ISO@backup_sync                                                      0             -    35420726976  -
> >
> > b1/datas/ISO                                                        35439308800  2176300351488    35439210496  /datas/ISO
> > b1/datas/ISO@backup_send                                                  98304              -    35439210496  -
> > b1/datas/ISO@backup_sync                                                      0              -    35439210496  -
> >
> > b2/datas/ISO                                                        35439308800  2176298991616    35439210496  /datas/ISO
> > b2/datas/ISO@backup_send                                                  98304              -    35439210496  -
> > b2/datas/ISO@backup_sync                                                      0              -    35439210496  -
> >
> > storage/datas/ISO                                                        35421024576  381303470016    35420715072  /datas/ISO
> > storage/datas/ISO@backup_send                                                 142848             -    35420715072  -
> > storage/datas/ISO@backup_sync                                                  11904             -    35420715072  -
> >
> >
> > storage/usrobj                                                            5819085888  381747995136     5816276544  legacy
> > storage/usrobj@create                                                         166656             -         214272  -
> > storage/usrobj@backup_send                                                   2642688             -     5816228928  -
> > storage/usrobj@backup_sync                                                         0             -     5816276544  -
> >
> > b1/usrobj                                                            5675081728  2176300351488     5673222144  legacy
> > b1/usrobj@create                                                         114688              -         147456  -
> > b1/usrobj@backup_send                                                   1744896              -     5673222144  -
> > b1/usrobj@backup_sync                                                         0              -     5673222144  -
> >
> > b2/usrobj                                                            5675188224  2176298991616     5673328640  legacy
> > b2/usrobj@create                                                         114688              -         147456  -
> > b2/usrobj@backup_send                                                   1744896              -     5673328640  -
> > b2/usrobj@backup_sync                                                         0              -     5673328640  -
> >
> > storage/usrobj                                                            5820359616  381303470016     5815098048  legacy
> > storage/usrobj@create                                                         166656             -         214272  -
> > storage/usrobj@backup_send                                                   2535552             -     5815098048  -
> > storage/usrobj@backup_sync                                                     11904             -     5815098048  -
> >
> > As you can see the numbers are different for each pool (the initial raidz1, backup1 disk, backup2 disk and new raidz1). I mean in the USED column. I have
> > nearly all my datasets in the same situation (those with fixed data that have not changed between the beginning of the process and now). backup1 and backup2
> > are identical disks with exactly the same configurations and have different numbers. I used the same commands for all my transfers except the name of the
> > destination pool.
> >
> > So, I wonder what can cause these differences ? Is it something I have to worry about ? Can I consider this as a normal behavior ?
> >
> > Thanks for your enlightments,
> > K.
> > _______________________________________________
> > [hidden email] mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-fs
> > To unsubscribe, send any mail to "[hidden email]"
>

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"