On 10/24/12 17:44, Carson Gaspar wrote:
On 10/24/12 3:59 AM, Darren J Moffat wrote:
So in this case you should have a) created the pool with a version that
matches the pool version of the backup server and b) make sure you
create the ZFS file systems with a version that is supposed by the
backu
On 10/24/12 3:59 AM, Darren J Moffat wrote:
So in this case you should have a) created the pool with a version that
matches the pool version of the backup server and b) make sure you
create the ZFS file systems with a version that is supposed by the
backup server.
And AI allows you to set the
On 10/24/12 03:16, Edward Ned Harvey
(opensolarisisdeadlongliveopensolaris) wrote:
From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
boun...@opensolaris.org] On Behalf Of Karl Wagner
The only thing I think Oracle should have done differently is to allow
either a downgrade or crea
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Karl Wagner
>
> The only thing I think Oracle should have done differently is to allow
> either a downgrade or creating a send stream in a lower version
> (reformatting the data where necessary
Actually, I think there is a world of difference.
Backwards compatibility is something we all need. We need to be able to
access content created in previous versions of software in newer
versions.
You cannot expect an older version to be compatible with the new
features in a later version. T
> From: Richard Elling [mailto:richard.ell...@gmail.com]
>
> At some point, people will bitterly regret some "zpool upgrade" with no way
> back.
>
> uhm... and how is that different than anything else in the software world?
>
> No attempt at backward compatibility, and no downgrade path, not eve
On Oct 19, 2012, at 4:59 PM, Edward Ned Harvey
(opensolarisisdeadlongliveopensolaris)
wrote:
>> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
>> boun...@opensolaris.org] On Behalf Of Richard Elling
>>
>>> At some point, people will bitterly regret some "zpool upgrade" with no
2012-10-20 3:59, Edward Ned Harvey
(opensolarisisdeadlongliveopensolaris) пишет:
From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
boun...@opensolaris.org] On Behalf Of Richard Elling
At some point, people will bitterly regret some "zpool upgrade" with no way
back.
uhm... and how
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Richard Elling
>
>> At some point, people will bitterly regret some "zpool upgrade" with no way
>> back.
>
> uhm... and how is that different than anything else in the software world?
No atte
On Oct 19, 2012, at 1:04 AM, Michel Jansens wrote:
>> On 10/18/12 21:09, Michel Jansens wrote:
>>> Hi,
>>>
>>> I've been using a Solaris 10 update 9 machine for some time to replicate
>>> filesystems from different servers through zfs send|ssh zfs receive.
>>> This was done to store disaster r
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Ian Collins
>
> You have to create pools/filesystems with the older versions used by the
> destination machine.
Apparently "zpool create -d -o version=28" you might want to do on the new
syst
On 10/18/12 21:09, Michel Jansens wrote:
Hi,
I've been using a Solaris 10 update 9 machine for some time to replicate
filesystems from different servers through zfs send|ssh zfs receive.
This was done to store disaster recovery pools. The DR zpools are made from
sparse files (to allow for ea
12 matches
Mail list logo
