Re: I am sick and tired of the poor quality of documentation on FreeBSD

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.
>