mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: bsuparna@in.ibm.com
To: Andreas Dilger <adilger@turbolinux.com>
Cc: Dave Kleikamp <shaggy@austin.ibm.com>,
	Andreas Dilger <adilger@turbolinux.com>,
	Alexander Viro <viro@math.psu.edu>,
	Linux kernel development list <linux-kernel@vger.kernel.org>,
	Linux FS development list <linux-fsdevel@vger.kernel.org>
Subject: Re: (struct dentry *)->vfsmnt;
Date: Thu, 15 Mar 2001 17:51:36 +0530	[thread overview]
Message-ID: <CA256A10.0044EAF4.00@d73mta03.au.ibm.com> (raw)



>Actually, I'm pretty sure you _never_ need to exportvg in order to have
>it work on another system.  That's one of the great things about AIX LVM,
>because it means you can move a VG to another system after a hardware
>problem, and not have any problems importing it (journaled fs also helps).
>AFAIK, the only think exportvg does is remove VG information from the
>ODM and /etc/filesystems.
>

Yes that's correct as far as I know too. The VGDA and LVCB contain all the
information required for import even without an exportvg.

>I suppose it is possible that because AIX is so tied into the ODM and
>SMIT, that it updates the VGDA mountpoint info whenever a filesystem
>mountpoint is changed, but this will _never_ work on Linux because of
>different tools versions, distributions, etc.  Also, it would mean on
>AIX that anyone editing /etc/filesystems might have a broken system at
>vgimport time (wouldn't be the first time that not using ODM/SMIT caused
>such a problem).

Yes, you can think of crfs (or chfs) as a composite command that handles
this (writing to LVCB. These are more like
administrative/setup/configuration commands -- one time, or occasional
system configuration changes.

On the other hand a mount doesn't cause a persistent configuration
information change. You can issue a mount even if an entry doesn't exist in
/etc/filesystems.

>
>> ... I do think that the LVM is a reasonable place to store this kind of
>> information.
>
>Yes, even though it would tie the user into using a specific version of
>mount(), I suppose it is a better solution than storing it inside the
>filesystem.  It will work with non-ext2 filesystems, and it also allows
>you to store more information than simply the mountpoint (e.g. mount
>options, dump + fsck info, etc).  In the end, I will probably just
>save the whole /etc/fstab line into the LV header somewhere, and extract
>it at importvg time (possibly with modifications for vgname and
mountpoint).
>
>Cheers, Andreas

Is mount the right time to do this ? A mount happens on every boot of the
system.
And then, one can issue a mount by explicitly specifying all the parameters
without having an entry in fstab. [Doesn't that also mean that you have a
possibility of inconsistency even here ?]




             reply	other threads:[~2001-03-15 12:34 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-03-15 12:21 bsuparna [this message]
  -- strict thread matches above, loose matches on Subject: below --
2001-03-15 12:59 bsuparna
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
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

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=CA256A10.0044EAF4.00@d73mta03.au.ibm.com \
    --to=bsuparna@in.ibm.com \
    --cc=adilger@turbolinux.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=shaggy@austin.ibm.com \
    --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®