On 4/13/2010 1:41 AM, Lori Alt wrote: > Kyle McDonald wrote: >> On 4/12/2010 3:01 PM, Lori Alt wrote: >> >>> On 04/12/10 11:50 AM, Darren J Moffat wrote: >>> >>>> On 12/04/2010 18:38, Tim Haley wrote: >>>> >>>>> 4.1. Proposal >>>>> >>>>> A new temporary mount property will be defined for the "zfs mount" >>>>> command. >>>>> Currently, the -o option to "zfs mount" can be used to set temporary >>>>> values for the following properties: devices, exec, readonly, setuid, >>>>> and xattr. It will now be possible to assign a temporary "mountpoint" >>>>> property. The file system will be mounted at the temporary mountpoint >>>>> and the persistent "mountpoint" property for the dataset will not >>>>> change. >>>>> >>>> Does this also allow the following to work without changing to legacy >>>> mountpoint: >>>> >>>> # mount -F zfs tank/a /mnt >>>> >>>> >>> I was sticking to the notion that legacy mounts work with the "legacy" >>> mountpoint only. So this would not be supported. This was an attempt >>> to be conservative about temporary mount support in an attempt to >>> limit its use to narrow circumstances, where the mechanism and its >>> constraints are well-understood. >>> >>> For example, ZFS legacy mounts can be performed on non-empty >>> directories. ZFS native mounts (and I consider a temporary mount to >>> be a native ZFS mount) cannot be performed on non-empty directories. >>> I didn't want to mix up the code paths between the legacy mount path >>> and the ZFS mount path and I didn't want the two types of mounts to >>> get confused, since they have different constraints. >>> >>> >> I'd really like this to work. >> >> For me currently 'legacy' really means "mounted through /etc/vfstab". I >> prefer if this was even more true, in that any ZFS filesystem could be >> mounted manually wherever you like using this traditional syntax (should >> the user even need to know that a filesystem is ZFS?) with out jumping >> through aditional hoops. >> > > I take your point, but I think "legacy" means more than "mounted > through /etc/vfstab". Also, a change that makes temporary zfs mounts > easier to use and more commonly used isn't necessarily a feature in my > mind. We really don't WANT temporary mounts to be used casually and > commonly. The zfs mount mechanism that already exists should > continue to be the normal and most commonly-used way to mount zfs file > systems.
I have to disagree. The name 'legacy' implies that you foresee a day when /etc/vfstab disappears, or at least is no longer used. would you also get rid of the 'mount' command? That's impossible. While 'neat' putting things like 'mount' and 'share' as built-ins to ZFS is really backwards, and non-productuve since they only manage ZFS filesystems. If mount, /etc/vfstab, share, /etc/dfs/dfstab, and sharemgr can manage everything, including ZFS, why as an admin would I also want to spend time learning, or using, or have to remember how to use 'zfs mount', 'zfs set', and 'zfs share' also? What advantages do the ZFS commands get me? For Filesystems types that mount can figure out on it's own, why should a user or admin have to know that this filesystem is ZFS and should use one mount command, while all others use 'mount'? What do I lose by continuing to use the 'legacy' commands? At the moment I can only see things I lose by using the ZFS commands - In addition to the losing the convience of using a single command to manage all filesystems on a level playing field, I lose the ability to control the order in which my filesystems are mounted and shared. ZFS is not the only Filesystem that needs to be mounted automatically at boot time. And I don't see it being the only one anytime soon. CD's/DVD's/BD's at least will be around virtually forever, and many people like me will need to mount (through lofi) those at boot time too. I'm currently forced to use 'legacy' on a few of my ZFS filesystems. They contain many ISO's which /etc/vfstab needs to be able to mount at boot. To do this (since ZFS's mounts aren't integrated with vfstab processing) I need to use 'legacy' mounting and mount the ZFS filesystem first in vfstab. That's fine really. but if I'm going to do those few, why not do them all in /etc/vfstab? I need to do this with more ZFS filesystems also since I want to mount these ISO's as subdirectories of my ZFS filesystems. For this reason I'm considering making all my ZFS filesystems 'legacy' in order to centralize management in one single place for everything. Ditto with sharing things. I need to share all thes ISO mountpoints. I can only do that with 'sharemgr'. In sharemgr I can easily group and manage related shares. If I use ZFS's share options, then all the FS's end up in the 'zfs' sharemanger group, and I no longer can organize them the way I need to work with them. For this reason, and just so that I can manage everything with one tool, I share all my filesystems ZFS or not, with sharemger, and I'll never use ZFS's share command. I guess I just don't understand, why you'd want to not take the chance to make a well known UNIX command like mount "just work" (least surprise) for ZFS filesystems like it does for everything else. Heck if you did you could also (since /etc/vfstab processing runs first, and it runs using mount) eliminate the need for setting mountpoint=legacy, since anythign I configure in /etc/vfstab would be mounted at boot using mount and would "just work". I love ZFS. I think all the great new things it's adding to Solaris are awesome. But I don't understand the urge to build into it parallels to all the existing UNIX commands that everyone knows, instead of making those commands just workk seamlessly with ZFS. Especially when there are no obvious user visible benefits, and in fact several user visible detriments to doing so. -Kyle > Temporary mounts really should be used for short-term, focused > purposes, like updating a BE other than the active one. > > That, plus the fact that I still think we want to avoid blurring the > line between ZFS mounts and temporary mounts, makes me we should stick > with the clear distinction that temporary mounts are NOT legacy mounts > and so the legacy mounting mechanism will not be supported. > > Lori > _______________________________________________ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
