[lustre-discuss] more on lustre striping
John Bauer
bauerj at iodoctors.com
Fri Jun 10 09:04:52 PDT 2016
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-discuss-lustre.org/attachments/20160610/0da6b324/attachment-0001.htm>
More information about the lustre-discuss
mailing list