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.) Nils Goroll writes: > >From my experience, the most important issues are that currently there > is no generic way to > > - mount filesystems on a metaset (can fail if metaset auto-take does > not work or not supported as in Sun Cluster) > > -> we need a metaset take import method and a filesystem mount > method which depends upon the metaset > > - mount filesystems which depend upon each other but are of different > FSTypes like NFS, ZFS, UFS or lofs. The classic is that a lofs mount > of an NFS mount or even an UFS mount fails (in some cases), if > simply being added to the vfstab. > > There are two different kinds of dependencies, but both boil down to > a dependency from one mount to another where one cannot be mounted > until this other is (I was tempted to use the notion of the dependee > and depender/dependend here, but this is always confusing, I think): > > - layered mounts where one FS is mounted into the namespace of > another > - loopback (lofs) mounts which need another FS as their "device" > > As a first effort to solve these issues "once and for all", I have > written > > - A simple metaset take/release method (trivial) > - and a proptotype of a generec mount method > > I would like to introduce the latter. Here's the general idea: > > - Every mountpoint should be a service. If it depends upon other > mountpoints, SMF dependencies should be used > > - What is now in /etc/vfstab should be in SMF, but to make things > easy, I would like a sync tool which generates an SMF config from > vfstab, similar to inetconv. > > - This could replace or at least amend > > svc:/system/filesystem/local:default and > svc:/network/nfs/client:default . > > The prototype which I have finished so far converts entries from > /etc/vfstab to SMF and automatically creates dependencies. To mark > entries which should be handled by SMF, I used the keyword "smf" in > the mount at boot column of /etc/vfstab. [ snip of very cool prototype. ] > * TODOs (those which came to my mind) > > - admin script: sync-with-vfstab -- modify properties if something > has been changed in vfstab, delete mpoints which have been > removed... > > - automate dependencies to metasets and vxvm diskgroups > > - test with zfs > > - move ufs qouta-support from filesystem/local to mount methods > (:quota instance ?) > > - finish all the details , ? rewrite admin script in perl ? > > This mini project is really not in a state where is should be > published, but if people are interested, I will definitely publish > it. But first of all I would like to hear some opinions... > My questions: > > - What do you think about this? Is this the right way to go? I believe > that it is, but maybe someone has a better idea? I think it is a good way to go. It also pushes us down a path which allows extensibility of filesystem configuration, which we don't have in the current vfstab format today. Some things to consider: - I'd recommend introducing a command to manipulate and query the filesystem configuration. I expect some of the concerns about moving away from vfstab would be alleviated by a solid (and easily scriptable) command to query and manipulate that data. (Honestly, such a command could be integrated today, and separately, to simply manipulate and query the existing vfstab.) - Compatibility will be a concern. Because there is no existing vfstab command, people are married to parsing the file format. ARC (and people with lots of tooling built around vfstab) will be worried. ZFS's choice to discard vfstab use by default may help. However, I do caution to avoid the trap of storing configuration for multiple subsystems in multiple persistent places. They're guaranteed to get out of sync and cause wailing and gnashing of teeth. I'm not sure I have a good enough grasp on your vfstab handling (especially the 'delete' part) to comment further, yet. - ZFS has a split model already. It is optional (and not the default) to use vfstab, because they want to bring the mount information with them, as well as wanting to store more with the filesystem than vfstab would have permitted. Deciding on how to coordinate with that model is important. - System filesystems (/, /usr, swap) worry me a bit. No concrete statements on this yet, but there's a vague concern. There's probably more, but none of this would stop me from suggesting you move forward with a project to start capturing discussion, design, and implementation. > - If this is something that the world needs, I would like to make this > an official opensolaris (mini-) project. As I mentioned above, I'd support creating project infrastructure to allow collaboration around this. > Who would help to set this up? I'd expect this community would be willing to sponsor. (You've got my +1 on getting the infrastructure.) > Who would participate? I'd help where I could in terms of code and reviews in my free time. (That's not a lot of time to promise, but I would like to lend tangible support where possible, not just throw stones from the sidelines.) > Would Sun support this concept? I expect you'll be getting some wildly divergent set of opinions from Sun folks about this concept. You'll never see a unified response. Instead, consider working on gathering feedback from the appropriate sets of communities. (Filesystem and sysadmin seem like obvious additions.) Get an early review from the ARC. Sun doesn't have to support your idea for it to be integrated into OpenSolaris -- but you do need to be able to get approval from the ARC and from an appropriately-expert set of code reviewers. That approach will give some ideas on where potential roadblocks might occur. Obviously, I'm curious to hear other responses you receive as well! liane
