Fix ZFS reporting plugin

A

AddonEx

Verified User
Joined
Jan 4, 2011
Messages
12
Hello,

As we noticed some of you have problems with running DirectAdmin under zfs, and the main problem is reporting quotas we was thinking on developing a plugin which to solve the reporting problem.

So users won't have been counted as having 0 mb space allocated, but rather the real (estimated) amount. And of course, this would make the suspending works again for the users which are using more space than the allocated space...

I am wondering if anyone would be interested on such plugin, we may be able to do it.
 
I think it would be best to check with John first if ZFS quota is going to be supported in DA in the near future.
I know he's been sent scripts that do report quota usage on ZFS filesystems.

Also, I'm not too sure a plugin would solve it, unless you can alter the output of DA before it's being sent to the skin (without altering the skin). If you don't, quota would be reported in 2 places, the DA pages and your plugin. It could be confusing to users.
 
Hello,

Already contacted John. I haven't got anything yet to suggest we going to have the feature implemented (soon).

The results would show normal (users list, all the other lists), no need of a second list. No need of skin editing.
 
So, you mean that all the data on CMD_USER_STATS would be correct without any modifications?

I'm guessing it would be FreeBSD 8.2+ only?
 
Hi.

I am part of the work on the plugin, as it stands it will work out of the box on any directadmin zfsv15 system, so the plugin is installed in the plugin manager and then quotas will simply start working as like on ufs.

The only configuration issue will likely be setting the fileset(partition) that is to be used for the user's homedir so it knows which one to collect the usage data from.

There is possibilities of version checking zfs on installation and even offering the ability to update it but the idea of this plugin as it stands is for a simple plug and play quota system.
 
OK, so figures will be modifed where DA checks for usage and limits and thus the correct values will show up on the stats page.
 
What about just replacing all this with 'du -s /home/user' check?

I use ZFS based DA in a jail (I won't be running DA on my main host) and It doesn't have much access to the ZFS commands.

du -s /home/user seems to show correct space used anyway.
 
woyteck said:
What about just replacing all this with 'du -s /home/user' check?

I use ZFS based DA in a jail (I won't be running DA on my main host) and It doesn't have much access to the ZFS commands.

du -s /home/user seems to show correct space used anyway.
Click to expand...

That will only show disk usage within the home directory for a user, it doesn't provide any size constraint quota features. Furthermore, it is a very expensive means of tallying disk usage (it has to traverse all subdirectories within the path reading inode info as it goes, which puts unnecessary IO load on the disk).

I too run DA in a freebsd jail with ZFS, so in the end I wrote my own solution, which provides fully transparent ZFS quota support to DA.

The way it works is this :

1. This jail has its own ZFS v15 dataset (more luck than forward thinking - I did it initially for the ability to snapshot the DA jail).

2. I have a minutely cron job on the host that runs a userspace query on the DA jail dataset (very cheap operation) and dumps it to a file within the dataset. It also reads and processes limited instructions from a different file within the dataset to facilitate manipulation of the dataset's quota from within the jail, as well as performing some housekeeping (such as removing quotas for system users that no longer exist within the jail).

3. Within the jail, I wrote replacements for repquota and edquota, so that they read quota information and write instructions from/to the files described in #2 and then configured DA to use them instead of the UFS based originals.

As ZFS stores/updates quota information as part of its normal operations, it also means that retrieving the quota information is extremely cheap (and doesn't require periodic quotachecks to ensure the quota integrity is intact).

As a result, I can lower the disk quota user update period (quota_update_interval) down the minimum of 1 minute instead of the 10mins DA defaults to (in fact, I could set it to 1 second with no adverse impact, if DA had such granularity).

Regards,

Jase.
 
jaset said:
As a result, I can lower the disk quota user update period (quota_update_interval) down the minimum of 1 minute instead of the 10mins DA defaults to (in fact, I could set it to 1 second with no adverse impact, if DA had such granularity).
Click to expand...

Although, anything less than 1 minute would be pointless given that the host only runs its cronjob every minute to make the quota information available to the jail.

Regards,

Jase.
 
You must log in or register to reply here.
Back
Top