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?