On Wed, Sep 26, 2007 at 11:36:57AM -0700, Richard Elling wrote: > AFAIK, VxVM still only expects one private region per disk. The private > region stores info on the configuration of the logical devices on the > disk, and its participation therein. ZFS places this data in the on-disk > format on the vdev, which is radically different. With ZFS you could > conceivably have a different storage pool per slice or partition.
Right. One private region per disk is certainly the standard way to set up VxVM, but it is not required. With type=simple, the private and public data share a slice. # vxdisk -g testdg list DEVICE TYPE DISK GROUP STATUS c1t6d0s5 simple disk6slice5 testdg online c1t6d0s6 simple disk6slice6 testdg online # vxdisk -g testdg list disk6slice5 Device: c1t6d0s5 devicetag: c1t6d0 type: simple [...] info: privoffset=1 flags: online ready private autoimport imported pubpaths: block=/dev/vx/dmp/c1t6d0s5 char=/dev/vx/rdmp/c1t6d0s5 version: 2.1 iosize: min=512 (bytes) max=2048 (blocks) public: slice=5 offset=2305 len=1022520 disk_offset=12510 private: slice=5 offset=1 len=2048 disk_offset=12510 [...] So the "Disk" name is 'disk6slice5', but that isn't really the name of a disk on Solaris. It's just a slice, and I have two of these VM disks on this physical disk. > >I'm only suggesting that a common use of both is in a 1:1 situation, and > >that being able to give names to storage is valuable in that case. I > >don't see that the value is diminished becase we can create a > >configuration where it's less obvious how it would be used. > > I think you are still thinking of the old way of doing things where you > *had to worry* about disks. To some degree, ZFS frees you from that > restriction in that you can worry about storage pools, at a higher level > of abstraction. VxVM and SVM got us only part way down the road to > abstraction. I would agree, but I don't think we're completely away from that yet either. When auto-identification of disks becomes possible (at whatever level of the stack makes sense), then that will go a long way toward good solutions. In the meantime, adding a name seems easier and possibly helpful. -- Darren Dunham [EMAIL PROTECTED] Senior Technical Consultant TAOS http://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area < This line left intentionally blank to confuse you. > _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
