On Thu, 12 May 2005 23:48:07 GMT, Darren Dunham
>> Sorry for the muddy view. 'data' was the mount point for a qtree from
>> a NetApp. Then the qtree is broken up into 2 qtrees, fs1 and fs2.
>> Now I try and mount these 2 qtrees under the old autofs mount point of
>> data at fs1 and fs2, but the issue I mentioned requires 2 runs of
>> automount to do it.
>So /data *used* to be an automount point, but I dan't tell from your
>description if it still is or if you've gotten rid of it.
>Is autofs still managing /data or is that simply a normal directory?
>Are these direct or indirect maps? Have you restarted the automounter?
>Can you post your automount maps that relate to data and the two fs
>filesystems? Can you run 'df -k /path/to/data' to see what the system
>thinks of that directory?
>> I'm attempting to keep the same path prefix but move the mounts 1
>> level down.
>Should be easy. Remove the references to data, restart the automounter
>so data becomes a normal directory, add the fs1/fs2, create the
>directories for them to mount onto and run automount.
Ok, so that's the part we're trying to avoid; a 2 step process. We
can get the new mounts if we run it twice, but we're thinking having
to do that is a bug somehow. Maybe not.
I can't post the specific entries but here's the logical map:
/path/to/data -rw,noquota filerA:/vol/vol1/data
Then we break that qtree into 2 and do:
/path/to/data/fs1 -rw,noquota filerA:/vol/vol1/data1
/path/to/data/fs1 -rw,noquota filerB:/vol/vol1/data2
data is now just a path placeholder where before it was the mount
If we make the change in the map in one shot it requires automounter
to be run twice, but this jacks with our configuration management and
requires a hack. As you mention if you make the change in 2 shots it
works, but that then leads to a long delay for both propogations.
Neither are optimal, but if that's the way it is then that's the way
it is. It just seemed this should not be the normal behavior.