Submounting Filesytem Issues?

[Jeff McKenzie]

The DBA wants a new filesystem mounted at /opt/oracle. HP-UX already has an /opt filesystem, so I would be mounting a filesytem on a mounted filesystem. This seems to be asking for trouble for at least the following reasons:

1. Dependencies between /opt and /opt/oracle. I will have to unmount /opt/oracle before unmounting /opt. Likewise, /opt/oracle won't mount unless /opt is mounted.

2. What about online JFS filesystem resizing with a mounted filesytem below it? Will fsadm refuse to defrag/resize/etc.?

What other issues are there? All ideas and input appreciated.

[Patrick Wallek]

Not really any issues.

Online JFS doesn't care. YOu just have to make sure you specify the correct filesystem when doing a resize.

If you think about it, all filesystem are submounted. You have the '/' mountpoint and then all other filesystem (/usr, /opt, /var, etc....) mounted on under '/'.

[A. Clay Stephenson]

In a sense, every filesystem except / has a filesystem mounted below it. You do have to be concerned with the order of mounting but other than that there are no problems. All of your filesystem maintenance commands will continue to function. Consider the case of /var. It is very common to have many filesystems mounted beneath it. /var/tmp, /var/mail, /var/spool -- which makes the critical filesystem /var much less likely to fill up and bring the system down and spreads io among several devices.

[DCE]

This is an accepted practice - the system does not really care.

One caveat - if you use an existing directory to mount a new lvol, whatever is in that directory will "disappear" a listing will show the contents of the mounted lvol. Once the lvol is unmounted the "old data" will re-appear.

[Dennis Handly]

>DCE: if you use an existing directory to mount a new lvol, whatever is in that directory will "disappear"

Right. But you can still see that directory if you mount it to a different machine.