How do snapshots work?

[finos]

im commin from this thread, and since its locked and i cannt reply there to ask , im making a new one.

i want a clarification on how snapshots work.
Lets say i have ZFS array of some amount , and i delete a handful of files after making a snapshot , reverting to said snapshot will make the files return intact ?

can someone clarify this a bit better cause it seems im at a los (thankfully not a data-loss)

 

[Arwen]

...
Lets say i have ZFS array of some amount , and i delete a handful of files after making a snapshot , reverting to said snapshot will make the files return intact ?
...

Yes.

ZFS is COW, Copy On Write. This means that ZFS can get snapshots more or less free, (from most overhead, not space).

Whence a snapshot is taken, any file referenced by the snapshot is frozen in time at the time the snapshot was taken. And new write is only reflected in the parent dataset. Anything common between them, parent dataset and snapshot, is reference by both.

In the case of a file update or deletion, the snapshot is still "frozen" in time, the parent dataset reflects the change as normal. But, the blocks for the file update or deletion are not freed up in the pool. The snapshot still "owns" a reference to them.

In some cases, you can consider snapshots hard-links until written, then COW.


Other snapshot schemes involve transaction log buffers. If I understand Linux LVM's snapshots, you create a holding space for all changes to a LVM volume, (which can contain a Linux file system). This holding space / snapshot has to be large enough to handle all the changes, writes, file updates and deletions, during the life of the snapshot. Or eventually the file system becomes frozen / locked.

Most other snapshot schemes, VMWare and Linux, are not designed to live for ever. They are designed for hours to days, not weeks or more. You MAY be able to get one to last weeks or months, but it may require lots more "holding space" than you might expect.


Worse, whence you are done with a VMWare or Linux LVM snapshot, and you delete the snapshot, all the pending writes have to be dumped back to the original file system. The more data to dump, the longer it takes. As in days to remove a snapshot that lived "too long". This can slow a server down to the point it is unusable.

ZFS did have a problem more than 10 years ago in removing snapshots. Basically to remove a ZFS snapshot, (or dataset), requires updating the free blocks list, (or anything not in use by another snapshot or dataset). Initially Sun Microsystems, (which wrote the original ZFS), did this all at once. Any interruption of that process, and it would have to start from scratch. Very painful.

OpenZFS added "async destroy" feature as one of it's first new features that Sun / Oracle ZFS did not have. This allowed a ZFS snapshot or dataset destroy happen in parts. And if interrupted, resume where it left off.


Hope this answers some of you ZFS snapshot questions.

 

[Whattteva]

Lets say i have ZFS array of some amount , and i delete a handful of files after making a snapshot , reverting to said snapshot will make the files return intact ?

Yes, it will return verbatim. You can observe this clearly when you make a snapshot, delete non-trivial amount of files (say 10 GB or so) and check your space usage after the deletion. You won't get back that 10 GB of space so long as that snapshot exists.

 

[sretalla]

I've always liked the way Ars Technica's explanation of that concept works on page 3 of this article:

ZFS 101—Understanding ZFS storage and performance

Learn to get the most out of your ZFS filesystem in our new series on storage fundamentals.

arstechnica.com

 

[finos]

Thank you all for taking the time to respond :

Yes.

ZFS is COW, Copy On Write. This means that ZFS can get snapshots more or less free, (from most overhead, not space).

Whence a snapshot is taken, any file referenced by the snapshot is frozen in time at the time the snapshot was taken. And new write is only reflected in the parent dataset. Anything common between them, parent dataset and snapshot, is reference by both.

In the case of a file update or deletion, the snapshot is still "frozen" in time, the parent dataset reflects the change as normal. But, the blocks for the file update or deletion are not freed up in the pool. The snapshot still "owns" a reference to them.

In some cases, you can consider snapshots hard-links until written, then COW.


Other snapshot schemes involve transaction log buffers. If I understand Linux LVM's snapshots, you create a holding space for all changes to a LVM volume, (which can contain a Linux file system). This holding space / snapshot has to be large enough to handle all the changes, writes, file updates and deletions, during the life of the snapshot. Or eventually the file system becomes frozen / locked.

Most other snapshot schemes, VMWare and Linux, are not designed to live for ever. They are designed for hours to days, not weeks or more. You MAY be able to get one to last weeks or months, but it may require lots more "holding space" than you might expect.


Worse, whence you are done with a VMWare or Linux LVM snapshot, and you delete the snapshot, all the pending writes have to be dumped back to the original file system. The more data to dump, the longer it takes. As in days to remove a snapshot that lived "too long". This can slow a server down to the point it is unusable.

ZFS did have a problem more than 10 years ago in removing snapshots. Basically to remove a ZFS snapshot, (or dataset), requires updating the free blocks list, (or anything not in use by another snapshot or dataset). Initially Sun Microsystems, (which wrote the original ZFS), did this all at once. Any interruption of that process, and it would have to start from scratch. Very painful.

OpenZFS added "async destroy" feature as one of it's first new features that Sun / Oracle ZFS did not have. This allowed a ZFS snapshot or dataset destroy happen in parts. And if interrupted, resume where it left off.


Hope this answers some of you ZFS snapshot questions.

Yes, it will return verbatim. You can observe this clearly when you make a snapshot, delete non-trivial amount of files (say 10 GB or so) and check your space usage after the deletion. You won't get back that 10 GB of space so long as that snapshot exists.

Actualy this would be my follow up question , i finished my dedup operation , cleaned up a bunch of files did and a scrub (just for good measure) even though via SMB and FTP i see more free space , the counters in the dashboard did not change at all so i was confused , this one is a good clarification

I've always liked the way Ars Technica's explanation of that concept works on page 3 of this article:

ZFS 101—Understanding ZFS storage and performance

Learn to get the most out of your ZFS filesystem in our new series on storage fundamentals.

arstechnica.com

i will check this one out.