ZFS ZFS and sync property

[CyberCr33p]

Hello,

I have a server that I use to store backups using rsync. The server has 2x12TB HDDs. I would like to improve the write performance disabling sync for zroot/home/backup dataset. In my case (no databases - just files) the only disadvantage is that if a power outage happens during the rsync, then I will lose few seconds data?

Man page:

sync=standard|always|disabled

Controls the behavior of synchronous requests (e.g. fsync, O_DSYNC).

standard is the POSIX-specified behavior of ensuring all synchronous
requests are written to stable storage and all devices are flushed to
ensure data is not cached by device controllers (this is the default).

always causes every file system transaction to be written and flushed
before its system call returns. This has a large performance penalty.

disabled disables synchronous requests. File system transactions are
only committed to stable storage periodically. This option will give
the highest performance. However, it is very dangerous as ZFS would be
ignoring the synchronous transaction demands of applications such as
databases or NFS. Administrators should only use this option when the
risks are understood.

 

[cracauer@]

This does nothing unless the application that writes uses fsync or friends.

How do you write your backups?

 

[CyberCr33p]

I use rsync over ssh from other servers to write data to this server.

 

[CyberCr33p]

Also as I use RAID-1 I am thinking to change redundant_metadata=most. Any thoughts about this?

 

[cracauer@]

I use rsync over ssh from other servers to write data to this server.

rsync never issues fsync(2) system calls, so it makes no difference to set sync to disabled in the target ZFS.

I don't think redundant_metadata will make a noticeable difference either.

 

[covacat]

look at --inplace rsync option especially if you have snapshots on the rsync destination dataset
if most of the file copied are new probably will have no effect

 

[Eric A. Borisch]

rsync never issues fsync(2) system calls

Unless you pass --fsync (since 3.2.4). Documented in rsync(1), too.

 

[CyberCr33p]

look at --inplace rsync option especially if you have snapshots on the rsync destination dataset
if most of the file copied are new probably will have no effect

In each server I have local backups done with rsync in a zroot/home/backup dataset (and I keep 30 daily snapshots). Then I rsync via ssh the files to a remote backup server (and I keep 12 weekly snapshots). So --inplace will make snapshots use less space. Do you think I can use --inplace for local backups too? I read in man page that is dangerous: "WARNING: you should not use this option to update files that are being accessed by others, so be careful when choosing to use this for a copy."

The files are related to websites (WordPress, Joomla, etc), so I am not sure how much --inplace will help because most files are new or not changed. Maybe it helps for some .sql files because when a new .sql replaces the old file part of the file is the same.

 

[covacat]

it's not a problem afaik if they are not accessed during the transfer
i use it to keep the remote snapshot sizes in check

 

[CyberCr33p]

Yes for the remote backup it shouldn't be a problem as the local backup is not touched during the remote rsync. But for the local rsync I think I should not enable it as someone or an application maybe alter the data of the original file.

 

[Eric A. Borisch]

Yes for the remote backup it shouldn't be a problem as the local backup is not touched during the remote rsync. But for the local rsync I think I should not enable it as someone or an application maybe alter the data of the original file.

This isn’t the impact of --inplace; it is only the backup copies (which hopefully aren’t being used / modified by applications/users) that get different treatment. (Rather than writing a new file and then replacing the original (in the backup) file, open the backup file, and update portions as needed “in-place”.)

 

[CyberCr33p]

So this is not dangerous in my case as the "backup" file (either the local or the remote) is not touched by user or application. And I will save some OPs and bandwidth on the mechanical HDDs. In some articles I read that for local (same system) rsync is recommened to combine --inplace and --whole-file. But man page says that --whole-file is already enabled if it's local transfer. Any thoughts on this?

 

[covacat]

no idea. i mostly moved from rsync to zfs send/receive. i still have one rsync script which is thru the network and just use inplace and im ok with it

 

[Eric A. Borisch]

So this is not dangerous in my case as the "backup" file (either the local or the remote) is not touched by user or application. And I will save some OPs and bandwidth on the mechanical HDDs. In some articles I read that for local (same system) rsync is recommened to combine --inplace and --whole-file. But man page says that --whole-file is already enabled if it's local transfer. Any thoughts on this?

Not if you’re trying to minimize snapshot space usage. I don’t recall if ZFS is smart enough to keep a block that gets re-written with identical content. Better to use --inplace without whole file to minimize freshly written (even if unchanged) data, I would think.