Summary:: Update: mount directory mount point

From: Bugs (bb1_at_humboldt.edu)
Date: 06/08/05

  • Next message: Iain Barker: "SUMMARY: Kernel panic during shutdown/reboot with Tru64 5.1b-3 (PK5)"
    Date: Wed, 08 Jun 2005 08:56:56 -0700 (PDT)
    To: Tru64-UNIX-Managers <tru64-unix-managers@ornl.gov>
    
    

    Thanks to Dr.Blinn for clearifying that the remedy that
    I first requested was not so simple. I got notification
    from the departments involved that they will change their
    scripts, but still requested my workaround in the interem.
    I dont anticipate that the /local/bin/pwd tcsh script will
    break anything, but you never know.

    Thanks much.

    Bugs

    Operating Systems Analyst for unix systems
    Humboldt State Univ. Information Technology Services
    Arcata, Calif.

    email bb1@humboldt.edu

    ---------- Forwarded message ----------
    From: "Dr Thomas.Blinn@HP.com" <tpb@doctor.zk3.dec.com>

    Very clear explanation. Alas, Tru64 UNIX doesn't have the same
    features in this area as Linux.

    You could, in principle, replace /bin/pwd (assuming that that's
    used universally) with a script or program that knows that if
    it can find a symlink by stripping off /home that leads to the
    current directory, it should display the path by stripping off
    that much of the leading path. But that's bizarre..

    The right fix is really to change the things that are checking
    for the absolute path to know a list of valid paths, but that
    would have been easier up front, and no one anticipated this
    change in layouts.

    There is no simple solution to the problem. The approach you
    used of having the symlink from the old location that leads to
    the real new location is very much the "UNIX way", but there
    are cases (pwd notably) where that doesn't work, and what an
    application really wants to know is either (a) how it got to
    where it presently is, that is, more or less what "cwd" does
    in some shells, or (b) the simplest path that gets it to its
    current real location from the root, even if that path is by
    use of a symbolic link instead of a real directory tree.

    Since this is an application problem, it's really up to the
    applications (e.g., scripts) to solve it. You can offer a
    few ways that help, but there's no simple method to make it
    totally transparent, at least none that I know of on Tru64
    UNIX.

    Tom

    > I have been requested to make myself more clear, and
    > give my problem rather than ask for a solution.
    > I appologize for my vagueness.
    >
    > We just migrated a server from an alpha 2100 (hostA)
    > to an ES40 (hostB).
    > There were 4 filesystems on hostA that were placed as
    > subdirectories on hostB:
    > hostA:
    > df
    > /dev/disk/dsk1g 5878109 2759618 2824585 50% /u
    > /dev/disk/dsk4g 12183434 7872959 3701303 69% /bhome1
    > /dev/disk/dsk8g 12183434 3461371 7503719 32% /ohome1
    > /dev/disk/dsk9g 8057740 4838990 2815863 64% /tech
    >
    > hostB:
    > df
    > laurel#home 54730624 19492349 35113288 36% /home
    >
    > cd /home
    > ls -l
    > drwxr-xr-x 8 root system 8192 Sep 8 2004 bhome1/
    > drwxr-xr-x 6 root system 8192 Dec 16 2003 ohome1/
    > drwxr-xr-x 7 root system 8192 Dec 16 2003 tech/
    > drwxr-xr-x 140 root system 8192 May 31 09:14 u/
    >
    > On hostB, I created sym links so software would not break:
    > cd /
    > l1 -l
    > lrwxrwxrwx 1 root system 12 Oct 28 2004 bhome1@ -> /home/bhome1/
    > lrwxrwxrwx 1 root system 12 Oct 28 2004 ohome1@ -> /home/ohome1/
    > lrwxrwxrwx 1 root system 10 Oct 28 2004 tech@ -> /home/tech/
    > lrwxrwxrwx 1 root system 7 Oct 28 2004 u@ -> /home/u/
    >
    > The only thing that fails, is that some departments run nitely jobs
    > that test for "pwd", and it must equal what they expect to find
    > such as /u/jobs/bin. Instead, pwd displays /home/u/jobs/bin,
    > which causes their scripts to fail, and negate my advertisement
    > that this migration would be transparent.
    >
    > My only workaround so far is a script, /local/bin/pwd:
    > #!/bin/tcsh
    >
    > echo $cwd
    > exit
    >
    > This give the desired results, but some users will have to
    > add the path /local/bin before /bin in their scripts.
    > Their jobs are submitted from an in-house job scheduler that
    > su's to the user, to execute their script. The /etc/csh.login
    > already has that setup, but I dont think that gets sourced
    > by "non logged in" jobs.
    > I know that in linux, the "mount --bind" would work.
    >
    > I hope this explains my situation.
    > Thanks
    >
    > Below was my original request.
    >
    >
    > Tru64 5.1B PK4 on an ES40
    >
    > Hello,
    > I could not find the answer in the man pages, so here
    > is my question.
    > We wish to mount a subdirectory located in an advfs fileset
    > as its own mount point.
    >
    > oak_local#local 47529432 9093988 38369368 20% /local
    > there is a subdirectory called /local/student
    >
    > We would like to mount /student as its own mount point, even though
    > /home/student is already mounted.
    >
    > Is there is way of doing this?
    > Thanks...
    >
    >
    > Bugs
    >
    > Operating Systems Analyst for unix systems
    > Humboldt State Univ. Information Technology Services
    > Arcata, Calif.
    >
    > email bb1@humboldt.edu
    >


  • Next message: Iain Barker: "SUMMARY: Kernel panic during shutdown/reboot with Tru64 5.1b-3 (PK5)"