On Fri, Oct 4, 2013 at 10:42:46PM +0300, Oskari Saarenmaa wrote: > Thanks for the offers, but it looks like ZFS doesn't actually implement > a similar file level clone operation. See > https://github.com/zfsonlinux/zfs/issues/405 for discussion on a feature > request for it. > > ZFS does support cloning entire datasets which seem to be similar to > btrfs subvolume snapshots and could be used to set up a new data > directory for a new $PGDATA. This would require the original $PGDATA > to be a dataset/subvolume of its own and quite a bit different logic > (than just another file copy method in pg_upgrade) to initialize the new > version's $PGDATA as a snapshot/clone of the original. The way this > would work is that the original $PGDATA dataset/subvolume gets cloned to > a new location after which we move the files out of the way of the new > PG installation and run pg_upgrade in link mode. I'm not sure if > there's a good way to integrate this into pg_upgrade or if it's just > something that could be documented as a fast way to run pg_upgrade > without touching original files. > > With btrfs tooling the sequence would be something like this: > > btrfs subvolume snapshot /srv/pg92 /srv/pg93 > mv /srv/pg93/data /srv/pg93/data92 > initdb /data/pg93/data > pg_upgrade --link \ > --old-datadir=/data/pg93/data92 \ > --new-datadir=/data/pg93/data
Does btrfs support file system snapshots? If so, shouldn't people just take a snapshot of the old data directory before the ugprade, rather than using cloning? -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
