zfs discuss - Nov 2006 - Que: ZFS - Automatic Endian Adaptiveness

I came across couple of articles (by Amy Rich) on BigAdmin abt ZFS. In 
one of these articles, it is mentioned that with ZFS export/import, one 
can move pool from SPARC to x64 or other way around without worrying 
about the Endian issues (target system will automatically re-write the 
blocks with new endianness as needed).

But later it talks about Endian conversion automatically happening for 
ZFS meta data blocks only ... user data blocks are not taken care of. 
OK. Has anyone tried moving data in this fashion ? Have you tried moving 
Oracle-related datafiles in this fashion ?

Regards,
Jay

Jay Sisodiya wrote:
> I came across couple of articles (by Amy Rich) on BigAdmin abt ZFS. In 
> one of these articles, it is mentioned that with ZFS export/import, one 
> can move pool from SPARC to x64 or other way around without worrying 
> about the Endian issues (target system will automatically re-write the 
> blocks with new endianness as needed).
> 
> But later it talks about Endian conversion automatically happening for 
> ZFS meta data blocks only ... user data blocks are not taken care of. 
> OK. Has anyone tried moving data in this fashion ? Have you tried moving 
> Oracle-related datafiles in this fashion ?
This was discussed on opensolaris-discuss recently.

A file system should NEVER mess around with application level data, that 
is the responsibility of the application only.

There are many solutions to this for applications already (including the 
now very old but still highly useful XDR method).  Apps already need to 
be able to do this to work properly with network file systems and for 
data the pass over the network.

-- 
Darren J Moffat

Hi Jay,

We''ve moved (import/export) ZFS filesystems between an Opteron-based
SunFire X4100 and T1 SPARC-based SunFire T2000 without any problems.

1.) Export SPARC
2.) Change FC array LUN masking.
3.) Import Opteron.

Worked like a charm. :-) Was running solid for about two months (MySQL
DB). We just moved back to the T2000.

Best Regards,
Jason

On 11/20/06, Jay Sisodiya <Jay.Sisodiya at sun.com>
wrote:
> I came across couple of articles (by Amy Rich) on BigAdmin abt ZFS. In
> one of these articles, it is mentioned that with ZFS export/import, one
> can move pool from SPARC to x64 or other way around without worrying
> about the Endian issues (target system will automatically re-write the
> blocks with new endianness as needed).
>
> But later it talks about Endian conversion automatically happening for
> ZFS meta data blocks only ... user data blocks are not taken care of.
> OK. Has anyone tried moving data in this fashion ? Have you tried moving
> Oracle-related datafiles in this fashion ?
>
> Regards,
> Jay
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
>

I waited for someone that knows for sure to respond but I
don''t think Oracle data file are endian neutral. 
ZFS insures that a pool can be mounted on any endian system.
The application must then be the one to deal with it''s own data
layout. 

-r

Jason J. W. Williams writes:
 > Hi Jay,
 > 
 > We''ve moved (import/export) ZFS filesystems between an
Opteron-based
 > SunFire X4100 and T1 SPARC-based SunFire T2000 without any problems.
 > 
 > 1.) Export SPARC
 > 2.) Change FC array LUN masking.
 > 3.) Import Opteron.
 > 
 > Worked like a charm. :-) Was running solid for about two months (MySQL
 > DB). We just moved back to the T2000.
 > 
 > Best Regards,
 > Jason
 > 
 > On 11/20/06, Jay Sisodiya <Jay.Sisodiya at sun.com> wrote:
 > > I came across couple of articles (by Amy Rich) on BigAdmin abt ZFS.
In
 > > one of these articles, it is mentioned that with ZFS export/import,
one
 > > can move pool from SPARC to x64 or other way around without worrying
 > > about the Endian issues (target system will automatically re-write
the
 > > blocks with new endianness as needed).
 > >
 > > But later it talks about Endian conversion automatically happening
for
 > > ZFS meta data blocks only ... user data blocks are not taken care of.
 > > OK. Has anyone tried moving data in this fashion ? Have you tried
moving
 > > Oracle-related datafiles in this fashion ?
 > >
 > > Regards,
 > > Jay
 > > _______________________________________________
 > > zfs-discuss mailing list
 > > zfs-discuss at opensolaris.org
 > > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
 > >
 > _______________________________________________
 > zfs-discuss mailing list
 > zfs-discuss at opensolaris.org
 > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

On 11/21/06, Roch - PAE <Roch.Bourbonnais at sun.com>
wrote:
>
> I waited for someone that knows for sure to respond but I
> don''t think Oracle data file are endian neutral.
> ZFS insures that a pool can be mounted on any endian system.
> The application must then be the one to deal with it''s own data
> layout.
This may be a good place to look:
http://www.oracle.com/technology/deploy/availability/htdocs/xtts.htm

-- 
Mike Gerdts
http://mgerdts.blogspot.com/

Thank you for clarifying this. Just wanted to make sure we have no magic 
for Oracle here.

Regards,
Jay

Mike Gerdts wrote:
> On 11/21/06, Roch - PAE <Roch.Bourbonnais at sun.com> wrote:
>>
>> I waited for someone that knows for sure to respond but I
>> don''t think Oracle data file are endian neutral.
>> ZFS insures that a pool can be mounted on any endian system.
>> The application must then be the one to deal with it''s own
data
>> layout.
>
> This may be a good place to look:
> http://www.oracle.com/technology/deploy/availability/htdocs/xtts.htm
>