Date: Thu, 23 Nov 2023 05:14:13 -0700 From: "Edward Sanford Sutton, III" <mirror176@hotmail.com> To: questions@freebsd.org Subject: Re: I am sick and tired of the poor quality of documentation on FreeBSD Message-ID: <CO1PR11MB4770A286B28951A530BDC941E6B9A@CO1PR11MB4770.namprd11.prod.outlook.com> In-Reply-To: <3694566.vYMqPgikMl@ravel> References: <NjnQuB8--R-9@tutanota.com> <1781224.E1bnfOMcs6@ravel> <CO1PR11MB4770488805D0DF48B314990AE6B9A@CO1PR11MB4770.namprd11.prod.outlook.com> <3694566.vYMqPgikMl@ravel>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11/23/23 03:56, Olivier Certner wrote: >> 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. It would apply to all datasets from that receive command but I doubt it would be remembered between receives but have not tested; the dataset already knows what was on the stream before receive and knows that it has a local override vs what the incoming stream originally had so I'd imagine they could 'guess' at maintaining it but have not heard that it is done. Could be quickly tested by making a dataset, set a desired property, copy/write 1 file in it, then test sending it, then a later snapshot with a revision of it with first receive overriding incoming properties and second one not doing so. If it seems to work then it would be worth a 3rd send where you test if a modified property is still overridden or not. Doing so would then have you know what to expect. My send+receive is executed by copying from a file so that I do not have to try to remember the command, let alone the flags and I won't likely make any typo. I really don't want to read a manpage on every use of a command due to forgetting options meanings and to try to avoid forgetting desired options entirely. I have similar files for executing poudriere, updating from source, performing disk cleanup, dealing with snapshots, etc. I usually copy+paste from them to tweak things like how many jobs run or skip certain commands/steps but some are scripts I can execute directly. Backups and testing are great to have that for to make sure they stay consistent and its good for restoring data as that is the point in time where mistakes are likely more dangerous and you many be stressed/distracted by the fact that you even need to perform that step. >> 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'). Correct. I have only used send+receive both executed on the same machine so that didn't come up for me. If data throughput is tight, you can also manually pipe a send through an external compressor which can likely get a better compression ratio too; such external compression is unrelated to -c and must be manually decompressed before the zfs receive step. Encrypted streams interfere with having control such as compressing too. >> 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. >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CO1PR11MB4770A286B28951A530BDC941E6B9A>