[lustre-devel] [lustre-discuss] more on lustre striping

[Dilger, Andreas <andreas.dilger@intel.com>]

If I recall correctly from when we implemented liblustre, which hooked into userspace using LD_PRELOAD, we had to capture the __open() call instead of open() (or something similar) to ensure that glibc didn't bypass our LD_PRELOAD from inside of fopen().

You might consider downloading the source for glibc to see what it is doing in fopen().

Cheers, Andreas
--
Andreas Dilger
Lustre Principal Architect
Intel High Performance Data Division

On 2016/06/10, 10:04, "lustre-discuss on behalf of John Bauer" <lustre-discuss-bounces at lists.lustre.org<mailto:lustre-discuss-bounces@lists.lustre.org> on behalf of bauerj at iodoctors.com<mailto:bauerj@iodoctors.com>> wrote:


To confirm the point that you can not intercept the open called by fopen by using LD_PRELOAD, I have written a simple test case.  Note that the runtime linker never looks for open().  Only fopen()

$ cat a.c
#include <unistd.h>
#include <stdlib.h>
#include <fcntl.h>
#include <stdio.h>

int
main(int argc, char ** argv ){
   FILE *f = fopen("a", "r" ) ;
   fprintf(stderr,"f=%p\n",f);
   fclose(f);
}
$ file a
a: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=dfe043b4ec8cf19d5fd3fab524d7c72ed1453574, not stripped
$ cat a.csh
#!/bin/csh
setenv LD_DEBUG all
./a >&! a.cpr
$ ./a.csh
$ grep -i open a.cpr
    120584:     symbol=fopen;  lookup in file=./a [0]
    120584:     symbol=fopen;  lookup in file=/lib64/libc.so.6 [0]
    120584:     binding file ./a [0] to /lib64/libc.so.6 [0]: normal symbol `fopen' [GLIBC_2.2.5]
$

On 6/10/2016 7:29 AM, Ashley Pittman wrote:
On 22/05/16 02:56, John Bauer wrote:

Oleg

I can intercept the fopen(), but that does me no good as I can't set the O_LOV_DELAY_CREATE bit.  What I can not intercept is the open() downstream of fopen().  If one examines the symbols in libc you will see there are no unsatisfied externals relating to open, which means there is nothing for the runtime linker to find concerning open's.  I will have a look at the Lustre 1.8 source, but I seriously doubt that the open beneath fopen() was intercepted with LD_PRELOAD.  I would love to find a way to do that.  I could throw away a lot of code. Thanks,  John

Could you not intercept fopen() and implement it with calls to open() and fdopen() yourself which would give you full control over what you're looking for here?

Ashley.



--

I/O Doctors, LLC

507-766-0378

bauerj at iodoctors.com<mailto:bauerj@iodoctors.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-devel-lustre.org/attachments/20160617/fe11079b/attachment.htm>