Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

NFS mounting a directory of symbolic links to other directories



On 02/25/2009 12:03 PM, Ben Eisenbraun wrote:
> When I say that hard links can't cross file system boundaries, I mean=20
> the linked files have to be on the same file system on the same partiti=
on=20
> on the same physical disk (lvm and RAID notwithstanding).  They can't=20
> just be mounted in the same directory tree.
>  =20
A hard link is an entry in an inode. If you have 2 directories that are=20
on the same file system (meaning the same partition in PC speak) they=20
share the same inode. But, if those same two directories are exported=20
separately, on a system that imports them, they will be different file=20
systems. Example:
on the system where the directories reside:
/foo/bar and /foo/fubar exists, and in your exports you export /foo/bar=20
and /foo/fubar.

On your NFS client you mount host:/foo/bar on /foo/bar and=20
host:/foo/fubar on /foo/fubar. On the NFS client they will NOT be part=20
of the same file system.


On Unix systems, /usr/bin/vi is hard linked to /usr/bin/view (and=20
others). On Linux, they are usually symbolic links. If /usr is a mounted =

filesystem the hard links will continue to fork because vi and view are=20
both in the /usr file system, even if /usr is imported because the /usr=20
file system will have its own inode table even if it is an NFS file=20
system. I'm trying to keep this reasonably simple.

Directories are interesting animals because every subdirectory has a=20
hard link to its parent (.. - / is an exception). When you mkdir, that=20
subdirectory will have a hard link to itself and the parent. An empty=20
directory always has a link count of 2 (the name it was created under=20
and itself (.)).

--=20
Jerry Feldman <gaf-mNDKBlG2WHs at public.gmane.org>
Boston Linux and Unix
PGP key id: 537C5846
PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB  CA3B 4607 4319 537C 5846








BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org