Re: using file cloning in create database / initdb - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: using file cloning in create database / initdb
Date
Msg-id CA+hUKGKU0_-JKS8jfp85kZHpSRmz5n31h8TxW7Rq+YPv=m1h-w@mail.gmail.com
Whole thread Raw
List pgsql-hackers
On Tue, Aug 2, 2022 at 6:15 AM Justin Pryzby <pryzby@telsasoft.com> wrote:
> On Sat, Feb 12, 2022 at 07:37:30PM -0800, Andres Freund wrote:
> > It could theoretically help linux - but currently I think the filesystem for
> > CI is ext4, which doesn't support FICLONE. I assume it'd help macos, but I
> > don't know the performance characteristics of copyfile(). I don't think any of
> > the other OSs have working reflink / file clone support.

Just BTW, I think Solaris (on its closed source ZFS) can also do
this[1], but I doubt anyone will be along soon to write the patch for
that.

More interestingly to me at least, it looks like OpenZFS is getting
ready to ship its reflink feature, called BRT (block reference
tracking).  I guess it'll just work on Linux and macOS, and for
FreeBSD there may be a new syscall to patch into this code...

+    if ((src_fd = open(src, O_RDONLY | PG_BINARY, 0)) < 0)
+        return 1;

Why would you return 1, and not -1 (system call style), for failure?

Hmm, I don't think we can do plain open() from a regular backend
without worrying about EMFILE/ENFILE (a problem that pg_upgrade
doesn't have to deal with).  Perhaps copydir() should double-wrap the
call to clone_file() in ReserveExternalFD()/ReleaseExternalFD()?

[1] https://blogs.oracle.com/solaris/post/reflink3c-what-is-it-why-do-i-care-and-how-can-i-use-it



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Add test of pg_prewarm extenion
Next
From: Jacob Champion
Date:
Subject: Re: [Commitfest 2022-07] is Done!