Re: [PATCH] pg_upgrade: support for btrfs copy-on-write clones

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: [PATCH] pg_upgrade: support for btrfs copy-on-write clones
Дата
Msg-id 5285DDF4.9050402@vmware.com
обсуждение исходный текст
Ответ на Re: [PATCH] pg_upgrade: support for btrfs copy-on-write clones  (Oskari Saarenmaa <os@ohmu.fi>)
Ответы Re: [PATCH] pg_upgrade: support for btrfs copy-on-write clones  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
On 05.10.2013 16:57, Oskari Saarenmaa wrote:
> 05.10.2013 16:38, Bruce Momjian kirjoitti:
>> 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?
>
> Yeah, it's possible to clone an existing subvolume, but this requires
> that $PGDATA is a subvolume of its own and would be a bit difficult to
> integrate into existing pg_upgrade scripts.
>
> The BTRFS_IOC_CLONE ioctl operates on file level and can be used to
> clone files anywhere in a btrfs filesystem.

Hmm, you can also do

cp --reflog -r data92 data-tmp
pg_upgrade --link --old-datadir=data92-copy --new-datadir=data-tmp
rm -rf data-tmp

That BTRFS_IOC_CLONE ioctl seems so hacky that I'd rather not get that 
in our source tree. cp --reflog is much more likely to get that magic 
incantation right, since it gets a lot more attention and testing than 
pg_upgrade.

I'm not in favor of adding filesystem-specific tricks into pg_upgrade. 
It would be nice to list these tricks in the docs, though.

- Heikki



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alexander Korotkov
Дата:
Сообщение: Re: GIN improvements part2: fast scan
Следующее
От: Andres Freund
Дата:
Сообщение: Re: init_sequence spill to hash table