I''m having trouble finding information on any hooks into ZFS. Is there information on a ZFS API so I can access ZFS information directly as opposed to having to constantly parse ''zpool'' and ''zfs'' command output? This message posted from opensolaris.org
On 8/16/06, William Fretts-Saxton <william.fretts.saxton at sun.com> wrote:> I''m having trouble finding information on any hooks into ZFS. Is there information on a ZFS API so I can access ZFS information directly as opposed to having to constantly parse ''zpool'' and ''zfs'' command output?libzfs: http://cvs.opensolaris.org/source/xref/on/usr/src/lib/libzfs/common/ -- Eric Enright
On Wed, 2006-08-16 at 11:49 -0400, Eric Enright wrote:> On 8/16/06, William Fretts-Saxton <william.fretts.saxton at sun.com> wrote: > > I''m having trouble finding information on any hooks into ZFS. Is > > there information on a ZFS API so I can access ZFS information > > directly as opposed to having to constantly parse ''zpool'' and ''zfs'' > > command output? > > libzfs: http://cvs.opensolaris.org/source/xref/on/usr/src/lib/libzfs/common/Careful -- this isn''t an API -- it''s part of the implementation of ZFS, and as a result it is subject to incompatible change at any time without advanced warning. In terms of our Interface Taxonomy, this is considered "Project Private". If you have specific requirements for a programmatic interface to ZFS, let''s hear them... it''s not uncommon for Private interfaces to get put through some renovation and housecleaning and then promoted to a public interface, but it''s best for the conversation to happen first... (And I can''t speak for the plans/intentions of the core zfs team on this..) - Bill
This is my first post on the opensolaris.org forums. I''m still trying to figure out whether I''m actually on the zfs-discuss alias and, if not, how to add myself to it! Anyway, I''m looking for a way to get information like "zpool list" or "zfs get all <filesystem>" through an API instead of parsing the information from the CLI. In the ideal world, I could just "get" a zpool object from the OS, which contained the zpool information and various zfs objects and do whatever I wanted with them. Bill Sommerfeld wrote:> On Wed, 2006-08-16 at 11:49 -0400, Eric Enright wrote: >> On 8/16/06, William Fretts-Saxton <william.fretts.saxton at sun.com> wrote: >>> I''m having trouble finding information on any hooks into ZFS. Is >>> there information on a ZFS API so I can access ZFS information >>> directly as opposed to having to constantly parse ''zpool'' and ''zfs'' >>> command output? >> libzfs: http://cvs.opensolaris.org/source/xref/on/usr/src/lib/libzfs/common/ > > Careful -- this isn''t an API -- it''s part of the implementation of ZFS, > and as a result it is subject to incompatible change at any time without > advanced warning. > > In terms of our Interface Taxonomy, this is considered "Project > Private". > > If you have specific requirements for a programmatic interface to ZFS, > let''s hear them... it''s not uncommon for Private interfaces to get put > through some renovation and housecleaning and then promoted to a public > interface, but it''s best for the conversation to happen first... > > (And I can''t speak for the plans/intentions of the core zfs team on > this..) > > - Bill > > > > > >
Perhaps this JNI code is what I''m looking for? http://cvs.opensolaris.org/source/xref/on/usr/src/lib/libzfs_jni/ It says the ZFS GUI uses this so, I''m assuming, anyone could. Although I am a Java programmer, I have ZERO experience with JNI. Am I on the right track? Bill Sommerfeld wrote:> On Wed, 2006-08-16 at 11:49 -0400, Eric Enright wrote: >> On 8/16/06, William Fretts-Saxton <william.fretts.saxton at sun.com> wrote: >>> I''m having trouble finding information on any hooks into ZFS. Is >>> there information on a ZFS API so I can access ZFS information >>> directly as opposed to having to constantly parse ''zpool'' and ''zfs'' >>> command output? >> libzfs: http://cvs.opensolaris.org/source/xref/on/usr/src/lib/libzfs/common/ > > Careful -- this isn''t an API -- it''s part of the implementation of ZFS, > and as a result it is subject to incompatible change at any time without > advanced warning. > > In terms of our Interface Taxonomy, this is considered "Project > Private". > > If you have specific requirements for a programmatic interface to ZFS, > let''s hear them... it''s not uncommon for Private interfaces to get put > through some renovation and housecleaning and then promoted to a public > interface, but it''s best for the conversation to happen first... > > (And I can''t speak for the plans/intentions of the core zfs team on > this..) > > - Bill > > > > > >
On Wed, Aug 16, 2006 at 01:44:48PM -0400, William Fretts-Saxton wrote:> Perhaps this JNI code is what I''m looking for? > > http://cvs.opensolaris.org/source/xref/on/usr/src/lib/libzfs_jni/ > > It says the ZFS GUI uses this so, I''m assuming, anyone could. Although > I am a Java programmer, I have ZERO experience with JNI. Am I on the > right track?This is another private API, albeit one written in Java. Unlike the DTrace JNI, this is a private interface between libzfs and the ZFS GUI. By nature of being cross-consolidation, it will likely change less frequently than the libzfs interface (hence putting it in ON in the first plcae). However, it is still a private interface and subject to incompatible change at any point. For ZFS status, the CLI was intentionally designed (''zfs list -H'', ''zfs get -H'') to be parsable, and that is the only stable interface for doing so. For pool status, we don''t currently have any stable, parsable, output. There is an RFE open for this, but I don''t have the BugID handy. I would imagine that the libzfs API would be made public at some point, but we need to wait for a variety of other RFEs to be implemented. Nearly every new feature (and even some bugfixes) ends up making incompatible changes to the API - it is still evolving. Once we are satisfied with the set of supported features, we can think about publicizing the API. But I would not expect this to occur for at least another year. - Eric -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock