help-hurd
[Top][All Lists]
Advanced

[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    address@hidden
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
address@hidden
http://www.marcus-brinkmann.de/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]