Chuck: Below is an idea from Walt on your LANL project.
Chuck, we've added a user-level interface to PVFS, there are many layers running from stdio, through posix system calls, to a low-level library called "iocommon" that calls the PVFS SYS calls directly. For what you are doing it would probably be a good idea to use that iocommon layer, or at least look at how it works. In particular there are a lot of weird corner cases having to do with the format of a path that make the bare SYS calls rather unfriendly. I've worked out those details (finally) so if you want you can use it. For the most part I think it will work fine with 2.8.4 if you don't want to upgrade, though there may be one or two patches you'd have to do. Mostly related to handling symbolic links. The PVFS "utilities" like pvfs2-ls and pvfs2-cp were never really intended as user tools - they mimic the fileutils, but not perfectly. This library will actually compile with (or link to) the GNU coreutils. Anyway, if you are interested, download the current version of OrangeFS-2.8.6 using the following svn command: svn co http://www.orangefs.org/svn/orangefs/branches/stable Walt On Thu, Oct 18, 2012 at 5:17 PM, Becky Ligon <[email protected]> wrote: > Chuck:* > > *John Chandy at the University of Connecticut ([email protected]*j*)wrote > the original pvfs2fuse module. > > Becky > > > On Thu, Oct 18, 2012 at 5:11 PM, Becky Ligon <[email protected]> wrote: > >> 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 >> >> >> > > > -- > 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
