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

[Da Zheng]

Sergiu Ivanov wrote:
> Hello,
> 
> 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.
Yes, you are right. My mistake. I didn't realize I initialized stat in 
ds_device_open().
> 
> 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 :-)
Not at all:-)

Zheng Da