From: Gal R. <GA...@il...> - 2010-10-05 09:31:03
|
Hi Stef, I would like to understand the whole path of syscalls, where it is blocking and where it is not. I know that I do not have the control of how the client is working with the files on the FUSE mount file system, sync or async, but I would like to understand how it works inside the kernel, in both modes. >From reading the documentation and looking a bit on the code, I understand that all syscalls requests except of 2 are blocking (I found only the release syscall). If I understand correctly when the user is working in sync mode then the whole path is sync. If the user is working in async mode, I guess that the VFS returns immediately to the user (so this part is non blocking), and then foreword the syscall request to the FUSE. Then a FUSE request is created, put on a pending list, and wait for response (this part is blocking). So what, the CPU is now waiting on this request for a response from the FUSE library ? I guess there is something here that I am not understand correctly, because in that case there is no point of implementing async mode with the low level API. Does the FUSE library use poll syscall on /dev/fuse or just reading and waiting for requests ? Gal. |------------> | From: | |------------> >------------------------------------------------------------------------------------------------------------------------------------------------| |Stef Bon <st...@gm...> | >------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | To: | |------------> >------------------------------------------------------------------------------------------------------------------------------------------------| |Gal Rosen/Haifa/IBM@IBMIL | >------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Cc: | |------------> >------------------------------------------------------------------------------------------------------------------------------------------------| |fus...@li... | >------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Date: | |------------> >------------------------------------------------------------------------------------------------------------------------------------------------| |10/04/2010 10:04 AM | >------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Subject: | |------------> >------------------------------------------------------------------------------------------------------------------------------------------------| |Re: [fuse-devel] Fw: Lowlevel fs | >------------------------------------------------------------------------------------------------------------------------------------------------| Yes of course. I've added the struct of the entry already, You can look at: http://git.kernel.org/?p=linux/kernel/git/mszeredi/deltafs.git;a=tree I copied most of my fs from there. You'll find the original lookup_path also there. And the inode struct. Please let me (us?) know about proceedings. Stef 2010/10/4 Gal Rosen <GA...@il...>: > Thanks Stef, > > This is how to extract the full path from the inode, but another work which > I need to do, that the high level interface is already doing, is to cache > the inodes. > I mean to create and save inodes in some data structure after create, mkdir > or mknod operations, and maybe more. The search in this structure should be > efficient. > Am I right ? > > Gal. > > > |------------> > | From: | > |------------> > >------------------------------------------------------------------------------------------------------------------------------------------------| > |Stef Bon <st...@gm...> | > >------------------------------------------------------------------------------------------------------------------------------------------------| > |------------> > | To: | > |------------> > >------------------------------------------------------------------------------------------------------------------------------------------------| > |Gal Rosen/Haifa/IBM@IBMIL | > >------------------------------------------------------------------------------------------------------------------------------------------------| > |------------> > | Cc: | > |------------> > >------------------------------------------------------------------------------------------------------------------------------------------------| > |fus...@li... | > >------------------------------------------------------------------------------------------------------------------------------------------------| > |------------> > | Date: | > |------------> > >------------------------------------------------------------------------------------------------------------------------------------------------| > |10/03/2010 03:37 PM | > >------------------------------------------------------------------------------------------------------------------------------------------------| > |------------> > | Subject: | > |------------> > >------------------------------------------------------------------------------------------------------------------------------------------------| > |Re: [fuse-devel] Fw: Lowlevel fs | > >------------------------------------------------------------------------------------------------------------------------------------------------| > > > > > > Maybe I can help you here!! > > I've had the same problem, using the highlevel interface first, and > then switching to the lowlevel interface, because I preferred the > asynchronous behaviour. Making the highlevel interface asynchronous is > a very difficult task, and making use of paths in the lowlevel > interface is not so hard. > > I've copied my function determine_path from deltafs, created by > Miklos, where is was called lookup_path, I believe. > > It walks down all the entries, taking it's parents, going back to the > root inode. > > pathstring is a typedef of char[4097]. > xmpfs_entry_struct is the struct for entries: > > struct xmpfs_entry_struct { > char *name; > struct xmpfs_inode_struct *inode; > struct xmpfs_entry_struct *name_next; > struct xmpfs_entry_struct *name_prev; > struct xmpfs_entry_struct *parent; > int onmd5keyresource; > size_t namehash; > struct workspace_data_struct *workspace_data; > struct xmpfs_entry_struct *md5key_list_next; > struct xmpfs_entry_struct *md5key_list_prev; > }; > > You can ignore the last values (onmd5keyresource, namehash, > workspace_data, md5key_list_next, md5key_list_prev). > Important is of course the pointer to the inode. > > Comments in the function are present. If some questions, pleasy reply. > > Stef Bon > > ------------------------ > > static int determine_path(pathstring path, struct xmpfs_entry_struct > *entry) > { > char *s = path + sizeof(pathstring) - 1; > size_t lenname; > > *s = '\0'; > > if ( xmpfs_options.logging > 0 ) syslog(LOG_DEBUG, > "determine_path."); > > lenname=strlen(entry->name); > > if ( s - path < (long) lenname ) { > > return -ENAMETOOLONG; > > } > > s -= (long) lenname; > > memcpy(s, entry->name, lenname); > > // go to all the parents > > while (entry->parent != NULL) { > > entry = entry->parent; > > // stop when root is reached > > if (entry->inode->ino == FUSE_ROOT_ID) break; > > // add the name of this entry (at the start of > path) and a slash to > separate it > > s--; > *s = '/'; > > lenname=strlen(entry->name); > > if ( s - path < (long) lenname ) { > > return -ENAMETOOLONG; > > } > > s -= lenname; > > memcpy(s, entry->name, lenname); > > } > > // > // move the path pointed by s back to the beginning of string > path > // > > memmove(path, s, sizeof(pathstring) - (s - path)); > > if (xmpfs_options.logging > 1) syslog(LOG_DEBUG, > "determine_path, > return: %s", path); > > return 0; > } > > > 2010/10/3 Gal Rosen <GA...@il...>: >> >> Sorry, one message line was disappears. >> >> I mean to write: >> I would like to use FUSE to build a file system in user space with single >> process and asynchronous operations. >> The high level API is working synchronously and with paths, and the low >> level API is working with inodes and asynchronously. >> So, as I understand, I have 2 options if I want to work asynchronously > and >> with paths: >> 1. Use the low level API and implement conversions between inodes to > paths >> (part of what the high level is doing). >> 2. Implement async operations in the high level API, which means to > change >> libfuse. > > ------------------------------------------------------------------------------ > > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > fuse-devel mailing list > fus...@li... > https://lists.sourceforge.net/lists/listinfo/fuse-devel > > > > |