Nested File Systems...

[Brian King]

I truly believe that it is bad practice to get in the habit of mounting a file system to a mountpoint that is part of another mounted file system. For example:

Regular mounted file system:

/dev/vg01/lvol5 --> /data

That's normal and acceptable. But this is bad practice:

/dev/vg01/lvol5 --> /data
/dev/vg01/lvol6 --> /data/newvol

If this is not bad practice and is perfectly acceptable - then let me know, but I don't think so. Also, if you support this as being bad practice, can you point me to some documentation that also supports this as being bad practice.

Thanks

[A. Clay Stephenson]

Well, if you take your view to the extreme then the only filesystem you want is / because every other filesystem is mounted off of it. The key here is to keep things to a reasonable level. It's very common (and good practice), for example, to split /var into several filesystems (e.g. /var/tmp, /var/spool, /var/mail, /var/adm/sw). This might be done for performance reasons - to better spread the i/o; it might be done for ease of maintenance reasons; it might also be done for space availability reasons. Moreover, perhaps more than any other filesystem, you absolutely want to avoid filling /var because that will bring a box to its knees.

In the old days, with traditional s5 filesystems, one was definitely encouraged to keep the mount trees as short as possible but modern filesystems handle this much better -- as long as one restricts oneself to a "reasonable level". I'll define "reasonable" to no more than 3 levels. I doubt very much using the example you cited that there would be any measurable performance difference.

The one restriction is that one must be certain of the mount order of nested filesystems.

[Alan Meyer_4]

I do remember having most all the Oracle and SAP data directories as nested mounts and it being recommended by Oracle & SAP to do so.

[TwoProc]

I prefer not to "submount" also. However, reality sets in for file systems that tend to get full much like A. Clay has mentioned. I would add Perfview (measureware) files to A. Clay's list (/var/opt/perf/datafiles).

[Mel Burslan]

It is not so much of a bad practice to mount filesystems nested in one another. It is a very bad practice not keeping track of it or too many people mangling the /etc/fstab file.

The failures due to filesystem nesting occurs, when an unknowing and careless sysadmin (wannabe) comes and starts "tidying-up" the fstab, with fancy alphabetical sorting etc. This is what gets you in trouble, not the actual nesting itself.

As one of the posts above indicated, some large software implementations actually encourage this to maintain application supportability. I actually dare you to ask any SAP consultant to break-up their mountpoint structure. They will scream bloody murder to oblivion. So, you have to live with it or learn to live with it. Once in this territory, keep a tab on the fstab by setting cronjobs, tripwires etc. to monitor the well-intended but ill-executed modifications.

[Devender Khatana]

Hi,

You perception is not correct and this is infact a good practice. As stated ealier system started migrating to this because of the flexibility available. Very older systems HPUx 9.x use to have only one root file system mounted on /. In these days there use to be problems of file system filling up as in that case / use to have everything including tmp and log files which always grow.

Then came the technology of seperating file systems to avoid such problems and allthough the option of having single root including all other file systems is still there nobody uses that.

Same option with some less priority applies here as well. It is still recommended to have one file system dedicated to one particular application itself but on the other part one application can have more than one file systems always, which is the case here.This also gives an option to overcome from some space problems without major changes.

HTH,
Devender

[Brian King]

Thanks all - I'm still not 100% comfortable with this practice, but I'm glad to know that there are no technical issues with doing this.