The way I see it benefits is because it will mean less "stray" threads
which is what I would call symlinks.
Say if the mount option for zvols are used to define that purpose, ZFS
metadata will always know how it is really being used. Also if someday
we come up with the framework to dump the metadata out of one system and
use that on a recovery system, we will cover all those hidden symlinks
and save the customer the trouble of remembering all the symlinks that
were created.
I would say .. truly abstracting the poolname from the zvol path would
be my main goal. What if in the middle of a database deployment I think
the vol should go on a different pool. Now I have the poolname hard
coded in my database and have to create a symlink referencing the
poolname/path combination to the new poolname path. From the user point
of view he is under the wrong impression from what he reads from the
database.
There are lot of scenarios where I think it will also help out a lot.
Consider massive deployments of identical setups. A design which
abstracts the zvol names is safer in scenarios where they end up with
different pool names.
. Atleast in my case where I am using DB2 with multiple partitions on
the same server all having their own tablespace areas, a simplified zvol
names cuts down the number of lines I have to write for all partition
from N lines to 1 where I add the partition id to the end of it.
I would say sleep over it to see where else it can apply.
Thanks for considering my 2 cents.
Regards,
Jignesh
Richard Elling wrote:
Jignesh K. Shah wrote:
I am already using symlinks.
But the problem is the ZFS framework won't know about them .
Can you explain how this knowledge would benefit the combination
of ZFS and databases? There may be something we could leverage here.
I would expect something like this from ZVOL specially abstracting
the poolname path from zvol.
Specially since many database will store the path names in their
metadata and is hard to change later on.
Which is why everyone I know uses symlinks :-)
-- richard
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
