ZFS Snapshots

[joobie]

Hi Guys,

I have two FreeNAS boxes replicating to each other. I have a few questions about snapshots that i'm struggling to find out.

1. What does the Used column in the ZFS Snapshots tab represent?
2. What does the Refer column in the ZFS Snapshots tab represent?
3. How can I determine the Complete size of a Snapshot (inclusive of all child snapshots - to make it a full image)?
4. How can I determine the Delta size of a Snapshot (just the size of the delta, not including any other snapshots which would be needed to make the full image)?


Thanks Guys,

joo

 

[joobie]

bump..

 

[joobie]

fundamental Q no? bump..

 

[fracai]

Yeah, pretty basic questions that you should be able to answer with some basic searching.

Essentially, used is how much data is unique to a dataset, while refer is how much total data is in that dataset.
So the complete size would be the referenced size (you could also check this with 'du') and the delta is "Used". Be careful though, "Used" will report zero if the data in that snapshot is overlapped by any one or many other snapshots / datasets. In other words, it's possible to have three snapshots that all report 0 Used, then delete one of the snapshots and have the other two both increase in reported Used.

 

[joobie]

Hi Fracai,

Thanks for the response. I did try searching for information on this - the documentation does not cover it (or maybe I missed it?).

The used column doesn't add up to what i'm seeing.
I wrote a script to pull the total in byte count from the FreeNAS Pull box on a nightly basis. Yesterday I saw 30GB transferred to the FreeNAS Pull based on netstat and when I go into ZFS Snapshots, I can see all the snapshots transferred over from last night - but the used column on all the snapshots are 0.

Note, there are no newer snapshots on the FreeNAS Pull box than what was sent to the box from last night to skew the Used figure.

Cheers, joo

 

[fracai]

USED isn't reliable for determining "consumed" space. For example:

1) Create file A as 100k
2) Create file B as 200k
3) Create snapshot-1
4) Create file C as 300k
5) Create snapshot-2
6) Delete file A
7) Create snapshot-3

snapshot-1 contains A and B
snapshot-2 contains A, B, and C
snapshot-3 contains B and C

The USED column for all three will be zero because there is no data that is unique to a single snapshot.

8) Delete snapshot-2

snapshot-1 contains A and B, USED is 100k
snapshot-3 contains B and C, USED is 300k

USED is only the unique data.

If you want to see which files have been added, deleted, or modified use 'zfs diff'

 

[joobie]

Our volumes are all used as iSCSI targets.

2 x Windows
1 x CentOS

These servers day-to-day run a Mail Server, Web Server, Intranet, Ticketing System, etc.. There is a lot of data change going on within a 24 hour window.

Given our use, how is it possible used would still show 0 change? The example you gave above makes sense, but with iSCSI used across both of these OS's with decent daily change - i'm still not seeing a correlation between used and the size of the snapshot. 30GB changed in a day also (based on netstat).

Cheers, joo

 

[fracai]

I can't say, but you should be able to figure things out if you take a look at 'zfs diff' and perhaps regular 'diff' and 'sha1'. Try comparing the files to see if there actually is a difference. It's possible that you aren't snapshotting what you thought you were, or that replication isn't functioning correctly.

 

[hungarianhc]

Yeah, pretty basic questions that you should be able to answer with some basic searching.

I'm coming up with this question as well, and I can't seem to find it in the documentation. Can you let me know where it defines these terms or where I should be searching? If it's not in the documentation, I'll file a ticket to have it put in there. Thanks!

 

[ser_rhaegar]

When a snapshot is created, its disk space is initially shared between the snapshot and the file system, and possibly with previous snapshots. As the file system changes, disk space that was previously shared becomes unique to the snapshot, and thus is counted in the snapshot's used property. Additionally, deleting snapshots can increase the amount of disk space unique to (and thus used by) other snapshots.
A snapshot's space referenced property value is the same as the file system's was when the snapshot was created.

Source: http://docs.oracle.com/cd/E19253-01/819-5461/gavvx/index.html

More details:
http://docs.oracle.com/cd/E19253-01/819-5461/6n7ht6r2s/index.html#gcfgr

 

[hungarianhc]

I have seen those Oracle ZFS docs, but that's not the FreeNAS documentation, which should explain what each column header stands for.

 

[ser_rhaegar]

I wasn't saying they should or shouldn't have it in their manual. I was just telling you guys where you could find the answers today.

 

[fracai]

I'm pretty sure the columns use the same terminology that the zfs and zpool commands use. You should read the oracle pages and apply the same knowledge.

 

[hungarianhc]

I'm pretty sure the columns use the same terminology that the zfs and zpool commands use. You should read the oracle pages and apply the same knowledge.

By that logic, I should be required to read a Linux manual for using a TiVo, as it's based on a linux kernel. I'll file a ticket to update the documentation or to include a definition in the UI.

https://bugs.freenas.org/issues/4977

 

[dlavigne]

Just a reminder that anyone can update the wiki at doc.freenas.org...

 

[joobie]

hungarianhc, i've basically moved to an alternative solution to FreeNAS after giving it about 6m-1y of a go.

ZFS is great and FreeNAS is a great idea to package it up into a easy to use solution. Downside is there is poor documentation and when you hit a fault, there is poor support across the forums.

We were replicating ZFS from one site to another, it failed time and time again and we posted multiple threads about it - all of which came up with the useless responses that you are getting within this thread from people like dlavigne & fracai.

For a hobby solution, it's OK I guess to toy around with - but for something serious - it's not stable / documented / supported well enough to be able to rely on.


Cheers, joo

 

[cyberjock]

That's because for something serious you should be doing your homework, learning a little about FreeBSD and FreeNAS, etc.

There's a reason why I put in my noobie guide this slide:

Your dedication to learning how to use the command line and setup FreeNAS with the proper features to monitor your hard drives, your UPS, and your hardware will determine how safe your data is.
If you choose to do the bare minimum learning, your data is not as safe as someone that has spent a few weeks to become thoroughly familiar with FreeNAS and custom scripts.
If you choose to spend the necessary time to get familiar with FreeBSD command line and scripting you can have a very safe and reliable storage location for your data.

Notice I didn't say anything about going to the forums and getting a formal education in FreeNAS or FreeBSD. This forum and IRC are not here to be your sole support structure. You should be ready to go figure stuff out on your own with only occasional questions here for very complex situations. If you want someone to be your sole support structure, there is plenty of paid support out there. But we are not under any obligation to provide you with support for software that cost you absolutely nothing to download and use.

The way in which your data is stored, how safely it is stored, and how you manage your file server is your responsibility. Not mine. Not anyone else's. Yours and yours alone. If you don't like that you can either:

1. Use something else that you can use that does meet your criteria and threshold for responsibility.
2. Pay someone to handle that responsibility for you.
3. Spend the time and effort to become the expert you want/need to be to handle your server.

Choose one.

 

[hungarianhc]

Hey cyberjock,

I appreciate the response, but I disagree a bit. I guess I take a different angle.. Rather than "it's your job to do your homework" I think "it's your job to help." For example, I totally agree with the OP that the information isn't clearly stated. That's why I filed a ticket to have it more clearly labeled: https://bugs.freenas.org/issues/4977

It looks like there will be a better explanation either in the documentation or in the UI now with 9.2.2.

 

[fracai]

It's actually not CJs job to help. He's a volunteer.

There might be the expectation that because he has helped others with more difficult problems, he has to help everyone, but that is unfounded and presumptive. Especially so when the knowledge is readily available.

Still, good job with the ticket; improving the docs is a big part of making FreeNAS better.

 

[hungarianhc]

Thanks, fracai - I never indicated that it was cj's role to help. I just meant that instead of taking time to write a 3 paragraph post that didn't really say anything except that he should try harder, it would be more constructive to suggest filing a ticket or helping to centralize the documentation better. Either way, glad to see FreeNAS progress!