[zfs-discuss] zfs snapshot and zil

[Justin Skariah]

Hello Everybody,

I have a doubt regarding zfs snapshots. When I take a zfs snapshot does it commit to the disk after logging in ZIL or it remains in ZIL till a DMU transaction group commit happens.

If it remains in ZIL, is it possible to commit it to the disk at that time.
will the following command help in getting the above output.

zfs set sync=always ZFS_ZPOOL
zfs snapshot ***@SNAP_NAME

Thanks in advance.

Regards,
Justin Skariah.

[Edward Ned Harvey]

Post by Justin Skariah
I have a doubt regarding zfs snapshots. When I take a zfs snapshot does it
commit to the disk after logging in ZIL or it remains in ZIL till a DMU
transaction group commit happens.

At all times, there exists in RAM, a data structure that represents the
present state of the filesystem. As processes send writes to the
filesystem, those writes occur in RAM, and according to schedule, they get
committed to disk as a TXG.

If a process writes in SYNC mode, then the process cannot continue until
after the write is committed to nonvolatile storage. So ZFS immediately
records this intent in the ZIL, and then the SYNC mode write can exist in
RAM, waiting for a TXG just like all the other ASYNC mode writes. Meanwhile
the process has been freed up to continue processing.

When you make a snapshot, the parent node of the filesystem is copied and
preserved. It's an instant operation. I don' t know if this is instantly
committed to disk, or if it's allowed to be buffered and written in the next
TXG.

Your question didn't really make any sense, so hopefully I've answered it.

[Edward Ned Harvey]

My question was does snapshot instantly get committed to disk or its
kept in memory till next TXG. If its kept in memory till next TXG will
sync=always solve this problem.

So, *if* it's committed in the next TXG, why do you care and why are you
calling it a problem?

I don't know the answer to the question, but either way, I don't consider it
a problem.

[Gmail]

Its a problem if I am going to take a backup of the disk on which ZFS
resides, for eg: if its a enterprise storage. So I need to know exactly
when the snapshot gets committed to the disk so I can backup my disk.

Regards,
Justin Skariah.

Post by Edward Ned Harvey

My question was does snapshot instantly get committed to disk or its
kept in memory till next TXG. If its kept in memory till next TXG will
sync=always solve this problem.

So, *if* it's committed in the next TXG, why do you care and why are you
calling it a problem?
I don't know the answer to the question, but either way, I don't consider it
a problem.

[Dmitry G. Kozhinov]

I need to know exactly when the snapshot gets committed to the disk so I can backup my disk.

You access your disk (for backup purpose) via operating system. The OS will show you the disk in the logical state in which it got after all write operations, regardless of whether they were physically completed or not.

[Edward Ned Harvey]

Post by Gmail

I need to know exactly when the snapshot gets committed to the disk so I

can backup my disk.
You access your disk (for backup purpose) via operating system. The OS

will

Post by Gmail
show you the disk in the logical state in which it got after all write

operations,

Post by Gmail
regardless of whether they were physically completed or not.

Dmitry, you've assumed too much - Justin might be correct.

If you backup your filesystem from inside the OS, then Dmitry is correct.
You don't have to worry about whether it's immediately synced or not,
because inside the OS, all access to the zpool will use the in-memory data
structures.

But if you have enterprise storage, and you're backing up your storage
through a 3rd party command issued to the storage controller at a level
below what ZFS sees... Then it's conceivable you might care about the
snapshot operation being asynchronous versus synchronous.

So, Justin, a few more comments:

Suppose you issue "zfs snapshot" command, and suppose it's async. Meaning
it's not yet written to disk. And you then "snapshot" the storage using an
enterprise low-level storage device command. Then your hardware snapshot
will not include the zfs snapshot inside of it, but maybe you don't care.
Under no circumstance does ZFS write an inconsistent filesystem to disk,
which means, any hardware snapshot you create will service functionally just
as well as the software snapshot. If you are doing a hardware snapshot,
then the only reason you care about zfs snapshot being sync or async... If
you want a convenient label inside your hardware snapshot to indicate when
it was taken.

So, all that being said... Do you still care?

I am surprised nobody has actually answered the question yet. You're asking
in the right place. Somebody here definitely knows the answer. When you
"zfs snapshot" a filesystem, is that a sync operation, or async? Does the
snapshot creation happen in ZIL before it gets flushed to main storage?

[Gmail]

Hi Edward,

My question was does snapshot instantly get committed to disk or its
kept in memory till next TXG. If its kept in memory till next TXG will
sync=always solve this problem.

Regards,
Justin Skariah.

Post by Edward Ned Harvey

Post by Justin Skariah
I have a doubt regarding zfs snapshots. When I take a zfs snapshot does it
commit to the disk after logging in ZIL or it remains in ZIL till a DMU
transaction group commit happens.

At all times, there exists in RAM, a data structure that represents the
present state of the filesystem. As processes send writes to the
filesystem, those writes occur in RAM, and according to schedule, they get
committed to disk as a TXG.
If a process writes in SYNC mode, then the process cannot continue until
after the write is committed to nonvolatile storage. So ZFS immediately
records this intent in the ZIL, and then the SYNC mode write can exist in
RAM, waiting for a TXG just like all the other ASYNC mode writes. Meanwhile
the process has been freed up to continue processing.
When you make a snapshot, the parent node of the filesystem is copied and
preserved. It's an instant operation. I don' t know if this is instantly
committed to disk, or if it's allowed to be buffered and written in the next
TXG.
Your question didn't really make any sense, so hopefully I've answered it.