I am in the process of beefing up our development environment. In essence I am really going simply replicate what we have spread across here and there (that what happens when you keep running out of disk space). Unfortunately, I inherited all of this and the guy who dreamed up the conflagration is lonnnggg gone. So here the way it works today. There are two top level directories called GroupWS and ReleaseWS. The auto mount map (auto.ws) looks like this: Upgrades chekov:/mnt/dsk1/GroupWS/& cstools chekov:/mnt/dsk1/GroupWS/& com chekov:/mnt/dsk1/GroupWS Integration chekov:/mnt/dsk1/GroupWS/& Everything is fine. Do a cd to /ws/Integration and you are taken to chekov:/mnt/dsk1/GroupWS/Integration. The directory Integration is a real directory that lives in GroupWS. If you cd to /ws/com, you are taken to chekov:/mnt/dsk1/GroupWS and then you can move about as one sees fit. To replicate this in ZFS, I did the following; 1) Parked all of the drives (except c1t0d0 and c1t1d0) into several RAIDZ configurations in a zpool called dpool. 2) Created a file system called dpool/GroupWS and set the mountpoint to /mnt/zfs1/GroupWS. The sharenfs properties were set to sharenfs=rw,log,root=msc-servers. 3) Next I created another file system called dpool/GroupWS/Integration. Its mount point was inherited from GroupWS and is /mnt/zfs1/GroupWS/Integration. Essentially I only allowed the new file system to inherit from its parent. 4) I change the auto.ws map thusly: Integration chekov:/mnt/zfs1/GroupWS/& Upgrades chekov:/mnt/zfs1/GroupWS/& cstools chekov:/mnt/zfs1/GroupWS/& com chekov:/mnt/zfs1/GroupWS Now the odd behavior. You will notice that the directories Upgrades and cstools are just that. Directories in GroupWS. You can cd /ws/cstools from [b][i]any server[/b][/i] without a problem. Perform and ls and you see what you expect to see. Now the rub. If on chekov, one does a cd /ws/Integration you end up in chekov:/mnt/zsf1/GroupWS/Integration and everything is great. Do a cd to /ws/com and everything is fine. You can do a cd to Integration and everything is fine. But. If you go to another server and do a cd /ws/Integration all is well. However, if you do a cd to /ws/com and then a cd Integration, Integration is EMPTY!! I know this was long winded but it is a strange problem. The workaround is to destroy the dpool/GroupWS/Integration file system and recreate as a regular directory un GroupWS. But i was hoping to be able to use fle systems in this way for snapshot ease. Any ideas? Thanks, Doug -- This message posted from opensolaris.org
On Wed, Oct 1, 2008 at 3:42 AM, Douglas R. Jones <doug.jones at genband.com> wrote: ...> 3) Next I created another file system called dpool/GroupWS/Integration. Its mount point was inherited from GroupWS and is /mnt/zfs1/GroupWS/Integration. Essentially I only allowed the new file system to inherit from its parent. > 4) I change the auto.ws map thusly: > Integration chekov:/mnt/zfs1/GroupWS/& > Upgrades chekov:/mnt/zfs1/GroupWS/& > cstools chekov:/mnt/zfs1/GroupWS/& > com chekov:/mnt/zfs1/GroupWS > > Now the odd behavior. You will notice that the directories Upgrades and cstools are just that. Directories in GroupWS. You can cd /ws/cstools from [b][i]any server[/b][/i] without a problem. Perform and ls and you see what you expect to see. Now the rub. If on chekov, one does a cd /ws/Integration you end up in chekov:/mnt/zsf1/GroupWS/Integration and everything is great. Do a cd to /ws/com and everything is fine. You can do a cd to Integration and everything is fine. But. If you go to another server and do a cd /ws/Integration all is well. However, if you do a cd to /ws/com and then a cd Integration, Integration is EMPTY!! > > Any ideas?Well, I guess you''re running Solaris 10 and not OpenSolaris/SXCE. I think the term is mirror mounts. It works just fine on my SXCE boxes. Until then, the way we got round this was to not make the new filesystem a child. So instead of: /mnt/zfs1/GroupWS /mnt/zfs1/GroupWS/Integration create /mnt/zfs1/GroupWS /mnt/zfs1/Integration and use that for the Integration mountpoint. Then in GroupWS, ''ln -s ../Integration .''. That way, if you look at Integration in /ws/com you get to something that exists. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
>>>>> "pt" == Peter Tribble <peter.tribble at gmail.com> writes:pt> I think the term is mirror mounts. he doesn''t need them---he''s using the traditional automounter, like we all used to use before this newfangled mirror mounts baloney. There were no mirror mounts with the old UFS NFSv3 setup that he inherited, and it worked fine. Maybe mirror mounts are breaking the automounter? I think someone who knows the automounter better than I could explain it, but one thing you migh try is to make the server and client''s filesystems similarly-nested. Right now you have: /ws/com /mnt/<...>/GroupWS /ws/Integration /mnt/<...>/GroupWS/Integration /ws/cstools /mnt/<...>/GroupWS/cstools /ws/Upgrades /mnt/<...>/GroupWS/Upgrades so, /ws/{Integration,cstools,upgrades} are decendents of /ws/com on the server, but not the client. This may break some assumption that the automounter needs to function, an assumption which I don''t have enough experience and wit to state quickly and explicitly but suspect might exist. Why not change to: /ws/com /mnt/<...>/GroupWS/com /ws/Integration /mnt/<...>/GroupWS/Integration /ws/cstools /mnt/<...>/GroupWS/cstools /ws/Upgrades /mnt/<...>/GroupWS/Upgrades or: /ws/com /mnt/<...>/GroupWS /ws/com/Integration /mnt/<...>/GroupWS/Integration /ws/com/cstools /mnt/<...>/GroupWS/cstools /ws/com/Upgrades /mnt/<...>/GroupWS/Upgrades and update the auto.ws map to match whichever you pick. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 304 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20081001/9e4b520c/attachment.bin>
On Wed, Oct 01, 2008 at 01:30:45PM +0100, Peter Tribble wrote:> On Wed, Oct 1, 2008 at 3:42 AM, Douglas R. Jones <doug.jones at genband.com> wrote: > > Any ideas? > > Well, I guess you''re running Solaris 10 and not OpenSolaris/SXCE. > > I think the term is mirror mounts. It works just fine on my SXCE boxes. > > Until then, the way we got round this was to not make the new > filesystem a child. > > So instead of: > > /mnt/zfs1/GroupWS > /mnt/zfs1/GroupWS/Integration > > create > > /mnt/zfs1/GroupWS > /mnt/zfs1/IntegrationNo, that''s not the workaround. The problem is that the automounter -hosts map does a MOUNT call once to get the list of exports from the server, and that means that filesystems added since the first mount via /net will not be visible. Mirror mounts solves *that* problem. And it fixes the poster''s problem as well. The poster isn''t using the -hosts automount map, so his workaround is to create "hierarchical" automount map entries. See automount(1M).> and use that for the Integration mountpoint. Then in GroupWS, ''ln -s > ../Integration .''.That works, but hierarchical automount map entries work better. Nico --
On Wed, Oct 01, 2008 at 01:12:08PM -0400, Miles Nordin wrote:> >>>>> "pt" == Peter Tribble <peter.tribble at gmail.com> writes: > > pt> I think the term is mirror mounts. > > he doesn''t need them---he''s using the traditional automounter, like we > all used to use before this newfangled mirror mounts baloney.Oh man, I *love* mirror mounts -- they''re *not* "baloney."> There were no mirror mounts with the old UFS NFSv3 setup that he > inherited, and it worked fine. Maybe mirror mounts are breaking the > automounter?Doubtful. There is a race condition in mirror mounts that can cause one or more of several threads racing to cause a mirror mount to happen to get an error. Usually you see that when running dmake. Otherwise mirror mounts work perfectly.> I think someone who knows the automounter better than I could explain > it, but one thing you migh try is to make the server and client''s > filesystems similarly-nested. Right now you have:Yes, the OP needs hierarchical automount map entries. Nico --
Douglas R. Jones wrote:> 4) I change the auto.ws map thusly: > Integration chekov:/mnt/zfs1/GroupWS/& > Upgrades chekov:/mnt/zfs1/GroupWS/& > cstools chekov:/mnt/zfs1/GroupWS/& > com chekov:/mnt/zfs1/GroupWS > >This is standard NFS behavior (prior to NFSv4). Child Filesystems have to be mounted on the NFS client explicitly. As someone else mentioned, NFSv4 has a feature called ''mirror-mounts'' that is supposed to automate this for you. For now try this: Integration chekov:/mnt/zfs1/GroupWS/& Upgrades chekov:/mnt/zfs1/GroupWS/& cstools chekov:/mnt/zfs1/GroupWS/& com / chekov:/mnt/zfs1/GroupWS \ /Integration chekov:/mnt/zfs1/GroupWS/Integration Note the \ line continuation character. The last 2 lines are really all one line. If you had had ''Integration'' on it''s own ufs or ext2fs filesystem in the past, but still mounted below ''GroupWS'' you would have seen this in the past. It''s not a ZFS thing, or a Solaris thing. -Kyle
First of all let me thank each and everyone of you who helped with this issue.
Your responses were not only helpful but insightful as well. I have been around
Unix for a long time but only recently have I had the opportunity to do some
"real world" admin work (they laid off or had quit those who were
doing this before me) i am just a code jockey.
Anyway the answer turned out to be hierarchical automounting. I really did not
know the difference between direct and hierarchical before. What eventually
worked was demonstrated by Kyle.
In the end, the auto.ws map looks like:
Integration chekov:/mnt/zfs1/GroupWS/&
Upgrades chekov:/mnt/zfs1/GroupWS/&
cstools chekov:/mnt/zfs1/GroupWS/&
com / chekov:/mnt/zfs1/GroupWS \
/Integration chekov:/mnt/zfs1/GroupWS/Integration
And it appears to be working fine one I slapped the autofs.
Thanks again for the help!
Doug
--
This message posted from opensolaris.org