[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: mtab (was: Re: path+file_name from port or process info?
From: |
Marcus Brinkmann |
Subject: |
Re: mtab (was: Re: path+file_name from port or process info? |
Date: |
Tue, 23 Jul 2002 14:15:17 +0200 |
User-agent: |
Mutt/1.4i |
On Mon, Jul 22, 2002 at 10:31:53PM -0400, David Walter wrote:
> >> 3. insertion of a new entry by using a utility program mtab_client.
> >> currently uses getline to read in a mount record. A mig definition
> >> file has been generated to create an insert of a record, the arguments
> >> are a string and the strings length. The record is parsed from the
> >> string using sscanf.
> >
> > It's better to not add a new interface if it is not needed.
>
> If this is to maintain compatibility with Posix/UNIX, shouldn't the
> mount command manage the insertion of records? If that is the case
> the rest of my issues disappear as well.
Well, I guess the mount command could add the --mtab PATH option to the
translator invocation.
The reason that mount should not add the record itself is that you really
want the translator to do it. If you read my proposal again, you will
find out that this is crucial to get the record removed automatically when
the translator dies.
> So anyway, my rationale was to separate the interface io interface.
> Thinking that by creating a single interface to update the table is
> cleaner. If not, oh well, I just learned somethings I didn't know how
> to do before.
A separate interface is probably less obscure, but it creates a barrier
between the Unix personality of the Hurd and the rest of the system. In
other words: You would need new tools to manipulate the mtab server. But
there is no need to have a new interface, all you want to do is to send a
string to it. And you send strings to programs with "write". So "write",
although it is generic, is exactly the right tool for the job.
The way you have in mind only leads to half a zillion incompatible
interfaces which all do the same job, sending a string to a server.
By using write, you immediately can use the normal command line programs
like "cat" to try out if your translator works.
> > In case you only need to transfer strings, why not make it part of the write
> > support? If a file is opened, the caller can write the string to it.
>
> Well in truth the first pass did this, I can comment out one line and
> make trivfs_support_write true, and have write support back, That is:
>
> echo /dev/hd0s1 / ext2 rw 0 0 > /var/run/mtab
>
> cat /var/run/mtab
> /dev/hd0s1 / ext2 rw 0 0
>
> df ...
>
> and so on.
Which is a start but not what I described. In this scheme it is very hard
to detect translator death. I see from the example output that mtab keeps
the record when the file is closed (because echo closes it), but it
shouldn't.
Root ("/") should always be included into the output.
The string that should be written to the mtab translator should be a
pathname, nothing else. The rest of the info is derived from fstab and
querying the fsysopts and storage info from the filesystem.
It should go like this:
Screen A Screen B
$ cat > /var/run/mtab
$ cat /var/run/mtab
/dev/hd0s1 / ext2 0 0
/mnt
$ cat /var/run/mtab
/dev/hd0s1 / ext2 0 0
/dev/hd0s2 /mnt ext2
/mnt2
$ cat /var/run/mtab
/dev/hd0s1 / ext2 0 0
/dev/hd0s2 /mnt2 ext2
^D
$ cat /var/run/mtab
/dev/hd0s1 / ext2 0 0
> > it. For each open that includes the writable bit, it accepts one line
> > written with a pathname. As long as the port is kept open, it will include
> > this pathname in its output. When the port is deallocated, the entry is
> > removed from the output. The filesystem will keep the file open as long as
> > they live (this way, we will get notified when the filesystem dies).
>
> This sounds like what I meant by notification.
Behind this is a no senders notification, yes.
> > The translator can write another line to the file, and then it will replace
> > the older one in the output.
>
> Who controls when this is done?
The user can do this by using fsysopts:
fsysopts /foo/mnt
/hurd/ext2fs --mtab /foo/mnt
mv /foo /bar
fsysopts /bar/mnt --mtab /bar/mnt
It's unfortunate that this is not atomic.
> >> Problem:
> >>
> >> I can't find a way to determine the mount point reliably in a
> >> translator, as it's cwd isn't necessarily the same at startup as the
> >> node for which it translates.
> >
> > It's cwd is completely unusable, esp for passive translators.
>
> Does it not even know the inode that it is on? If it did can't it
> walk up the dir tree.
Sure it knows the inode, because it gets a port to its underlying node when
attaching itself to it.
Have you looked at _hurd_canonicalize_directory_name_internal? Because that
is trying to walk up the tree.
However, this is only a honest attempt at it. There is no requirement that
it works, nor that the resulting path name is one that the mtab translator
can use to determine the filesystems path! Because the mtab translator
might see a different filesystem world than the translator.
There is another thing that can go wrong, which was already shown in the
above example. If a translator is moved (for example, because the parent
dir was renamed), there is no easy (and definitely no reliable) way for a
translator to detect that.
All of this is an uphill battle against a deep design mistake in
the mtab concept. I mean, it is even broken in Unix:
ulysses:/tmp# mkdir /tmp/foo/mnt
ulysses:/tmp# mount /dev/hda6 /tmp/foo/mnt
ulysses:/tmp# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/hda2 4134932 3620324 304560 93% /
/dev/hdc2 5064135 4620397 391302 93% /mnt
/dev/hda3 1035692 987168 0 100% /gnu
/dev/hda6 1011928 33800 926724 4% /tmp/foo/mnt
ulysses:/tmp# mv /tmp/foo /tmp/bar
ulysses:/tmp# LC_ALL=C df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/hda2 4134932 3620324 304560 93% /
/dev/hdc2 5064135 4620397 391302 93% /mnt
/dev/hda3 1035692 987168 0 100% /gnu
df: /tmp/foo/mnt': No such file or directory
Well, at least in Linux in /proc/mounts one can find the correct
information.
> Meaning, I suppose that there is no need to extend the interface? In
> that case wouldn't it make sense to have mount do this.
Please see above, and if there is still a doubt, specify what you mean with
"have mount do this" in terms of filesystem actions.
> > Having an option --mtab has the advantage that you only see
> > filesystems that are configured to be included in the output. You
> > don't want all filesystems to register themself.
>
> I don't see why not?
You want all /dev/* nodes listed in there, for example?
Or things firmlinks (and, by extension, symlinks etc)?
Or things like ftp filesystems?
> Or rather, it seems like the reverse would be
> preferable. To make the exceptional case be a --no-mtab option to the
> translator to not include it, then when testing or working without
> permissions to update the system mtab, the person can choose not to
> include it for testing. Then mounts of system are automatically
> registered, whether mount is used with user mounts from /etc/fstab.
It might be a useful default for diskfs based filesystems. And it might be
useful to try to determine the path by going up the directory tree.
> > Also, you should make write permission on the node restrictive,
> > because only system filesystems should be in /etc/mtab. User
> > filesystems can be in ~/.mtabrc or sim.
>
> Don't these permissions match the decisions of mount and the records
> of fstab?
I can't parse that.
> Should mount control the insertions?
Definitely no. You only want to see live filesystems there, and for passive
translators that means that they have to register themselve at startup.
> >> As a temporary kludge I have added a settrans call in /libexec/rc. I
> >> notice that this deletes all files in /var/run on startup. Thus this
> >> translator doesn't exist across reboots. Will a production GNU system
> >> run
> >> settrans -cap /var/run/mtab /hurd/mtab
> >>
> >> at each system startup?
>
> > Only if /var/run is the place to put it into, and we remove all files in
> > there. ;)
>
> Okay, seems like I'm playing 20 questions with this one. If df looks
> in /var/run/mtab is that where it goes on a GNU system or is df
> broken? :)
_PATH_MOUNTED is /var/run/mtab, so that seems to be the place. Unless we
change it in glibc :) We will have the same issue with utmp. So I think it
is correct not to clear this file if it is a translator, or to clear it and
recreate the translator setting.
> >> I haven't figured out notification yet, if anyone has tips, pointers,
> >> example code I will be happy to have them.
> >
> > If you use write support, the normal close hook is the way to go.
>
> I don't understand, why use a close hook, why not use the
> trivfs_S_io_write? Wait a minute? Here do you mean that when the
> translator calls it's close hook it removes it's entry?
Yes.
> But that
> contradicts the design that you suggested where the mtab translator
> monitors the control port of the filesystems it has registered?
I never said that.
What I said is that a path is written to the open file, and that the path is
opened by mtab and queried for things like filesystem options and backing
store.
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' GNU http://www.gnu.org marcus@gnu.org
Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de/
- path+file_name from port or process info?, David Walter,,,, 2002/07/22
- mtab (was: Re: path+file_name from port or process info?, Marcus Brinkmann, 2002/07/22
- Re: mtab (was: Re: path+file_name from port or process info?, David Walter, 2002/07/22
- Re: mtab (was: Re: path+file_name from port or process info?,
Marcus Brinkmann <=
- Re: mtab (was: Re: path+file_name from port or process info?, Marcus Brinkmann, 2002/07/23
- Re: mtab (was: Re: path+file_name from port or process info?, David Walter, 2002/07/25
- Re: mtab (was: Re: path+file_name from port or process info?, Marcus Brinkmann, 2002/07/25
- Re: mtab (was: Re: path+file_name from port or process info?, Alfred M. Szmidt, 2002/07/25
- Re: mtab (was: Re: path+file_name from port or process info?, David Walter, 2002/07/25
- Re: mtab (was: Re: path+file_name from port or process info?, Marcus Brinkmann, 2002/07/25