Re: [Mysqlfs-general] query_inode_full: how does it work?

[Stef B. <st...@bo...>]

Smart Weblications GmbH, Florian Wiessner wrote:
> Hi,
>
> Stef Bon schrieb:
>
>   
>> This query does grow bigger as the path is longer (deeper).
>>
>>     
> Yes, the query grows bigger, and it is executed every time a lstat() or 
> lstat64() syscall happens - which makes performance really bad on 
> ndbcluster with distributed clients on different locations. We should 
> cache it somewhere (either in mysqlfs_getattr, or as cache somewhere in 
> query_inode_full.
>
> the cache must be cleared for the inode, if write/rename or chown/chmod 
> is executed so that query_inode_full always returns proper values.
>
> i thought about that inode-cache - it shouldn't be more than an array 
> containing values which has to be checked before the query is run.
>   
Yes, a cache should will things up. The construction now does a lot of 
lookups and never uses
data it has found before. For example, if you want to read a file 
/a/b/c/d/testfile, it will check you've permissions to
that file, and walk the path to it:
check /
check /a
check /a/b
check /a/b/c
check /a/b/c/d
check /a/b/c/d/testfile

to determine the inode of say /a/b/c, it does not use the information it 
just found before.

So a cache is a smart thing to do.
There are other fuse fs's using a cache(sshfs, fusesmb). My idea is to 
look first there how it is solved there.
My first impression is that fuse offers possibilities to use a cache, 
but I'm not sure.


> as for the locking-problem, what about creating a table metadata to 
> store information on which inode is currently locked? metadata could 
> also be stored with ndbcluster-engine, and thus we would easily be able 
> to implement file locking.
>
>   
Why not create an extra field in the inodes table, with a information 
about the locking?
An extra table is making things extra complicated, I think.

Stef Bon