Date: Thu, 23 Nov 2023 11:56:34 +0100 From: Olivier Certner <olivier.freebsd@free.fr> To: questions@freebsd.org Subject: Re: I am sick and tired of the poor quality of documentation on FreeBSD Message-ID: <3694566.vYMqPgikMl@ravel> In-Reply-To: <CO1PR11MB4770488805D0DF48B314990AE6B9A@CO1PR11MB4770.namprd11.prod.outlook.com> References: <NjnQuB8--R-9@tutanota.com> <1781224.E1bnfOMcs6@ravel> <CO1PR11MB4770488805D0DF48B314990AE6B9A@CO1PR11MB4770.namprd11.prod.outlook.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Rather than hope I will do an export/import dance of a backup drive with > the flag, I prefer to use -x or -o to change properties to a different > state while they are on the backup drive before they have a chance to > take effect. I hadn't caught up with using -x and -o when receiving. That said, are these settings persistent on receiving new streams produced by -R? Because if they are not, they don't provide any additional foot-shooting protection, since you have to remember to use -o at each receive. > This also works nice to set different compression settings, Just for the record, this works only if you don't send compressed blocks in streams (triggered by using -c with 'zfs send'). > decide if atime should be enabled or not, and even put the backup into a > read only state automatically. Keeping settings like refreservation from > being overridden just because a backup seems important instead of just > an afterthought since the two disks are likely different sizes with > different needs. These 'overrides' are noted so that zfs inherit -S can > get you back on track if wanting to start using the data in place with > original properties or -b for when data gets sent the other way. Seems very nice. Thanks for making me aware of these "novelties". Regards. -- Olivier Certner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3694566.vYMqPgikMl>