On Tue, Jun 22, 2021 at 11:08 AM Paul Guo <paulguo@gmail.com> wrote:
>
> On Thu, Jun 17, 2021 at 3:19 PM Michael Paquier <michael@paquier.xyz> wrote:
> >
> > On Wed, Jun 02, 2021 at 05:02:10PM +0900, Michael Paquier wrote:
> > > On Wed, Jun 02, 2021 at 06:20:30PM +1200, Thomas Munro wrote:
> > > > The main thing I noticed was that Linux < 5.3 can fail with EXDEV if
> > > > you cross a filesystem boundary, is that something we need to worry
> > > > about there?
> > >
> > > Hmm. Good point. That may justify having a switch to control that.
> >
> > Paul, the patch set still needs some work, so I am switching it as
> > waiting on author. I am pretty sure that we had better have a
> > fallback implementation of copy_file_range() in src/port/, and that we
> > are going to need an extra switch in pg_rewind to allow users to
> > bypass copy_file_range()/EXDEV if they do a local rewind operation
> > across different FSes with a kernel < 5.3.
> > --
>
> I did modification on the copy_file_range() patch yesterday by simply falling
> back to read()+write() but I think it could be improved further.
>
> We may add a function to determine two file/path are copy_file_range()
> capable or not (using POSIX standard statvfs():f_fsid?) - that could be used
> by other copy_file_range() users although in the long run the function
> is not needed.
> And even having this we may still need the fallback code if needed.
>
> - For pg_rewind, we may just determine that ability once on src/dst pgdata, but
> since there might be soft link (tablespace/wal) in pgdata so we should still
> allow fallback for those non copy_fie_range() capable file copying.
> - Also it seems that sometimes copy_file_range() could return ENOTSUP/EOPNOTSUP
> (the file system does not support that and the kernel does not fall
> back to simple copying?)
> although this is not documented and it seems not usual?
>
> Any idea?
I modified the copy_file_range() patch using the below logic:
If the first call of copy_file_range() fails with errno EXDEV or
ENOTSUP, pg_rewind
would not use copy_file_range() in rest code, and if copy_file_range() fails we
fallback to use the previous read()+write() code logic for the file.
