bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: unionfs Documentation


From: Thomas Schwinge
Subject: Re: unionfs Documentation
Date: Tue, 4 Aug 2009 01:00:10 +0200
User-agent: Mutt/1.5.11

Hello!

On Fri, Jul 17, 2009 at 05:08:28AM +0200, olafBuddenhagen@gmx.net wrote:
> On Sat, Jun 13, 2009 at 09:23:23AM +0300, Sergiu Ivanov wrote:
> > I'm sending in my attempt to compile a unionfs documentation. It is
> > formatted as a stand-alone Texinfo file for now, so that I am able to
> > build and view .info files from it.
> 
> I don't understand -- why can't you just build it as part of the Hurd
> manual?

> do it as I asked
> you from the beginning: put it in the normal Hurd manual, where the
> "shadowfs" placeholder used to be.

I disagree: let's please put it into the unionfs repository and render
into a separate info file.  Sergiu, then please remove the shadowfs
reference(s) from the GNU Hurd Reference Manual.  unionfs is not an
integral core part of the GNU Hurd kernel infrastructure, even is held in
a separate repository, and thus doesn't really belong into the GHRM.  (Of
course I'm not saying that unionfs was an unimportant part for the
envisoned GNU system.)


Sergiu, please address Olaf's valid comments as much as you want, put the
unaddressed ones into the file (commented-out, like: ``Olaf Buddenhagen:
rather say s.th. like ...''), and put it into the unionfs repository.
Don't spend too much time on the build infrastructure; I'll take care of
that as soon as I do the overall Automake dance.


> > @item -u
> > @itemx --underlying
> > Add the underlying file system to the list of union mounted file
> > systems.
> > 
> > @item -w
> > @itemx --writable
> > Specify the following file system as writable. This makes it possible
> > to create new nodes in the specified file system.
> 
> Are these two really only possible on startup? Seems like a major
> limitation, which should be fixed...

If yes, then this is worth either a item in the Savannah task list, a new
*open issue* in the web pages, or an entry in a TODO file in the unionfs
repository.


> > @node Basic Internals
> > @chapter Basic Internals
> > @cindex internals, node, light node, conflict
> > 
> > In this chapter a short description of how @command{unionfs} works
> > will be done. This description is intended for people who have at
> > least a vague idea about GNU/Hurd translator programming.
> > 
> > Note that what follows is an overview of the basic functionality.
> 
> I don't think the introduction paragraphs are necessary.

Without having at all looked at them so far, why remove them?


> > @item
> > If there's a name conflict in underlying file systems between
> > directories (or between files), and the user has no permission to
> > delete all the entries -- e.g. one hidden entry is read-only -- then
> > he will get an @samp{EPERM} even if permissions seems ok. This is a
> > structural bug (there's no clean way to solve it), and should be
> > fixed.
> 
> I think both of these problems are actually a result of handling file
> deletion fundamentally wrong; or perhaps even handling writable entries
> wrong in general. It's probably never right to write to more than one
> directory at a time.
> 
> This is a non-trivial problem. Other unionfs implementations probably
> spent considerable time figuring out how to do it best. I entreated
> Gianluca to check what over implementations do, instead of trying to
> reinvent the wheel -- but he wouldn't listen :-(

This for sure has been ``solved'' (in one way or another) by now in other
designs and implementations.  Some weeks ago I added a few links to some
Linux unionfs pages to our unionfs web page.  Someone could go looking
there.


> In general, there are various places where I believe I could improve the
> wording -- but instead of explaining each seperately, I think it's
> easier if I just post a followup patch

Please do so, yes!


Regards,
 Thomas

Attachment: signature.asc
Description: Digital signature


reply via email to

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