[Top][All Lists]

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

Re: [PATCH 2/2] Setup the node stat information in netfs_validate_stat.

From: Sergiu Ivanov
Subject: Re: [PATCH 2/2] Setup the node stat information in netfs_validate_stat.
Date: Tue, 22 Dec 2009 23:12:17 +0200
User-agent: Mutt/1.5.20 (2009-06-14)


On Tue, Dec 22, 2009 at 07:40:12PM +0800, Da Zheng wrote:
> Could you tell me why initializing node status here is perferred?

The multiplexer creates nodes on any demand, whether the client
intends to further use the node to create a (virtual) device or not.
This means that, for instance,

 $ file mux/<any-name>

will always find the <any-name> file.

An important remark is that there is a one-to-one relationship between
light nodes and devices.

Now let's see what happens if one really runs the aforementioned
command.  When file tries to open <any-name>, the multiplexer will
create a new node with <any-name> (suppose this name does not exist
yet), but since file does not intend to open any devices, no lnode
will be created.  Then, file will io_stat the port it has got, and the
multiplexer will return the stat information of its underlying node,
according to the original code.  I hope I managed to make it clear :-)

The problem I tried to solve with this patch was that running file
mux/<any-name> could return surprising results, should the multiplexer
be sitting on a directory (and it is so when the multiplexer is used
in conjunction with unionmount) -- any non-existent filename under
mux/ would be a directory.  Whether this is bad for the human typing
the command at the shell is a matter of taste, but the fundamental
problem was that all new nodes without devices associated had the same
inode number as the node underlying the multiplexer, which confused
unionmount severely (unionmount actually didn't work with multiplexer
because of this inode number confusion).  I don't really remember
which exactly piece of code in unionmount refused to function, but the
reason I remember pretty well.

There is a second argument which relies mainly on the idea of keeping
affiliated pieces of code together.  Let me put it like this: the stat
information is something relevant in libnetfs business, and less in
device business.  Therefore, it would be better to set up the stat
information when a *node* is created, and not postpone it till the
actual creation of a device.  As you might have seen above, this
purely intuitive reasoning has a pretty strong practical background :-)

Hopefully, my (unexpectedly) overgrown E-mail has not bored you to
death :-)


reply via email to

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