configure.ac, why the change to ldflags?
The issue is that the AC_CHECK_LIB macro ends up adding -ljvm to $LIBS when successful. Then all of the following AC_CHECK_FUNCS tests were failing like so:
configure:11586: gcc -o conftest -g -O2 -I/usr/local/include -L/usr/local/lib conftest.c -ljvm -ldl >&5
/usr/bin/ld: cannot find -ljvm
collect2: ld returned 1 exit status
configure:11586: $? = 1
so it was failing to properly set HAVE_POSIX_FADVISE.
Did you happen to test sync_file_range on both 32 and 64 bit architectures with files greater than 4G
Nope. I unfortunately did not have the chance to test this. But I think if we commit this as an "experimental" feature to start off, then we can address some issues like this down the road. If your team has time to test it, that would be excellent.
I was wondering if cancel should go ahead and remove the req from the workq.
It seemed like extra complexity for little gain. In watching this code run with terasorts, etc, the queue was almost always empty (ie most of the time at least one of the RA threads was inactive). If it's OK, I'd prefer to leave as is.
Regarding the cancel race. It's not guaranteed to return EBADF because the fd is likely to get reused immediately for something else
True. Let me add a comment as you described.
It would be nice if ReadaheadRequest sanity checked curPos and maxOffsetToRead as well
Might be nice in the maxOffsetToRead param to indicate what the "don't care" value is
Good ideas. Will add.