From: Andreas Dilger <adilger@turbolinux.com>
To: Alexander Viro <viro@math.psu.edu>
Cc: Andreas Dilger <adilger@turbolinux.com>,
Linux kernel development list <linux-kernel@vger.kernel.org>,
Linux FS development list <linux-fsdevel@vger.kernel.org>
Subject: Re: (struct dentry *)->vfsmnt;
Date: Wed, 14 Mar 2001 10:26:50 -0700 (MST) [thread overview]
Message-ID: <200103141726.f2EHQoj09856@webber.adilger.int> (raw)
In-Reply-To: <Pine.GSO.4.21.0103140146590.2506-100000@weyl.math.psu.edu> from Alexander Viro at "Mar 14, 2001 01:50:41 am"
Al writes:
> On Tue, 13 Mar 2001, Andreas Dilger wrote:
>
> > On AIX, it is possible to import a volume group, and it automatically
> > builds /etc/fstab entries from information stored in the fs. Having the
> > "last mounted on" would have the mount point info, and of course LVM
> > would hold the device names.
>
> Wait a minute. What happens if you bring /home from one box to another,
> that already has /home? Corrupted /etc/fstab?
The AIX vgimport will not corrupt /etc/fstab with duplicate mounts, nor for
that matter with duplicate LV names (AIX has a single namespace for all LVs).
If a conflict is found with an LV name, a new name like "lv01" is used (the
LV names are not that important anyways). I'm not sure what would
happen with a duplicate mount point (whether it would pick a new name, or
simply leave it out of /etc/fstab), but it isn't too hard to think of
easy ways to fix this (e.g. /home01 or /mnt/vgname/home or whatever).
It was really useful (i.e. easy to manage) to be able to move a bunch of
disks (making a whole volume group) from one system to another, import it,
and then not have to mount each filesystem to figure out what the contents
are before editing /etc/fstab to set up the correct mount point. In 99.9%
of the cases, the mountpoints were correct. I don't think you can ever
have a system that is 100% correct all of the time.
For AIX, the base filesystems in the rootvg (/, /usr, /var, /tmp, /home,
/boot, and swap) all moved as a single unit (sometimes /home was moved
out for systems that served lots of users). For data or application
specific filesystems, the normal practise was to put them into their own
volume group for backup, failover, etc. This made it easy to upgrade
systems, or move a critical application to another server in case of
hardware problems (whether manual or via HA auto failover).
> Let me put it that way: I don't understand why (if it is useful at all)
> it is done in the fs. Looks like a wrong level...
For the same reason that the UUID and LABEL are stored in the superblock:
you want this infomation kept with the filesystem and not anywhere else,
otherwise it will quickly get out-of-date. Wherever you mounted the
filesystem last is where it would be mounted if you import the VG on
another system. You can obviously edit /etc/fstab afterwards if it is
wrong, and then remount the filesystem(s), and this will store the
correct mountpoint into the filesystem for the next vgimport.
Cheers, Andreas
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert
next prev parent reply other threads:[~2001-03-14 17:29 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-09 23:20 LA Walsh
2001-03-10 1:00 ` Alexander Viro
2001-03-10 1:56 ` LA Walsh
2001-03-10 2:42 ` Alexander Viro
2001-03-14 1:28 ` Andreas Dilger
2001-03-14 2:32 ` Alexander Viro
2001-03-14 4:27 ` Andreas Dilger
2001-03-14 5:11 ` Alexander Viro
2001-03-14 5:19 ` Andreas Dilger
2001-03-14 5:49 ` Alexander Viro
2001-03-14 6:05 ` Andreas Dilger
2001-03-14 6:50 ` Alexander Viro
2001-03-14 17:26 ` Andreas Dilger [this message]
2001-03-14 17:40 ` Matthew Wilcox
2001-03-14 18:06 ` Andreas Dilger
2001-03-14 18:11 ` Alexander Viro
2001-03-14 19:14 ` Andreas Dilger
2001-03-14 19:32 ` Alexander Viro
2001-03-14 20:21 ` Ragnar Kjørstad
2001-03-14 19:31 ` Dave Kleikamp
2001-03-14 19:45 ` Andreas Dilger
2001-03-14 19:51 ` Alexander Viro
2001-03-14 19:57 ` Dave Kleikamp
2001-03-14 21:07 ` Andreas Dilger
2001-03-15 12:21 bsuparna
2001-03-15 12:59 bsuparna
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200103141726.f2EHQoj09856@webber.adilger.int \
--to=adilger@turbolinux.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@math.psu.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®