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 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 | nonesuch@longcount.org > On May 18, 2017, at 3:36 PM, kc atgb <kisscoolandthegangbang@hotmail.fr> 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. > _______________________________________________ > 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>