Chuck: The person who wrote the pvfs2fuse module is not on our staff, but I will track down his name and send it along to you. This guy is probably the person you should ask about your concerns.
Becky On Thu, Oct 18, 2012 at 3:37 PM, Chuck Cranor <[email protected]> wrote: > hi- > > I've got the 2.8.4 embedded in a disk image i'm using > across a set of clusters, so it isn't so easy to change right > now. I am OK though, as I have a workaround that removes all > double slashes from a filename before passing it to PVFS API. > Glad the issue is resolved in 2.8.6, I can easily remove my > workaround when I get a chance to upgrade (but I'm not sure > when that will be). > > I've modified PLFS (parallel log structured filesystem from > LANL) to write directly to PVFS rather than go through the PVFS > kernel module. To do that I need to link PLFS with the PVFS APIs. > I've got it working with that API, but I was mainly wondering about > the memory management issues (to avoid memory leaks by not using > the PVFS_SYS API properly). Based on my reading of the code, it > seems to me that there may be memory leaks in pvfs2fuse... but maybe > I don't understand the API fully. > > thanks, > chuck > > > On Tue, Oct 16, 2012 at 03:04:24PM -0400, Becky Ligon wrote: > > Under Orangefs 2.8.6, the errors that you described with pvfs2-ls (and > > kernel ls) no longer exist. Is it possible for you to use the latest > > Orangefs 2.8.6? If so, use this SVN command: > > > > svn co http://www.orangefs.org/svn/orangefs/branches/stable. > > > > > > Also with OrangeFS 2.8.6, we have a new user library that you may want to > > use instead of the PVFS_SYS calls that I described earlier. If you can > > tell me what you are trying to do, I can help you decide which way to go. > > > > Thanks, > > Becky > > > > On Mon, Oct 15, 2012 at 1:47 PM, Chuck Cranor <[email protected]> wrote: > > > > > hi- > > > > > > I believe I've found a bug in path handling in OrangeFS 2.8.4. > > > I don't know if it impacts newer versions, but it is easy to test. > > > If you make a directory and then make a subdirectory with the same > > > name in it, then stat gets confused when it encounters filenames with > > > extra slashes in it. In other words, try this: > > > > > > > > > # cat /etc/pvfs2tab > > > tcp://p9ea1:3334/pvfs2-fs /pvfsarea/pp pvfs2 defaults,noauto 0 > 0 > > > # pvfs2-mkdir /pvfsarea/pp/testdir > > > # pvfs2-mkdir /pvfsarea/pp/testdir/testdir > > > # pvfs2-ls /pvfsarea/pp/testdir/some_random_string > > > PVFS_sys_lookup: No such file or directory (error class: 0) > > > # pvfs2-ls /pvfsarea/pp//testdir/some_random_string > > > # > > > # pvfs2-ls /pvfsarea/pp/testdir/another_random_string > > > PVFS_sys_lookup: No such file or directory (error class: 0) > > > # pvfs2-ls /pvfsarea/pp////testdir/another_random_string > > > # > > > > > > note that "pvfs2-ls" does not generate an error if I add the extra "/" > > > characters (and it should!). > > > > > > > > > > > > While I am here, where is the documentation/man pages for the libpvfs2 > > > API? I was looking at the pvfs2fuse as an example of using this API, > > > but I'm unclear on when I need to call PVFS_Request_free() and > > > PVFS_util_release_sys_attr(). > > > > > > > > > For example, with PVFS_Request_free(), in pvfs2fuse.c in the function > > > pvfs_fuse_read() it calls: > > > > > > PVFS_Request_contiguous(count, PVFS_BYTE, &mem_req); > > > > > > That function appears to malloc() mem_req in PVFS_Request_hvector(). > > > pvfs_fuse_read() then goes on to call "ret = PVFS_sys_read()" and based > > > on the return value it does: > > > > > > if (ret == 0) > > > { > > > PVFS_Request_free(&mem_req); > > > return(resp_io.total_completed); > > > } > > > else > > > return PVFS_ERROR_TO_ERRNO_N( ret ); > > > > > > the PVFS_Request_free() function appears to free mem_req, but it is > > > only called if PVFS_sys_read() returns 0. > > > > > > My question: who frees mem_req if PVFS_sys_read() returns a non-zero > value? > > > > > > > > > Next: PVFS_util_release_sys_attr(). pvfs2fuse.c calls > PVFS_sys_getattr() > > > with PVFS_ATTR_SYS_ALL_NOHINT in 3 places: > > > 1. pvfs_fuse_getattr_pfhp() > > > 2. pvfs_fuse_readlink() > > > 3. pvfs_fuse_access() > > > > > > in the first case, pvfs_fuse_getattr_pfhp(), it calls > > > PVFS_util_release_sys_attr(attrs) before returning (attrs is > > > shorthand for &getattr_response.attr). > > > > > > But in the second and third cases (readlink/access), it does not > > > call PVFS_util_release_sys_attr() at all, and I'm not clear on > > > why this is different from the pvfs_fuse_getattr_pfhp() case? > > > > > > > > > Can anyone clarify when PVFS_Request_free() and > > > PVFS_util_release_sys_attr() > > > needs to be called (and maybe provide a pointer to docs so I can better > > > check my own code). > > > > > > thanks, > > > chuck > > > > > > _______________________________________________ > > > Pvfs2-users mailing list > > > [email protected] > > > http://www.beowulf-underground.org/mailman/listinfo/pvfs2-users > > > > > > > > > > > -- > > Becky Ligon > > OrangeFS Support and Development > > Omnibond Systems > > Anderson, South Carolina > -- Becky Ligon OrangeFS Support and Development Omnibond Systems Anderson, South Carolina
_______________________________________________ Pvfs2-users mailing list [email protected] http://www.beowulf-underground.org/mailman/listinfo/pvfs2-users
