Any way to get "Active volumes" GUI to display usage for ZFS Vols used as iSCSI tgts?

[Peter Bowler]

Hello,

I have one Pool that is cut up into zvols floor use as iSCSI targets.
The "Active Volumes GUI just shows their maximum size but doesn't give nay info on actual usage.

Additionally I have snapshots running which obviously don't show up here either...

any thoughts?

 

[Peter Bowler]

No one?

hmmm

 

[cyberjock]

iSCSI only takes some storage space and dumps it to whatever machine you access. It shoudln't normally be trying to access data in the iSCSI store. So based on that concept I'd say "no, it's not possible...."

 

[Peter Bowler]

sorry, less about the SCSI and more about the zvols.

any way to get the zvol info to be accurate, irrespective of whether I use them for iSCSI or not.

i.e. "zfs list"

 

[cyberjock]

I'm not really sure what is "inaccurate" that needs to be more "accurate"..

 

[jgreco]

I'm not really sure what is "inaccurate" that needs to be more "accurate"..

If you're not consuming all of the space (i.e. you have not yet written to the entire volume) it might be nice to report "Used".

This is kind of a subtle point. With ZFS, untouched space in a file extent (and presumably a zvol based extent) isn't actually allocated from the pool. You can create three 1TB extents (or a thousand!) on a 2TB filesystem, and it will appear to be all working and fine and happy until the sum of the extents is around 1.8TB. At which point your iSCSI service goes completely crazy as it cannot write a block that it reasonably ought to be able to, due to lack of free space in the pool.

Reporting "Used" as the amount of space allocated out of the pool, and "Available" as the remaining space available in the pool (or allowed by quota or whatever) makes a heck of a lot of sense from that perspective.

 

[Peter Bowler]

I'm not really sure what is "inaccurate" that needs to be more "accurate"..

This would be a good start

 

[RvdKraats]

I don't think your FreeNAS can look into zvols. A server that'll use the zvol doesn't neccessarily format it as a filesystem that FreeNAS understands. FreeNAS only knows it serves a big file as a LUN to a server, and doesn't know what that server is doing with it. For example, NetApp filers also cannot do this; the only way when using a NetApp is when the client uses Snapdrive software to operate it's LUN, so that Snapdrive can inform the NetApp filer about what is happening to which block of the LUN.

 

[jgreco]

I don't think your FreeNAS can look into zvols. A server that'll use the zvol doesn't neccessarily format it as a filesystem that FreeNAS understands. FreeNAS only knows it serves a big file as a LUN to a server, and doesn't know what that server is doing with it. For example, NetApp filers also cannot do this; the only way when using a NetApp is when the client uses Snapdrive software to operate it's LUN, so that Snapdrive can inform the NetApp filer about what is happening to which block of the LUN.

Reporting the amount of space used by a zvol does not require you to look into the zvol. Suggest you go and read my comments above. What "looking in" suggests is that FreeNAS should go into the zvol, try to figure out what's stored there, and then interpret the data there as the initiator would for whatever filesystem the initiator has decided to store there. Problem is, that's crazy complex. What if it's more than one filesystem? What if it's a complete FreeBSD install with eight partitions? What if it's something much more complex than that?

Discard that idea and focus on what was suggested in my comment above; it is sane, reasonable, should be quite possible, and most importantly, it is USEFUL in any environment where oversubscription is in play.

 

[RvdKraats]

Hi jgreco,

If you meant checking how much a zvol would consume from a thin provisioning point of view, then i agree, that should be doable. What i meant to say was, that if a 'foreign' OS starts using the zvol, the underlaying FreeNAS machine could see how much would be used. But, as an OS could possibly delete files by deleting only the pointers to a file, FreeNAS (or any LUN provider for that matter) wouldn't be able to see if the previously used blocks in the zvol would or wouldn't be used anymore. Increase of zvol usage could be spotted, but decrease of usage would be difficult to check.

 

[jgreco]

"Thin provisioning" is a virtualization term for a concept that's existed a long time in the UNIX (and NTFS for that matter) world: sparse allocation. While I applaud the virtualization world's marketing departments for creating a new term for an old concept, I should point out that iSCSI extents are used outside of virtualization environments as well, so it's probably best to let the virtualization people have their newly discovered invention along with their new term, so as to avoid confusion, at least for this discussion...

From a sparse allocation point of view, we're basically talking about implementation of "ls -s" vs "ls -l" ... it sometimes comes as a shock to UNIX newcomers that sparse allocation can happen, and Bad Things(tm) can happen if insufficient space is available. It also comes as a shock to ZFS newcomers that many things can affect the number of blocks a file can take ... it's not a given that "ls -l" will give a number that's 1KB * the "ls -s" number. In fact, if "zfs copies=" is set to something other than 1, or other space-affecting options have been set, the results can be unpredictable.

And that's really the issue here. There's a useful number that could be reported. Two, even.