Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 18 May 2017 17:53:23 -0400
From:      Mark Saad <nonesuch@longcount.org>
To:        kc atgb <kisscoolandthegangbang@hotmail.fr>
Cc:        "freebsd-fs@freebsd.org" <freebsd-fs@freebsd.org>
Subject:   Re: Different size after zfs send receive
Message-ID:  <58A6B47B-2992-4BB8-A80E-44F74EAE93B2@longcount.org>
In-Reply-To: <DBXPR05MB157C1956B267EA6BE59F570A0E40@DBXPR05MB157.eurprd05.prod.outlook.com>
References:  <DBXPR05MB157C1956B267EA6BE59F570A0E40@DBXPR05MB157.eurprd05.prod.outlook.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Hi kc=20
  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 simp=
lified but imagine you store a file of 10gb on a raidz1 . The system splits t=
he file into smaller chunks; of say 1mb , and stores one extra chunk for eac=
h chunk that us striped around the raidz1 . Storing on a mirror is just writ=
e 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 .=20

Hope this helps .=20

---
Mark Saad | nonesuch@longcount.org

> On May 18, 2017, at 3:36 PM, kc atgb <kisscoolandthegangbang@hotmail.fr> w=
rote:
>=20
> Hi,
>=20
> Some days ago I had a need to backup my current pool and restore it after p=
ool destroy and create.=20
>=20
> 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 j=
ust one
> sata port left I can use to plug a disk).=20
>=20
> The whole process of backup and restore went well as I can say. But lookin=
g at the size reported by zfs list make me a little bit curious.=20
>=20
> storage/datas/ISO                                                        3=
5420869824  381747995136    35420726976  /datas/ISO
> storage/datas/ISO@backup_send                                             =
    142848             -    35420726976  -
> storage/datas/ISO@backup_sync                                             =
         0             -    35420726976  -
>=20
> b1/datas/ISO                                                        354393=
08800  2176300351488    35439210496  /datas/ISO
> b1/datas/ISO@backup_send                                                  9=
8304              -    35439210496  -
> b1/datas/ISO@backup_sync                                                  =
    0              -    35439210496  -
>=20
> b2/datas/ISO                                                        354393=
08800  2176298991616    35439210496  /datas/ISO
> b2/datas/ISO@backup_send                                                  9=
8304              -    35439210496  -
> b2/datas/ISO@backup_sync                                                  =
    0              -    35439210496  -
>=20
> storage/datas/ISO                                                        3=
5421024576  381303470016    35420715072  /datas/ISO
> storage/datas/ISO@backup_send                                             =
    142848             -    35420715072  -
> storage/datas/ISO@backup_sync                                             =
     11904             -    35420715072  -
>=20
>=20
> storage/usrobj                                                            5=
819085888  381747995136     5816276544  legacy
> storage/usrobj@create                                                     =
    166656             -         214272  -
> storage/usrobj@backup_send                                                =
   2642688             -     5816228928  -
> storage/usrobj@backup_sync                                                =
         0             -     5816276544  -
>=20
> b1/usrobj                                                            56750=
81728  2176300351488     5673222144  legacy
> b1/usrobj@create                                                         1=
14688              -         147456  -
> b1/usrobj@backup_send                                                   17=
44896              -     5673222144  -
> b1/usrobj@backup_sync                                                     =
    0              -     5673222144  -
>=20
> b2/usrobj                                                            56751=
88224  2176298991616     5673328640  legacy
> b2/usrobj@create                                                         1=
14688              -         147456  -
> b2/usrobj@backup_send                                                   17=
44896              -     5673328640  -
> b2/usrobj@backup_sync                                                     =
    0              -     5673328640  -
>=20
> storage/usrobj                                                            5=
820359616  381303470016     5815098048  legacy
> storage/usrobj@create                                                     =
    166656             -         214272  -
> storage/usrobj@backup_send                                                =
   2535552             -     5815098048  -
> storage/usrobj@backup_sync                                                =
     11904             -     5815098048  -
>=20
> 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 h=
ave
> nearly all my datasets in the same situation (those with fixed data that h=
ave not changed between the beginning of the process and now). backup1 and b=
ackup2
> are identical disks with exactly the same configurations and have differen=
t numbers. I used the same commands for all my transfers except the name of t=
he
> destination pool.=20
>=20
> So, I wonder what can cause these differences ? Is it something I have to w=
orry about ? Can I consider this as a normal behavior ?=20
>=20
> Thanks for your enlightments,
> K.
> _______________________________________________
> freebsd-fs@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?58A6B47B-2992-4BB8-A80E-44F74EAE93B2>