[Pvfs2-developers] Re: [Pvfs2-cvs] commit by kunkel in pvfs2/src/io/trove/trove-dbpf: dbpf-attr-cache.c dbpf-bstream-threaded.c

[Julian Martin Kunkel]

Hi,
> I would prefer to see this handled by the configure script, if
> possible.  No O_DIRECT in fcntl.h => no support in pvfs2; we
> shouldn't get in the business of defining these constants if
> possible to avoid it.
right, I agree. In the moment I try to get a working O_DIRECT version in order 
to evaluate first results. Right now it is extremely hard to determine how 
O_DIRECT should be tuned, e.g. do we need extra scheduling etc. Thus, it is 
just an prototype. 
> Where is 512 enforced?  How do you know it is exactly 512?  Do all
> FSes support O_DIRECT at a 512-byte granularity?  How can you detect
> this at runtime?
Actually the alignment used to be the memory pagesize, in kernel 2.6 this was 
reduced to 512 bytes. Anyway the current code uses the memory pagesize.
Also there is a maximum and minimum size of an O_Direct request which is 
allowed. This is currently not checked.

> Use memset.  bzero is deprecated, non-posix.
Oh, that sucks, I loved bzero :)
> > +    buff_real = (unsigned char *)(((unsigned long)odirectBuffAlloc +
> > +                mem_pagesize - 1) & (~(mem_pagesize - 1)));
>
> Use uintptr_t for this sort of calculation.  ulong is not guaranteed
> to hold a pointer.
Good tip, thanks ! I'll change it !
I'll do some benchmarking on a single node disk to figure out how much 
O_direct hurts in that case... Maybe later in the week (maybe there are some 
more bugs ;-) it would be neat to see some results on a high performance raid 
system :)

Julian