Hi, I was looking for the zfs system calls to check zfs quotas from within C code, analogous to the quotactl(7I) interface for UFS, and realized that there was nothing similar. Is anything like this planned? Why no public API for ZFS? Do I start making calls to zfs_prop_get_int(), like in the df code, to find out what I want? Will this blow up later? Jeff Earickson Colby College
Jeff A. Earickson wrote:> Hi, > > I was looking for the zfs system calls to check zfs quotas from > within C code, analogous to the quotactl(7I) interface for UFS, > and realized that there was nothing similar. Is anything like this > planned? Why no public API for ZFS? > > Do I start making calls to zfs_prop_get_int(), like in the df > code, to find out what I want? Will this blow up later?What is it that you are trying to do here ? -- Darren J Moffat
On Tue, 12 Sep 2006, Darren J Moffat wrote:> Date: Tue, 12 Sep 2006 10:30:33 +0100 > From: Darren J Moffat <Darren.Moffat at Sun.COM> > To: Jeff A. Earickson <jaearick at colby.edu> > Cc: zfs-discuss at opensolaris.org > Subject: Re: [zfs-discuss] ZFS API (again!), need quotactl(7I) > > Jeff A. Earickson wrote: >> Hi, >> >> I was looking for the zfs system calls to check zfs quotas from >> within C code, analogous to the quotactl(7I) interface for UFS, >> and realized that there was nothing similar. Is anything like this >> planned? Why no public API for ZFS? >> >> Do I start making calls to zfs_prop_get_int(), like in the df >> code, to find out what I want? Will this blow up later? > > What is it that you are trying to do here ?Modify the dovecot IMAP server so that it can get zfs quota information to be able to implement the QUOTA feature of the IMAP protocol (RFC 2087). In this case pull the zfs quota numbers for quoted home directory/zfs filesystem. Just like what quotactl() would do with UFS. I am really surprised that there is no zfslib API to query/set zfs filesystem properties. Doing a fork/exec just to execute a "zfs get" or "zfs set" is expensive and inelegant. Jeff Earickson Colby College
On Tue, Sep 12, 2006 at 07:23:00AM -0400, Jeff A. Earickson wrote:> > Modify the dovecot IMAP server so that it can get zfs quota information > to be able to implement the QUOTA feature of the IMAP protocol (RFC 2087). > In this case pull the zfs quota numbers for quoted home directory/zfs > filesystem. Just like what quotactl() would do with UFS. > > I am really surprised that there is no zfslib API to query/set zfs > filesystem properties. Doing a fork/exec just to execute a "zfs get" > or "zfs set" is expensive and inelegant.The libzfs API will be made public at some point. However, we need to finish implementing the bulk of our planned features before we can feel comfortable with the interfaces. It will take a non-trivial amount of work to clean up all the interfaces as well as document them. It will be done eventually, but I wouldn''t expect it any time soon - there are simply too many important things to get done first. If you don''t care about unstable interfaces, you''re welcome to use them as-is. If you want a stable interface, you are correct that the only way is through invoking ''zfs get'' and ''zfs set''. - Eric -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock
On 13/09/2006, at 2:29 AM, Eric Schrock wrote:> On Tue, Sep 12, 2006 at 07:23:00AM -0400, Jeff A. Earickson wrote: >> >> Modify the dovecot IMAP server so that it can get zfs quota >> information >> to be able to implement the QUOTA feature of the IMAP protocol >> (RFC 2087). >> In this case pull the zfs quota numbers for quoted home directory/zfs >> filesystem. Just like what quotactl() would do with UFS. >> >> I am really surprised that there is no zfslib API to query/set zfs >> filesystem properties. Doing a fork/exec just to execute a "zfs get" >> or "zfs set" is expensive and inelegant. > > The libzfs API will be made public at some point. However, we need to > finish implementing the bulk of our planned features before we can > feel > comfortable with the interfaces. It will take a non-trivial amount of > work to clean up all the interfaces as well as document them. It will > be done eventually, but I wouldn''t expect it any time soon - there are > simply too many important things to get done first. > > If you don''t care about unstable interfaces, you''re welcome to use > them > as-is. If you want a stable interface, you are correct that the only > way is through invoking ''zfs get'' and ''zfs set''.I''m sure I''m missing something, but is there some reason that statvfs () is not good enough?
Richard L. Hamilton
2006-Sep-13 14:25 UTC
[zfs-discuss] Re: ZFS API (again!), need quotactl(7I)
> On 13/09/2006, at 2:29 AM, Eric Schrock wrote: > > On Tue, Sep 12, 2006 at 07:23:00AM -0400, Jeff A. > Earickson wrote: > >> > >> Modify the dovecot IMAP server so that it can get > zfs quota > >> information > >> to be able to implement the QUOTA feature of the > IMAP protocol > >> (RFC 2087). > >> In this case pull the zfs quota numbers for quoted > home directory/zfs > >> filesystem. Just like what quotactl() would do > with UFS. > >> > >> I am really surprised that there is no zfslib API > to query/set zfs > >> filesystem properties. Doing a fork/exec just to > execute a "zfs get" > >> or "zfs set" is expensive and inelegant. > > > > The libzfs API will be made public at some point. > However, we need to > finish implementing the bulk of our planned features > before we can > feel > comfortable with the interfaces. It will take a > non-trivial amount of > work to clean up all the interfaces as well as > document them. It will > be done eventually, but I wouldn''t expect it any > time soon - there are > simply too many important things to get done first. > > > If you don''t care about unstable interfaces, you''re > welcome to use > > them > > as-is. If you want a stable interface, you are > correct that the only > > way is through invoking ''zfs get'' and ''zfs set''. > > I''m sure I''m missing something, but is there some > reason that statvfs > () is not good enough? >Assuming that statvfs() reports per filesystem, and (as I understand it), zfs "quotas" are per-filesystem sharing a storage pool, and not per-user, I think you''ve got a point there. Of course, for some things (like a /var/mail directory, or something similar with one large _file_ per user in a single directory), it seems to me that per-user quotas would still be quite desirable; likewise sometimes for shared trees meant for some sort of collaborative activity...even if for things such as home directories, a filesystem per user works out fine, that model doesn''t fit everything well. This message posted from opensolaris.org
Issue with statvfs() # zfs list NAME USED AVAIL REFER MOUNTPOINT mypool 108M 868M 26.5K /mypool mypool/home 108M 868M 27.5K /mypool/home mypool/home/user-2 108M 868M 108M /mypool/home/user-2 # df -h Filesystem size used avail capacity Mounted on ... mypool 976M 26K 868M 1% /mypool <---- used not in sync with ''zfs list'' mypool/home 976M 26K 868M 1% /mypool/home mypool/home/user-2 976M 108M 868M 12% /mypool/home/user-2 or my interpretation of zfs list incorrect ? This message posted from opensolaris.org
Matthew Ahrens
2007-Jun-14 17:07 UTC
[zfs-discuss] Re: ZFS API (again!), need quotactl(7I)
Pretorious wrote:> Issue with statvfs() > > > # zfs list > NAME USED AVAIL REFER MOUNTPOINT > mypool 108M 868M 26.5K /mypool > mypool/home 108M 868M 27.5K /mypool/home > mypool/home/user-2 108M 868M 108M /mypool/home/user-2 > > # df -h > Filesystem size used avail capacity Mounted on > ... > mypool 976M 26K 868M 1% /mypool <---- used not in sync with ''zfs list'' > mypool/home 976M 26K 868M 1% /mypool/home > mypool/home/user-2 976M 108M 868M 12% /mypool/home/user-2 > > or my interpretation of zfs list incorrect ?Yeah, df''s "used" is zfs list''s "REFER". zfs list''s "used" takes into account space used by all descendant filesystems/zvols. --matt