> > The removal of /etc/mtab in favor of /proc/mounts is a new requirement,
> > and is not as trivial as you might hope. Internally the NFS client
> > represents the mount options as a binary data structure, and it contains
> > only the information that has traditionally been passed into the ke
> On Tue, 2007-07-31 at 17:16 -0400, Chuck Lever wrote:
> > Miklos Szeredi wrote:
> > > It would be nice to have all this stuff in 2.6.24, which doesn't leave
> > > a lot of time.
> >
> > Yes, that would be nice, but there's a lot of stuff that needs to get
> > done before this. NFS IPv6, for ex
On Tue, Jul 31, 2007 at 10:19:57AM -0400, Chuck Lever wrote:
> The removal of /etc/mtab in favor of /proc/mounts is a new requirement,
> and is not as trivial as you might hope. Internally the NFS client
> represents the mount options as a binary data structure, and it contains
> only the infor
On Tue, 2007-07-31 at 17:16 -0400, Chuck Lever wrote:
> Miklos Szeredi wrote:
> > It would be nice to have all this stuff in 2.6.24, which doesn't leave
> > a lot of time.
>
> Yes, that would be nice, but there's a lot of stuff that needs to get
> done before this. NFS IPv6, for example, is a hi
Miklos Szeredi wrote:
After a successful mount, the NFS mount command tucks some options into
/etc/mtab that reflect which mountd was used for the mount, and what
protocol version and port was used for the mount request. Those options
are not passed to the kernel, and do not appear in /proc/mo
> >> After a successful mount, the NFS mount command tucks some options into
> >> /etc/mtab that reflect which mountd was used for the mount, and what
> >> protocol version and port was used for the mount request. Those options
> >> are not passed to the kernel, and do not appear in /proc/mount
Miklos Szeredi wrote:
After a successful mount, the NFS mount command tucks some options into
/etc/mtab that reflect which mountd was used for the mount, and what
protocol version and port was used for the mount request. Those options
are not passed to the kernel, and do not appear in /proc/mo
> After a successful mount, the NFS mount command tucks some options into
> /etc/mtab that reflect which mountd was used for the mount, and what
> protocol version and port was used for the mount request. Those options
> are not passed to the kernel, and do not appear in /proc/mounts today.
>
Miklos Szeredi wrote:
Some mount options are never passed to the kernel, and thus can't appear
in /proc/mounts. Examples include user, users, and _netdev for NFS.
These options control *who* may mount and *when* to mount. They are
not a property of the mount itself and are not added to /etc/
[cc trim on purpose, just autofs interest here]
On Jul 28 2007 14:45, Ian Kent wrote:
>
>Oh .. sorry, I wasn't paying enough attention.
>
>But now might be a good time to propose the removal of autofs and rename
>autofs4 to autofs. I would need to provide some way to map autofs4
>module load reque
On Fri, 2007-07-27 at 17:40 +0200, Miklos Szeredi wrote:
> > all - fs has options, but doesn't define ->show_options()
> > some - fs defines ->show_options(), but some options are not shown
> > noopt - fs does not have options
> > good - fs shows all options
> > patch - I have a patch
>
> >> Some mount options are never passed to the kernel, and thus can't appear
> >> in /proc/mounts. Examples include user, users, and _netdev for NFS.
> >
> > These options control *who* may mount and *when* to mount. They are
> > not a property of the mount itself and are not added to /etc/mta
Miklos Szeredi wrote:
Some mount options are never passed to the kernel, and thus can't appear
in /proc/mounts. Examples include user, users, and _netdev for NFS.
These options control *who* may mount and *when* to mount. They are
not a property of the mount itself and are not added to /etc/m
> Some mount options are never passed to the kernel, and thus can't appear
> in /proc/mounts. Examples include user, users, and _netdev for NFS.
These options control *who* may mount and *when* to mount. They are
not a property of the mount itself and are not added to /etc/mtab.
There's a "use
Miklos:
Some mount options are never passed to the kernel, and thus can't appear
in /proc/mounts. Examples include user, users, and _netdev for NFS.
Miklos Szeredi wrote:
[please consider pruning the CC list if discussing some aspect, which
doesn't concern all]
I've done an audit of all fil
> cifs and nfs (probably others) have some mount options which are mount
> order dependent ie may be invalid or ignored when you have more than
> one mount to the same server, or mount the same resource in two places
> with different options. In the long run, at least for cifs, we may be
> able to
cifs and nfs (probably others) have some mount options which are mount
order dependent ie may be invalid or ignored when you have more than
one mount to the same server, or mount the same resource in two places
with different options. In the long run, at least for cifs, we may be
able to better ha
> all - fs has options, but doesn't define ->show_options()
> some - fs defines ->show_options(), but some options are not shown
> noopt - fs does not have options
> good - fs shows all options
> patch - I have a patch
[...]
> > autofs all
>
> I'm not sure I understand this.
> How
On Fri, 2007-07-27 at 15:45 +0200, Miklos Szeredi wrote:
> [please consider pruning the CC list if discussing some aspect, which
> doesn't concern all]
>
> I've done an audit of all filesystems with regards to showing mount
> options in /proc//mounts. Unfortunately most of them show none
> or onl
> What do you consider the best example so far of a kernel module's
> equivalent of "parse_mount_options" (handling a mix of options of
> different types) and show_options.
For example gfs2 is pretty good. It has lots of different type of
options, and it handles them in remount as well as mount.
What do you consider the best example so far of a kernel module's
equivalent of "parse_mount_options" (handling a mix of options of
different types) and show_options.
On 7/27/07, Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> [please consider pruning the CC list if discussing some aspect, which
> doe
21 matches
Mail list logo
