> > Wow, Nils! What you've done here already is incredibly cool. I > absolutely think it's worth exploring further, and 100% support a > project to explore further. > > More below. (Though I may have left an excessive amount of context.) > ...
Let me second that and say this is definitely cool and useful and something to pursue further. I have two comments, one minor and one major: - Minor is that I would not add FMRIs for things that need "fsck" - that should be viewed as an implementation detail of the start/mount method for particular filesystems, not something we expose into the smf namespace. - Major that Liane also pointed out is ZFS. ZFS rightly stores all of its metadata inside of itself (yeah, yeah, zpool.cache but whatever). And given the notion of 10,000+ filesystems since they are so lightweight neither vfstab nor smf would make sense there. Also it is very bad idea to duplicate that state, i.e. have ZFS knowledge of mounts duplicated as smf services in the repository that we have to keep in sync. One way around this might be to say that regardless of where one stores the idea of needing to mount something, there is a uniform way to express dependencies on those mounts. That is, right now smf has this half-baked notion of file dependencies that we never finished. If you have legacy mounts expressed as FMRIs that one can express a service dependency on, you could introduce either zfs:/// dependencies or file dependencies for ZFS mount points, and this would permit you to uniformly use dependencies even if "start" in some cases is done by a method script and in other cases is done by the innards of ZFS. -Mike -- Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/
