From: maciver <ro...@gm...> - 2013-01-11 07:40:04
|
With lots of support regarding FUSE (Filesystem in Userspace) with high level operations classified in fuse_operations Struct, together with it is tons of examples that relates how fuse_operations works. However, what I am trying to achieve required the use of: void(* lookup )(fuse_req_t req, fuse_ino_t parent, const char *name) void(* mknod )(fuse_req_t req, fuse_ino_t parent, const char *name, mode_t mode, dev_t rdev) in fuse_lowlevel_ops Struct. I am not trying to the change the function of this two method, but just to intercept the meta data that passes through and store them in a cache. >From sample traces, for a new file creation, I see that LOOKUP() is always called first to identify if a file node exist, if it does, it will be returned. Else ERROR will be returned and MKNOD() will be called to create the file node then OPEN() and so on. So what I am trying to achieve is to have my filesystem maintaining a cache record. MKNOD will continue to do it normal operation while I'll just intercept the meta data record and store it in my cache. When LOOKUP is called for file node lookup, I'll check with my cache to see if it is available, if it is, I'll return. Else it will go on to check using it normal operation. Now the problem is, I couldn't find any documentation regarding the implementation of low-level MKNOD() where file nodes are created and LOOKUP() where file nodes are retrieved. So when the function call is passed from VFS to my mounted filesystem, I am not sure where I should create my file node to (based on normal filesystem operation). And what are the conditions to meet. I will be glad if someone can direct me to the correct direction and established examples that I can refer to. Thanks. |
From: maciver <ro...@gm...> - 2013-01-11 09:57:41
|
With lots of support regarding FUSE (Filesystem in Userspace) with high level operations classified in fuse_operations Struct, together with it is tons of examples that relates how fuse_operations works. However, what I am trying to achieve required the use of: void(* lookup )(fuse_req_t req, fuse_ino_t parent, const char *name) void(* mknod )(fuse_req_t req, fuse_ino_t parent, const char *name, mode_t mode, dev_t rdev) in fuse_lowlevel_ops Struct. I am not trying to the change the function of this two method, but just to intercept the meta data that passes through and store them in a cache. >From sample traces, for a new file creation, I see that LOOKUP() is always called first to identify if a file node exist, if it does, it will be returned. Else ERROR will be returned and MKNOD() will be called to create the file node then OPEN() and so on. So what I am trying to achieve is to have my filesystem maintaining a cache record. MKNOD will continue to do it normal operation while I'll just intercept the meta data record and store it in my cache. When LOOKUP is called for file node lookup, I'll check with my cache to see if it is available, if it is, I'll return. Else it will go on to check using it normal operation. Now the problem is, I couldn't find any documentation regarding the implementation of low-level MKNOD() where file nodes are created and LOOKUP() where file nodes are retrieved. So when the function call is passed from VFS to my mounted filesystem, I am not sure where I should create my file node to (based on normal filesystem operation). And what are the conditions to meet. I will be glad if someone can direct me to the correct direction and established examples that I can refer to. Thanks. -- View this message in context: http://old.nabble.com/Intercepting-regular-low-level-mknod-operations-in-FUSE-tp34887018p34887018.html Sent from the Fuse - Dev mailing list archive at Nabble.com. |
From: maciver <ro...@gm...> - 2013-01-11 07:34:10
|
With lots of support regarding FUSE (Filesystem in Userspace) with high level operations classified in fuse_operations Struct, together with it is tons of examples that relates how fuse_operations works. However, what I am trying to achieve required the use of: void(* lookup )(fuse_req_t req, fuse_ino_t parent, const char *name) void(* mknod )(fuse_req_t req, fuse_ino_t parent, const char *name, mode_t mode, dev_t rdev) in fuse_lowlevel_ops Struct. I am not trying to the change the function of this two method, but just to intercept the meta data that passes through and store them in a cache. >From sample traces, for a new file creation, I see that LOOKUP() is always called first to identify if a file node exist, if it does, it will be returned. Else ERROR will be returned and MKNOD() will be called to create the file node then OPEN() and so on. So what I am trying to achieve is to have my filesystem maintaining a cache record. MKNOD will continue to do it normal operation while I'll just intercept the meta data record and store it in my cache. When LOOKUP is called for file node lookup, I'll check with my cache to see if it is available, if it is, I'll return. Else it will go on to check using it normal operation. Now the problem is, I couldn't find any documentation regarding the implementation of low-level MKNOD() where file nodes are created and LOOKUP() where file nodes are retrieved. So when the function call is passed from VFS to my mounted filesystem, I am not sure where I should create my file node to (based on normal filesystem operation). And what are the conditions to meet. I will be glad if someone can direct me to the correct direction and established examples that I can refer to. Thanks. -- View this message in context: http://old.nabble.com/Intercepting-regular-low-level-mknod-operations-in-FUSE-tp34886596p34886596.html Sent from the Fuse - Dev mailing list archive at Nabble.com. |
From: Goswin v. B. <gos...@we...> - 2013-01-15 09:15:42
|
On Thu, Jan 10, 2013 at 11:34:02PM -0800, maciver wrote: > > With lots of support regarding FUSE (Filesystem in Userspace) with high level > operations classified in fuse_operations Struct, together with it is tons of > examples that relates how fuse_operations works. > > However, what I am trying to achieve required the use of: > > void(* lookup )(fuse_req_t req, fuse_ino_t parent, const char *name) > void(* mknod )(fuse_req_t req, fuse_ino_t parent, const char *name, mode_t > mode, dev_t rdev) > > in fuse_lowlevel_ops Struct. > > I am not trying to the change the function of this two method, but just to > intercept the meta data that passes through and store them in a cache. Fuse does not intercept the VFS operations, it provides it own. The operations on a fuse filesystem go to fuse and fuse alone.So you need to implement a full filesystem even if all it does it pass 99% of all operations through to a real one. Read the example filesystem that comes with fuse and go from there. MfG Goswin |
From: Rongjun T. <ro...@gm...> - 2013-01-15 15:53:02
|
The only example I came across with reference to low level implementation is hello_ll.c However this example implementation practically revolves the one and only hello file which can't be use dynamically. There is also no support for a full low level file system implementation. I do understand that FUSE itself with handle the inodes and metadata at low level, and return it to the higher level if I do not declare my own low level implementation for mknod() and lookup(). For me to be able to return my cached metadata upon a file call, I believe that I'll need to return the cache when lookup() is called. And lookup() can only be found at low level. So I am actually wondering if I will be able to pass the mknod() operation to FUSE default handler, at the same time try to intercept the metadata and store the information into my cache. On Tue, Jan 15, 2013 at 5:15 PM, Goswin von Brederlow <gos...@we...>wrote: > On Thu, Jan 10, 2013 at 11:34:02PM -0800, maciver wrote: > > > > With lots of support regarding FUSE (Filesystem in Userspace) with high > level > > operations classified in fuse_operations Struct, together with it is > tons of > > examples that relates how fuse_operations works. > > > > However, what I am trying to achieve required the use of: > > > > void(* lookup )(fuse_req_t req, fuse_ino_t parent, const char *name) > > void(* mknod )(fuse_req_t req, fuse_ino_t parent, const char *name, > mode_t > > mode, dev_t rdev) > > > > in fuse_lowlevel_ops Struct. > > > > I am not trying to the change the function of this two method, but just > to > > intercept the meta data that passes through and store them in a cache. > > Fuse does not intercept the VFS operations, it provides it own. The > operations on a fuse filesystem go to fuse and fuse alone.So you need > to implement a full filesystem even if all it does it pass 99% of all > operations through to a real one. > > Read the example filesystem that comes with fuse and go from there. > > MfG > Goswin > > > ------------------------------------------------------------------------------ > Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS > and more. Get SQL Server skills now (including 2012) with LearnDevNow - > 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. > SALE $99.99 this month only - learn more at: > http://p.sf.net/sfu/learnmore_122512 > _______________________________________________ > fuse-devel mailing list > fus...@li... > https://lists.sourceforge.net/lists/listinfo/fuse-devel > |
From: Feng S. <ste...@gm...> - 2013-01-15 16:22:09
|
I don't think this is possible. For fuse, you needs to either call high level API, or call low level API, or directly work with FUSE request/reply...... For a reference of low level API, you could take a look at HSFS: https://github.com/openunix/hsfs My suggestion is to start from the fuse_lowlevel_new in hsfs/fuse/hsfs_main.c: https://github.com/openunix/hsfs/blob/master/fuse/hsfs_main.c#L457 On Tue, Jan 15, 2013 at 11:52 PM, Rongjun Tang <ro...@gm...> wrote: > The only example I came across with reference to low level implementation > is hello_ll.c > However this example implementation practically revolves the one and only > hello file which can't be use dynamically. > There is also no support for a full low level file system implementation. > > I do understand that FUSE itself with handle the inodes and metadata at low > level, and return it to the higher level if I do not declare my own low > level implementation for mknod() and lookup(). > For me to be able to return my cached metadata upon a file call, I believe > that I'll need to return the cache when lookup() is called. And lookup() > can only be found at low level. > > So I am actually wondering if I will be able to pass the mknod() operation > to FUSE default handler, at the same time try to intercept the metadata and > store the information into my cache. > > > > On Tue, Jan 15, 2013 at 5:15 PM, Goswin von Brederlow <gos...@we...>wrote: > >> On Thu, Jan 10, 2013 at 11:34:02PM -0800, maciver wrote: >> > >> > With lots of support regarding FUSE (Filesystem in Userspace) with high >> level >> > operations classified in fuse_operations Struct, together with it is >> tons of >> > examples that relates how fuse_operations works. >> > >> > However, what I am trying to achieve required the use of: >> > >> > void(* lookup )(fuse_req_t req, fuse_ino_t parent, const char *name) >> > void(* mknod )(fuse_req_t req, fuse_ino_t parent, const char *name, >> mode_t >> > mode, dev_t rdev) >> > >> > in fuse_lowlevel_ops Struct. >> > >> > I am not trying to the change the function of this two method, but just >> to >> > intercept the meta data that passes through and store them in a cache. >> >> Fuse does not intercept the VFS operations, it provides it own. The >> operations on a fuse filesystem go to fuse and fuse alone.So you need >> to implement a full filesystem even if all it does it pass 99% of all >> operations through to a real one. >> >> Read the example filesystem that comes with fuse and go from there. >> >> MfG >> Goswin >> >> >> ------------------------------------------------------------------------------ >> Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS >> and more. Get SQL Server skills now (including 2012) with LearnDevNow - >> 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. >> SALE $99.99 this month only - learn more at: >> http://p.sf.net/sfu/learnmore_122512 >> _______________________________________________ >> fuse-devel mailing list >> fus...@li... >> https://lists.sourceforge.net/lists/listinfo/fuse-devel >> > ------------------------------------------------------------------------------ > Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS > and more. Get SQL Server skills now (including 2012) with LearnDevNow - > 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. > SALE $99.99 this month only - learn more at: > http://p.sf.net/sfu/learnmore_122512 > _______________________________________________ > fuse-devel mailing list > fus...@li... > https://lists.sourceforge.net/lists/listinfo/fuse-devel -- Feng Shuo Tel: (86)10-59851155-2116 Fax: (86)10-59851155-2008 Tianjin Zhongke Blue Whale Information Technologies Co., Ltd 10th Floor, Tower A, The GATE building, No. 19 Zhong-guan-cun Avenue Haidian District, Beijing, China Postcode 100080 |
From: Goswin v. B. <gos...@we...> - 2013-01-16 17:15:19
|
On Tue, Jan 15, 2013 at 11:52:52PM +0800, Rongjun Tang wrote: > The only example I came across with reference to low level implementation > is hello_ll.c > However this example implementation practically revolves the one and only > hello file which can't be use dynamically. > There is also no support for a full low level file system implementation. > > I do understand that FUSE itself with handle the inodes and metadata at low > level, and return it to the higher level if I do not declare my own low > level implementation for mknod() and lookup(). > For me to be able to return my cached metadata upon a file call, I believe > that I'll need to return the cache when lookup() is called. And lookup() > can only be found at low level. > > So I am actually wondering if I will be able to pass the mknod() operation > to FUSE default handler, at the same time try to intercept the metadata and > store the information into my cache. > > > > On Tue, Jan 15, 2013 at 5:15 PM, Goswin von Brederlow <gos...@we...>wrote: > > > On Thu, Jan 10, 2013 at 11:34:02PM -0800, maciver wrote: > > > > > > With lots of support regarding FUSE (Filesystem in Userspace) with high > > level > > > operations classified in fuse_operations Struct, together with it is > > tons of > > > examples that relates how fuse_operations works. > > > > > > However, what I am trying to achieve required the use of: > > > > > > void(* lookup )(fuse_req_t req, fuse_ino_t parent, const char *name) > > > void(* mknod )(fuse_req_t req, fuse_ino_t parent, const char *name, > > mode_t > > > mode, dev_t rdev) > > > > > > in fuse_lowlevel_ops Struct. > > > > > > I am not trying to the change the function of this two method, but just > > to > > > intercept the meta data that passes through and store them in a cache. > > > > Fuse does not intercept the VFS operations, it provides it own. The > > operations on a fuse filesystem go to fuse and fuse alone.So you need > > to implement a full filesystem even if all it does it pass 99% of all > > operations through to a real one. > > > > Read the example filesystem that comes with fuse and go from there. > > > > MfG > > Goswin As said you can't intercept things. you have to implement the full filesystem. If it must be low level then start with the highlevel fusexmp_fh.c and rewrite it for the lowlevel operations. You will need to implement your own inode -> path/name mapping then though. I don't see though why you can't stay highlevel and just add your cached files to the getattr and readdir hooks and wherever else you need it. MfG Goswin |
From: Rongjun T. <ro...@gm...> - 2013-01-16 17:34:54
|
I had tried to mount fusexmp_fh.c to get the following trace. >From the trace record, I find the following for opening a file. cat hellofile unique: 4048, opcode: LOOKUP (1), nodeid: 838, insize: 50, pid: 10324 LOOKUP /home/devuser/hellofile getattr /home/devuser/hellofile NODEID: 1429 unique: 4048, success, outsize: 144 unique: 4049, opcode: OPEN (14), nodeid: 1429, insize: 48, pid: 10324 open flags: 0x8000 /home/devuser/hellofile open[0] flags: 0x8000 /home/devuser/hellofile unique: 4049, success, outsize: 32 unique: 4050, opcode: READ (15), nodeid: 1429, insize: 80, pid: 10324 read[0] 4096 bytes from 0 flags: 0x8000 read[0] 14 bytes from 0 unique: 4050, success, outsize: 30 unique: 4051, opcode: GETATTR (3), nodeid: 1429, insize: 56, pid: 10324 getattr /home/devuser/hellofile unique: 4051, success, outsize: 120 unique: 4052, opcode: RELEASE (18), nodeid: 1429, insize: 64, pid: 0 release[0] flags: 0x8000 unique: 4052, success, outsize: 16 I see that LOOKUP is always the first operation that is being called, followed by open and read, then getattr. So I presumably assume that the right place to return metadata from my metadata cache to the caller will be at LOOKUP, which is only provided in low level. As for storage of metadata to my metadata cache, I am looking at MKNOD, which will be called when LOOKUP failed. So when a inode is created, a duplicated copy will be store to my metadata cache. cat > hellofile hello1 hello2 unique: 4040, opcode: LOOKUP (1), nodeid: 838, insize: 50, pid: 10286 LOOKUP /home/devuser/hellofile getattr /home/devuser/hellofile unique: 4040, error: -2 (No such file or directory), outsize: 16 unique: 4041, opcode: MKNOD (8), nodeid: 838, insize: 66, pid: 10286 mknod /home/devuser/hellofile 0100664 0x0 umask=0002 getattr /home/devuser/hellofile NODEID: 1429 unique: 4041, success, outsize: 144 unique: 4042, opcode: OPEN (14), nodeid: 1429, insize: 48, pid: 10286 open flags: 0x8001 /home/devuser/hellofile open[0] flags: 0x8001 /home/devuser/hellofile unique: 4042, success, outsize: 32 unique: 4043, opcode: GETXATTR (22), nodeid: 1429, insize: 68, pid: 10286 getxattr /home/devuser/hellofile security.capability 0 unique: 4043, error: -61 (No data available), outsize: 16 unique: 4044, opcode: WRITE (16), nodeid: 1429, insize: 87, pid: 10286 write[0] 7 bytes to 0 flags: 0x8001 write[0] 7 bytes to 0 unique: 4044, success, outsize: 24 unique: 4045, opcode: GETXATTR (22), nodeid: 1429, insize: 68, pid: 10286 getxattr /home/devuser/hellofile security.capability 0 unique: 4045, error: -61 (No data available), outsize: 16 unique: 4046, opcode: WRITE (16), nodeid: 1429, insize: 87, pid: 10286 write[0] 7 bytes to 7 flags: 0x8001 write[0] 7 bytes to 7 unique: 4046, success, outsize: 24 unique: 4047, opcode: RELEASE (18), nodeid: 1429, insize: 64, pid: 0 release[0] flags: 0x8001 unique: 4047, success, outsize: 16 I don't really see how I can implement my requirement through the use of highlevel getattr and readdir at this moment. Is it even possible? Thanks. On Thu, Jan 17, 2013 at 1:15 AM, Goswin von Brederlow <gos...@we...>wrote: > On Tue, Jan 15, 2013 at 11:52:52PM +0800, Rongjun Tang wrote: > > The only example I came across with reference to low level implementation > > is hello_ll.c > > However this example implementation practically revolves the one and only > > hello file which can't be use dynamically. > > There is also no support for a full low level file system implementation. > > > > I do understand that FUSE itself with handle the inodes and metadata at > low > > level, and return it to the higher level if I do not declare my own low > > level implementation for mknod() and lookup(). > > For me to be able to return my cached metadata upon a file call, I > believe > > that I'll need to return the cache when lookup() is called. And lookup() > > can only be found at low level. > > > > So I am actually wondering if I will be able to pass the mknod() > operation > > to FUSE default handler, at the same time try to intercept the metadata > and > > store the information into my cache. > > > > > > > > On Tue, Jan 15, 2013 at 5:15 PM, Goswin von Brederlow <gos...@we... > >wrote: > > > > > On Thu, Jan 10, 2013 at 11:34:02PM -0800, maciver wrote: > > > > > > > > With lots of support regarding FUSE (Filesystem in Userspace) with > high > > > level > > > > operations classified in fuse_operations Struct, together with it is > > > tons of > > > > examples that relates how fuse_operations works. > > > > > > > > However, what I am trying to achieve required the use of: > > > > > > > > void(* lookup )(fuse_req_t req, fuse_ino_t parent, const char *name) > > > > void(* mknod )(fuse_req_t req, fuse_ino_t parent, const char *name, > > > mode_t > > > > mode, dev_t rdev) > > > > > > > > in fuse_lowlevel_ops Struct. > > > > > > > > I am not trying to the change the function of this two method, but > just > > > to > > > > intercept the meta data that passes through and store them in a > cache. > > > > > > Fuse does not intercept the VFS operations, it provides it own. The > > > operations on a fuse filesystem go to fuse and fuse alone.So you need > > > to implement a full filesystem even if all it does it pass 99% of all > > > operations through to a real one. > > > > > > Read the example filesystem that comes with fuse and go from there. > > > > > > MfG > > > Goswin > > As said you can't intercept things. you have to implement the full > filesystem. If it must be low level then start with the highlevel > fusexmp_fh.c and rewrite it for the lowlevel operations. You will > need to implement your own inode -> path/name mapping then though. > > I don't see though why you can't stay highlevel and just add your > cached files to the getattr and readdir hooks and wherever else you > need it. > > MfG > Goswin > |
From: Goswin v. B. <gos...@we...> - 2013-01-17 13:12:29
|
On Thu, Jan 17, 2013 at 01:34:47AM +0800, Rongjun Tang wrote: > I had tried to mount fusexmp_fh.c to get the following trace. > >From the trace record, I find the following for opening a file. > > cat hellofile > unique: 4048, opcode: LOOKUP (1), nodeid: 838, insize: 50, pid: 10324 > LOOKUP /home/devuser/hellofile > getattr /home/devuser/hellofile > NODEID: 1429 > unique: 4048, success, outsize: 144 > unique: 4049, opcode: OPEN (14), nodeid: 1429, insize: 48, pid: 10324 > open flags: 0x8000 /home/devuser/hellofile > open[0] flags: 0x8000 /home/devuser/hellofile > unique: 4049, success, outsize: 32 > unique: 4050, opcode: READ (15), nodeid: 1429, insize: 80, pid: 10324 > read[0] 4096 bytes from 0 flags: 0x8000 > read[0] 14 bytes from 0 > unique: 4050, success, outsize: 30 > unique: 4051, opcode: GETATTR (3), nodeid: 1429, insize: 56, pid: 10324 > getattr /home/devuser/hellofile > unique: 4051, success, outsize: 120 > unique: 4052, opcode: RELEASE (18), nodeid: 1429, insize: 64, pid: 0 > release[0] flags: 0x8000 > unique: 4052, success, outsize: 16 > > I see that LOOKUP is always the first operation that is being called, > followed by open and read, then getattr. > So I presumably assume that the right place to return metadata from my > metadata cache to the caller will be at LOOKUP, which is only provided in > low level. > > As for storage of metadata to my metadata cache, I am looking at MKNOD, > which will be called when LOOKUP failed. So when a inode is created, a > duplicated copy will be store to my metadata cache. > > cat > hellofile > hello1 > hello2 > > unique: 4040, opcode: LOOKUP (1), nodeid: 838, insize: 50, pid: 10286 > LOOKUP /home/devuser/hellofile > getattr /home/devuser/hellofile Look in cache, check disk, return -ENOENT. > unique: 4040, error: -2 (No such file or directory), outsize: 16 > unique: 4041, opcode: MKNOD (8), nodeid: 838, insize: 66, pid: 10286 > mknod /home/devuser/hellofile 0100664 0x0 umask=0002 Add node to cache, create on disk. > getattr /home/devuser/hellofile > NODEID: 1429 > unique: 4041, success, outsize: 144 > unique: 4042, opcode: OPEN (14), nodeid: 1429, insize: 48, pid: 10286 Look in cache, return cached data. > I don't really see how I can implement my requirement through the use of > highlevel getattr and readdir at this moment. > Is it even possible? Thanks. Where is the problem? It is trivial. MfG Goswin |
From: Feng S. <ste...@gm...> - 2013-01-17 02:23:54
|
On Thu, 2013-01-17 at 01:34 +0800, Rongjun Tang wrote: > I had tried to mount fusexmp_fh.c to get the following trace. > >From the trace record, I find the following for opening a file. > > cat hellofile > unique: 4048, opcode: LOOKUP (1), nodeid: 838, insize: 50, pid: 10324 > LOOKUP /home/devuser/hellofile > getattr /home/devuser/hellofile > NODEID: 1429 > unique: 4048, success, outsize: 144 > unique: 4049, opcode: OPEN (14), nodeid: 1429, insize: 48, pid: 10324 > open flags: 0x8000 /home/devuser/hellofile > open[0] flags: 0x8000 /home/devuser/hellofile > unique: 4049, success, outsize: 32 > unique: 4050, opcode: READ (15), nodeid: 1429, insize: 80, pid: 10324 > read[0] 4096 bytes from 0 flags: 0x8000 > read[0] 14 bytes from 0 > unique: 4050, success, outsize: 30 > unique: 4051, opcode: GETATTR (3), nodeid: 1429, insize: 56, pid: 10324 > getattr /home/devuser/hellofile > unique: 4051, success, outsize: 120 > unique: 4052, opcode: RELEASE (18), nodeid: 1429, insize: 64, pid: 0 > release[0] flags: 0x8000 > unique: 4052, success, outsize: 16 > > I see that LOOKUP is always the first operation that is being called, > followed by open and read, then getattr. > So I presumably assume that the right place to return metadata from my > metadata cache to the caller will be at LOOKUP, which is only provided in > low level. In high level, this is done by stat(). Why don't you hook that? > > As for storage of metadata to my metadata cache, I am looking at MKNOD, > which will be called when LOOKUP failed. So when a inode is created, a > duplicated copy will be store to my metadata cache. This call is available in high level, I think. > > cat > hellofile > hello1 > hello2 > > unique: 4040, opcode: LOOKUP (1), nodeid: 838, insize: 50, pid: 10286 > LOOKUP /home/devuser/hellofile > getattr /home/devuser/hellofile > unique: 4040, error: -2 (No such file or directory), outsize: 16 > unique: 4041, opcode: MKNOD (8), nodeid: 838, insize: 66, pid: 10286 > mknod /home/devuser/hellofile 0100664 0x0 umask=0002 > getattr /home/devuser/hellofile > NODEID: 1429 > unique: 4041, success, outsize: 144 > unique: 4042, opcode: OPEN (14), nodeid: 1429, insize: 48, pid: 10286 > open flags: 0x8001 /home/devuser/hellofile > open[0] flags: 0x8001 /home/devuser/hellofile > unique: 4042, success, outsize: 32 > unique: 4043, opcode: GETXATTR (22), nodeid: 1429, insize: 68, pid: 10286 > getxattr /home/devuser/hellofile security.capability 0 > unique: 4043, error: -61 (No data available), outsize: 16 > unique: 4044, opcode: WRITE (16), nodeid: 1429, insize: 87, pid: 10286 > write[0] 7 bytes to 0 flags: 0x8001 > write[0] 7 bytes to 0 > unique: 4044, success, outsize: 24 > unique: 4045, opcode: GETXATTR (22), nodeid: 1429, insize: 68, pid: 10286 > getxattr /home/devuser/hellofile security.capability 0 > unique: 4045, error: -61 (No data available), outsize: 16 > unique: 4046, opcode: WRITE (16), nodeid: 1429, insize: 87, pid: 10286 > write[0] 7 bytes to 7 flags: 0x8001 > write[0] 7 bytes to 7 > unique: 4046, success, outsize: 24 > unique: 4047, opcode: RELEASE (18), nodeid: 1429, insize: 64, pid: 0 > release[0] flags: 0x8001 > unique: 4047, success, outsize: 16 > > I don't really see how I can implement my requirement through the use of > highlevel getattr and readdir at this moment. > Is it even possible? Thanks. > > > On Thu, Jan 17, 2013 at 1:15 AM, Goswin von Brederlow <gos...@we...>wrote: > > > On Tue, Jan 15, 2013 at 11:52:52PM +0800, Rongjun Tang wrote: > > > The only example I came across with reference to low level implementation > > > is hello_ll.c > > > However this example implementation practically revolves the one and only > > > hello file which can't be use dynamically. > > > There is also no support for a full low level file system implementation. > > > > > > I do understand that FUSE itself with handle the inodes and metadata at > > low > > > level, and return it to the higher level if I do not declare my own low > > > level implementation for mknod() and lookup(). > > > For me to be able to return my cached metadata upon a file call, I > > believe > > > that I'll need to return the cache when lookup() is called. And lookup() > > > can only be found at low level. > > > > > > So I am actually wondering if I will be able to pass the mknod() > > operation > > > to FUSE default handler, at the same time try to intercept the metadata > > and > > > store the information into my cache. > > > > > > > > > > > > On Tue, Jan 15, 2013 at 5:15 PM, Goswin von Brederlow <gos...@we... > > >wrote: > > > > > > > On Thu, Jan 10, 2013 at 11:34:02PM -0800, maciver wrote: > > > > > > > > > > With lots of support regarding FUSE (Filesystem in Userspace) with > > high > > > > level > > > > > operations classified in fuse_operations Struct, together with it is > > > > tons of > > > > > examples that relates how fuse_operations works. > > > > > > > > > > However, what I am trying to achieve required the use of: > > > > > > > > > > void(* lookup )(fuse_req_t req, fuse_ino_t parent, const char *name) > > > > > void(* mknod )(fuse_req_t req, fuse_ino_t parent, const char *name, > > > > mode_t > > > > > mode, dev_t rdev) > > > > > > > > > > in fuse_lowlevel_ops Struct. > > > > > > > > > > I am not trying to the change the function of this two method, but > > just > > > > to > > > > > intercept the meta data that passes through and store them in a > > cache. > > > > > > > > Fuse does not intercept the VFS operations, it provides it own. The > > > > operations on a fuse filesystem go to fuse and fuse alone.So you need > > > > to implement a full filesystem even if all it does it pass 99% of all > > > > operations through to a real one. > > > > > > > > Read the example filesystem that comes with fuse and go from there. > > > > > > > > MfG > > > > Goswin > > > > As said you can't intercept things. you have to implement the full > > filesystem. If it must be low level then start with the highlevel > > fusexmp_fh.c and rewrite it for the lowlevel operations. You will > > need to implement your own inode -> path/name mapping then though. > > > > I don't see though why you can't stay highlevel and just add your > > cached files to the getattr and readdir hooks and wherever else you > > need it. > > > > MfG > > Goswin > > > ------------------------------------------------------------------------------ > Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery > and much more. Keep your Java skills current with LearnJavaNow - > 200+ hours of step-by-step video tutorials by Java experts. > SALE $49.99 this month only -- learn more at: > http://p.sf.net/sfu/learnmore_122612 > _______________________________________________ > fuse-devel mailing list > fus...@li... > https://lists.sourceforge.net/lists/listinfo/fuse-devel |
From: Rongjun T. <ro...@gm...> - 2013-01-17 04:50:06
|
Hi Feng Shuo, I do not actually see the function stat() at http://fuse.sourceforge.net/doxygen/structfuse__operations.html I can only find struct stat from getattr. http://sourceforge.net/apps/mediawiki/fuse/index.php?title=Stat http://sourceforge.net/apps/mediawiki/fuse/index.php?title=Getattr() Please advise. Thanks. There is a high level mknod(). http://fuse.sourceforge.net/doxygen/structfuse__operations.html#1465eb2268cec2bb5ed11cb09bbda42f I would like to explore this, however I need to make sure I can retrieve my metadata cache at high level as well. On Thu, Jan 17, 2013 at 10:23 AM, Feng Shuo <ste...@gm...>wrote: > On Thu, 2013-01-17 at 01:34 +0800, Rongjun Tang wrote: > > I had tried to mount fusexmp_fh.c to get the following trace. > > >From the trace record, I find the following for opening a file. > > > > cat hellofile > > unique: 4048, opcode: LOOKUP (1), nodeid: 838, insize: 50, pid: 10324 > > LOOKUP /home/devuser/hellofile > > getattr /home/devuser/hellofile > > NODEID: 1429 > > unique: 4048, success, outsize: 144 > > unique: 4049, opcode: OPEN (14), nodeid: 1429, insize: 48, pid: 10324 > > open flags: 0x8000 /home/devuser/hellofile > > open[0] flags: 0x8000 /home/devuser/hellofile > > unique: 4049, success, outsize: 32 > > unique: 4050, opcode: READ (15), nodeid: 1429, insize: 80, pid: 10324 > > read[0] 4096 bytes from 0 flags: 0x8000 > > read[0] 14 bytes from 0 > > unique: 4050, success, outsize: 30 > > unique: 4051, opcode: GETATTR (3), nodeid: 1429, insize: 56, pid: 10324 > > getattr /home/devuser/hellofile > > unique: 4051, success, outsize: 120 > > unique: 4052, opcode: RELEASE (18), nodeid: 1429, insize: 64, pid: 0 > > release[0] flags: 0x8000 > > unique: 4052, success, outsize: 16 > > > > I see that LOOKUP is always the first operation that is being called, > > followed by open and read, then getattr. > > So I presumably assume that the right place to return metadata from my > > metadata cache to the caller will be at LOOKUP, which is only provided in > > low level. > In high level, this is done by stat(). Why don't you hook that? > > > > As for storage of metadata to my metadata cache, I am looking at MKNOD, > > which will be called when LOOKUP failed. So when a inode is created, a > > duplicated copy will be store to my metadata cache. > This call is available in high level, I think. > > > > cat > hellofile > > hello1 > > hello2 > > > > unique: 4040, opcode: LOOKUP (1), nodeid: 838, insize: 50, pid: 10286 > > LOOKUP /home/devuser/hellofile > > getattr /home/devuser/hellofile > > unique: 4040, error: -2 (No such file or directory), outsize: 16 > > unique: 4041, opcode: MKNOD (8), nodeid: 838, insize: 66, pid: 10286 > > mknod /home/devuser/hellofile 0100664 0x0 umask=0002 > > getattr /home/devuser/hellofile > > NODEID: 1429 > > unique: 4041, success, outsize: 144 > > unique: 4042, opcode: OPEN (14), nodeid: 1429, insize: 48, pid: 10286 > > open flags: 0x8001 /home/devuser/hellofile > > open[0] flags: 0x8001 /home/devuser/hellofile > > unique: 4042, success, outsize: 32 > > unique: 4043, opcode: GETXATTR (22), nodeid: 1429, insize: 68, pid: 10286 > > getxattr /home/devuser/hellofile security.capability 0 > > unique: 4043, error: -61 (No data available), outsize: 16 > > unique: 4044, opcode: WRITE (16), nodeid: 1429, insize: 87, pid: 10286 > > write[0] 7 bytes to 0 flags: 0x8001 > > write[0] 7 bytes to 0 > > unique: 4044, success, outsize: 24 > > unique: 4045, opcode: GETXATTR (22), nodeid: 1429, insize: 68, pid: 10286 > > getxattr /home/devuser/hellofile security.capability 0 > > unique: 4045, error: -61 (No data available), outsize: 16 > > unique: 4046, opcode: WRITE (16), nodeid: 1429, insize: 87, pid: 10286 > > write[0] 7 bytes to 7 flags: 0x8001 > > write[0] 7 bytes to 7 > > unique: 4046, success, outsize: 24 > > unique: 4047, opcode: RELEASE (18), nodeid: 1429, insize: 64, pid: 0 > > release[0] flags: 0x8001 > > unique: 4047, success, outsize: 16 > > > > I don't really see how I can implement my requirement through the use of > > highlevel getattr and readdir at this moment. > > Is it even possible? Thanks. > > > > > > On Thu, Jan 17, 2013 at 1:15 AM, Goswin von Brederlow <gos...@we... > >wrote: > > > > > On Tue, Jan 15, 2013 at 11:52:52PM +0800, Rongjun Tang wrote: > > > > The only example I came across with reference to low level > implementation > > > > is hello_ll.c > > > > However this example implementation practically revolves the one and > only > > > > hello file which can't be use dynamically. > > > > There is also no support for a full low level file system > implementation. > > > > > > > > I do understand that FUSE itself with handle the inodes and metadata > at > > > low > > > > level, and return it to the higher level if I do not declare my own > low > > > > level implementation for mknod() and lookup(). > > > > For me to be able to return my cached metadata upon a file call, I > > > believe > > > > that I'll need to return the cache when lookup() is called. And > lookup() > > > > can only be found at low level. > > > > > > > > So I am actually wondering if I will be able to pass the mknod() > > > operation > > > > to FUSE default handler, at the same time try to intercept the > metadata > > > and > > > > store the information into my cache. > > > > > > > > > > > > > > > > On Tue, Jan 15, 2013 at 5:15 PM, Goswin von Brederlow < > gos...@we... > > > >wrote: > > > > > > > > > On Thu, Jan 10, 2013 at 11:34:02PM -0800, maciver wrote: > > > > > > > > > > > > With lots of support regarding FUSE (Filesystem in Userspace) > with > > > high > > > > > level > > > > > > operations classified in fuse_operations Struct, together with > it is > > > > > tons of > > > > > > examples that relates how fuse_operations works. > > > > > > > > > > > > However, what I am trying to achieve required the use of: > > > > > > > > > > > > void(* lookup )(fuse_req_t req, fuse_ino_t parent, const char > *name) > > > > > > void(* mknod )(fuse_req_t req, fuse_ino_t parent, const char > *name, > > > > > mode_t > > > > > > mode, dev_t rdev) > > > > > > > > > > > > in fuse_lowlevel_ops Struct. > > > > > > > > > > > > I am not trying to the change the function of this two method, > but > > > just > > > > > to > > > > > > intercept the meta data that passes through and store them in a > > > cache. > > > > > > > > > > Fuse does not intercept the VFS operations, it provides it own. The > > > > > operations on a fuse filesystem go to fuse and fuse alone.So you > need > > > > > to implement a full filesystem even if all it does it pass 99% of > all > > > > > operations through to a real one. > > > > > > > > > > Read the example filesystem that comes with fuse and go from there. > > > > > > > > > > MfG > > > > > Goswin > > > > > > As said you can't intercept things. you have to implement the full > > > filesystem. If it must be low level then start with the highlevel > > > fusexmp_fh.c and rewrite it for the lowlevel operations. You will > > > need to implement your own inode -> path/name mapping then though. > > > > > > I don't see though why you can't stay highlevel and just add your > > > cached files to the getattr and readdir hooks and wherever else you > > > need it. > > > > > > MfG > > > Goswin > > > > > > ------------------------------------------------------------------------------ > > Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery > > and much more. Keep your Java skills current with LearnJavaNow - > > 200+ hours of step-by-step video tutorials by Java experts. > > SALE $49.99 this month only -- learn more at: > > http://p.sf.net/sfu/learnmore_122612 > > _______________________________________________ > > fuse-devel mailing list > > fus...@li... > > https://lists.sourceforge.net/lists/listinfo/fuse-devel > > > |
From: Feng S. <ste...@gm...> - 2013-01-17 05:53:33
|
Sorry, yes it's the getattr() in high level. Still not quite understanding why you want to do that, but basiclly, you need to hack fuse library to do that. On Thu, Jan 17, 2013 at 12:49 PM, Rongjun Tang <ro...@gm...> wrote: > Hi Feng Shuo, > > I do not actually see the function stat() at > http://fuse.sourceforge.net/doxygen/structfuse__operations.html > I can only find struct stat from getattr. > http://sourceforge.net/apps/mediawiki/fuse/index.php?title=Stat > http://sourceforge.net/apps/mediawiki/fuse/index.php?title=Getattr() > > Please advise. Thanks. > > There is a high level mknod(). > http://fuse.sourceforge.net/doxygen/structfuse__operations.html#1465eb2268cec2bb5ed11cb09bbda42f > I would like to explore this, however I need to make sure I can retrieve my > metadata cache at high level as well. > > On Thu, Jan 17, 2013 at 10:23 AM, Feng Shuo <ste...@gm...> > wrote: >> >> On Thu, 2013-01-17 at 01:34 +0800, Rongjun Tang wrote: >> > I had tried to mount fusexmp_fh.c to get the following trace. >> > >From the trace record, I find the following for opening a file. >> > >> > cat hellofile >> > unique: 4048, opcode: LOOKUP (1), nodeid: 838, insize: 50, pid: 10324 >> > LOOKUP /home/devuser/hellofile >> > getattr /home/devuser/hellofile >> > NODEID: 1429 >> > unique: 4048, success, outsize: 144 >> > unique: 4049, opcode: OPEN (14), nodeid: 1429, insize: 48, pid: 10324 >> > open flags: 0x8000 /home/devuser/hellofile >> > open[0] flags: 0x8000 /home/devuser/hellofile >> > unique: 4049, success, outsize: 32 >> > unique: 4050, opcode: READ (15), nodeid: 1429, insize: 80, pid: 10324 >> > read[0] 4096 bytes from 0 flags: 0x8000 >> > read[0] 14 bytes from 0 >> > unique: 4050, success, outsize: 30 >> > unique: 4051, opcode: GETATTR (3), nodeid: 1429, insize: 56, pid: 10324 >> > getattr /home/devuser/hellofile >> > unique: 4051, success, outsize: 120 >> > unique: 4052, opcode: RELEASE (18), nodeid: 1429, insize: 64, pid: 0 >> > release[0] flags: 0x8000 >> > unique: 4052, success, outsize: 16 >> > >> > I see that LOOKUP is always the first operation that is being called, >> > followed by open and read, then getattr. >> > So I presumably assume that the right place to return metadata from my >> > metadata cache to the caller will be at LOOKUP, which is only provided >> > in >> > low level. >> In high level, this is done by stat(). Why don't you hook that? >> > >> > As for storage of metadata to my metadata cache, I am looking at MKNOD, >> > which will be called when LOOKUP failed. So when a inode is created, a >> > duplicated copy will be store to my metadata cache. >> This call is available in high level, I think. >> > >> > cat > hellofile >> > hello1 >> > hello2 >> > >> > unique: 4040, opcode: LOOKUP (1), nodeid: 838, insize: 50, pid: 10286 >> > LOOKUP /home/devuser/hellofile >> > getattr /home/devuser/hellofile >> > unique: 4040, error: -2 (No such file or directory), outsize: 16 >> > unique: 4041, opcode: MKNOD (8), nodeid: 838, insize: 66, pid: 10286 >> > mknod /home/devuser/hellofile 0100664 0x0 umask=0002 >> > getattr /home/devuser/hellofile >> > NODEID: 1429 >> > unique: 4041, success, outsize: 144 >> > unique: 4042, opcode: OPEN (14), nodeid: 1429, insize: 48, pid: 10286 >> > open flags: 0x8001 /home/devuser/hellofile >> > open[0] flags: 0x8001 /home/devuser/hellofile >> > unique: 4042, success, outsize: 32 >> > unique: 4043, opcode: GETXATTR (22), nodeid: 1429, insize: 68, pid: >> > 10286 >> > getxattr /home/devuser/hellofile security.capability 0 >> > unique: 4043, error: -61 (No data available), outsize: 16 >> > unique: 4044, opcode: WRITE (16), nodeid: 1429, insize: 87, pid: 10286 >> > write[0] 7 bytes to 0 flags: 0x8001 >> > write[0] 7 bytes to 0 >> > unique: 4044, success, outsize: 24 >> > unique: 4045, opcode: GETXATTR (22), nodeid: 1429, insize: 68, pid: >> > 10286 >> > getxattr /home/devuser/hellofile security.capability 0 >> > unique: 4045, error: -61 (No data available), outsize: 16 >> > unique: 4046, opcode: WRITE (16), nodeid: 1429, insize: 87, pid: 10286 >> > write[0] 7 bytes to 7 flags: 0x8001 >> > write[0] 7 bytes to 7 >> > unique: 4046, success, outsize: 24 >> > unique: 4047, opcode: RELEASE (18), nodeid: 1429, insize: 64, pid: 0 >> > release[0] flags: 0x8001 >> > unique: 4047, success, outsize: 16 >> > >> > I don't really see how I can implement my requirement through the use of >> > highlevel getattr and readdir at this moment. >> > Is it even possible? Thanks. >> > >> > >> > On Thu, Jan 17, 2013 at 1:15 AM, Goswin von Brederlow >> > <gos...@we...>wrote: >> > >> > > On Tue, Jan 15, 2013 at 11:52:52PM +0800, Rongjun Tang wrote: >> > > > The only example I came across with reference to low level >> > > > implementation >> > > > is hello_ll.c >> > > > However this example implementation practically revolves the one and >> > > > only >> > > > hello file which can't be use dynamically. >> > > > There is also no support for a full low level file system >> > > > implementation. >> > > > >> > > > I do understand that FUSE itself with handle the inodes and metadata >> > > > at >> > > low >> > > > level, and return it to the higher level if I do not declare my own >> > > > low >> > > > level implementation for mknod() and lookup(). >> > > > For me to be able to return my cached metadata upon a file call, I >> > > believe >> > > > that I'll need to return the cache when lookup() is called. And >> > > > lookup() >> > > > can only be found at low level. >> > > > >> > > > So I am actually wondering if I will be able to pass the mknod() >> > > operation >> > > > to FUSE default handler, at the same time try to intercept the >> > > > metadata >> > > and >> > > > store the information into my cache. >> > > > >> > > > >> > > > >> > > > On Tue, Jan 15, 2013 at 5:15 PM, Goswin von Brederlow >> > > > <gos...@we... >> > > >wrote: >> > > > >> > > > > On Thu, Jan 10, 2013 at 11:34:02PM -0800, maciver wrote: >> > > > > > >> > > > > > With lots of support regarding FUSE (Filesystem in Userspace) >> > > > > > with >> > > high >> > > > > level >> > > > > > operations classified in fuse_operations Struct, together with >> > > > > > it is >> > > > > tons of >> > > > > > examples that relates how fuse_operations works. >> > > > > > >> > > > > > However, what I am trying to achieve required the use of: >> > > > > > >> > > > > > void(* lookup )(fuse_req_t req, fuse_ino_t parent, const char >> > > > > > *name) >> > > > > > void(* mknod )(fuse_req_t req, fuse_ino_t parent, const char >> > > > > > *name, >> > > > > mode_t >> > > > > > mode, dev_t rdev) >> > > > > > >> > > > > > in fuse_lowlevel_ops Struct. >> > > > > > >> > > > > > I am not trying to the change the function of this two method, >> > > > > > but >> > > just >> > > > > to >> > > > > > intercept the meta data that passes through and store them in a >> > > cache. >> > > > > >> > > > > Fuse does not intercept the VFS operations, it provides it own. >> > > > > The >> > > > > operations on a fuse filesystem go to fuse and fuse alone.So you >> > > > > need >> > > > > to implement a full filesystem even if all it does it pass 99% of >> > > > > all >> > > > > operations through to a real one. >> > > > > >> > > > > Read the example filesystem that comes with fuse and go from >> > > > > there. >> > > > > >> > > > > MfG >> > > > > Goswin >> > > >> > > As said you can't intercept things. you have to implement the full >> > > filesystem. If it must be low level then start with the highlevel >> > > fusexmp_fh.c and rewrite it for the lowlevel operations. You will >> > > need to implement your own inode -> path/name mapping then though. >> > > >> > > I don't see though why you can't stay highlevel and just add your >> > > cached files to the getattr and readdir hooks and wherever else you >> > > need it. >> > > >> > > MfG >> > > Goswin >> > > >> > >> > ------------------------------------------------------------------------------ >> > Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery >> > and much more. Keep your Java skills current with LearnJavaNow - >> > 200+ hours of step-by-step video tutorials by Java experts. >> > SALE $49.99 this month only -- learn more at: >> > http://p.sf.net/sfu/learnmore_122612 >> > _______________________________________________ >> > fuse-devel mailing list >> > fus...@li... >> > https://lists.sourceforge.net/lists/listinfo/fuse-devel >> >> > -- Feng Shuo Tel: (86)10-59851155-2116 Fax: (86)10-59851155-2008 Tianjin Zhongke Blue Whale Information Technologies Co., Ltd 10th Floor, Tower A, The GATE building, No. 19 Zhong-guan-cun Avenue Haidian District, Beijing, China Postcode 100080 |