Is there a way that I can discover the vdev configuration of a ZFS pool, starting with a single leaf vdev device? The "config" attribute of the object directory contains the needed information, but I''m not sure how to read it until I already know the vdev configuration in order to correctly interpret the vdev portion of a DVA (a chicken and egg problem!). The vdev label contains part of the vdev configuration (the subtree of a single top-level vdev), but without information about the other top-level vdevs I still can''t interpret the DVA in a block pointer. Am I missing something here? Perhaps I''m supposed to scan through "all" devices looking for vdev labels and matching up pool_guid''s? (but that would be rather error prone, as it would be difficult to tell at first whether I''m missing some top-level vdev, right?) This message posted from opensolaris.org
On Tue, Jan 03, 2006 at 05:39:23PM -0800, Luke wrote:> Is there a way that I can discover the vdev configuration of a ZFS > pool, starting with a single leaf vdev device? The "config" attribute > of the object directory contains the needed information, but I''m not > sure how to read it until I already know the vdev configuration in > order to correctly interpret the vdev portion of a DVA (a chicken and > egg problem!). The vdev label contains part of the vdev configuration > (the subtree of a single top-level vdev), but without information > about the other top-level vdevs I still can''t interpret the DVA in a > block pointer. > > Am I missing something here? Perhaps I''m supposed to scan through > "all" devices looking for vdev labels and matching up pool_guid''s? > (but that would be rather error prone, as it would be difficult to > tell at first whether I''m missing some top-level vdev, right?)You should read: http://blogs.sun.com/roller/page/eschrock?entry=behind_the_scenes_of_zpool Basically, you have to taste every device you expect to be in the pool. The reasons we do it this way are outlined in the above blog entry. You can tell if you''re missing a toplevel vdev based on the vdev GUID sum for the pool. You can''t tell _what_ you''re missing, but this is a rare case, and is covered by the following RFE: 6325967 neighbor lists Which would keep (purely informational) data about other devices in the pool. - Eric -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock
Thanks Eric, that blog post is very enlightening. I hope you will allow me to push a little further before giving up :-) - Using a cache such as /etc/zfs/zpool.cache wouldn''t work if ZFS is to be used as a root filesystem, right? Relying on scanning all block devices at boot time worries me in that it may not be exhaustive, or may be too exhaustive! I would have thought that a discovery mechanism which begins with a single block device would be really useful for root filesystem support. - What''s wrong with storing the entire vdev tree on each leaf vdev? Are there concerns about the size of the tree or about the update mechanism? This message posted from opensolaris.org
On Tue, Jan 03, 2006 at 08:46:43PM -0800, Luke wrote:> > - Using a cache such as /etc/zfs/zpool.cache wouldn''t work if ZFS is > to be used as a root filesystem, right? Relying on scanning all block > devices at boot time worries me in that it may not be exhaustive, or > may be too exhaustive! I would have thought that a discovery > mechanism which begins with a single block device would be really > useful for root filesystem support.Yes, we will probably need something like this for root filesystem support. Things get very complicated very quickly in the boot world (it''s quite difficult to address multiple devices) and we haven''t hashed out the details yet. Right now I believe the boot prototype only supports a single device pool. More details will be forthcoming as the project evolves.> - What''s wrong with storing the entire vdev tree on each leaf vdev? > Are there concerns about the size of the tree or about the update > mechanism?Both. - Eric -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock