Re: [PATCH RFC 2/5] libext2fs: add threading support to the I/O manager abstraction

["Theodore Y. Ts'o" <tytso@mit.edu>]

On Mon, Dec 07, 2020 at 11:15:30AM -0700, Andreas Dilger wrote:
> 
> Do you know how often we get into the "bounce_read" IO path?  It seems like
> locking around the read would kill parallelism, but this code path also
> looks like a fallback, but maybe 100% used for blocksize != PAGE_SIZE?

It should be extremely rare.  It only happens when Direct I/O is
requested (which is rare to begin with, although it looks like there
are people who are playing with some out of tree patchets to force
e2image to use Direct I/O?), and the offset or the size of I/O isn't
aligned with the system's direct I/O alignment requirements.  (See
ext2fs_get_dio_alignment() in lib/ext2fs/getsectsize.c)

> At one point you talked about using dlopen() or similar to link in the
> pthread library only if it is actually needed?  Or is the linkage of
> the pthread library avoided by these functions not being called unless
> IO_FLAG_THREADS is set? 

So what I'm doing is just not trying to call those functions unless
threading is required (e.g., IO_FLAG_THREADS is set, which would imply
that EXT2_FLAG_THREADS was passed to ext2fs_open()).  This won't help
if the application is using static linking, but if the application is
compiled statically, dlopen(3) is not guaranteed to work in any case.

So it's not perfect, and there may be some ancient AIX machine for
which this might be problematic.  But for all modern OS's that are
linking to want to compile e2fsprogs, it should work.  And I don't
have access to an AIX machine these days, and I don't work for IBM
anymore, so....  ¯\_(ツ)_/¯

:-)

					- Ted