Trouble converting FileSystem metadata with fscdsconv in Linux

[RaulGomez]

Hello everyone,

I'm in the process of migrating a Solaris 5.10 server to Linux Red Hat 6.4 

At this point, I'm trying to convert the byte order of some volumes that come from Solaris in my Linux server using the following command:

/opt/VRTS/bin/fscdsconv -y -e -f /tmp/vxConv/dbtemp01.tmp -t os_name=Linux,arch=x86 /dev/vx/rdsk/dgtemp/dbtemp01

Note: Because of the text formating, the above command could span two lines, but it I'm executing it in just one

And I get the following errors:

UX:vxfs fscdsconv: ERROR: V-3-20012: not a valid vxfs file system
UX:vxfs fscdsconv: ERROR: V-3-24426: fscdsconv: Failed to migrate.

Searching for a solution of these errors in the forums, I've found this post, where the user mikebounds gives some steps to migrate Solaris to Linux. I've found that I've replicated these steps but I get stuck on the fscdsconv because the beforementioned errors.

Does anyone know what could be happening here or have any sugestion to share?

Software Versions:

• RHEL 6.4 x86_64
• Veritas Storage Foundation Enterprise 6.2.0.100 on Linux
• Solaris 5.10
• Veritas 5.0 on Solaris
• Disk layout v7
• vxfs filesystem format

Thank you very much in advance for any help/ideas to solve this

Best regards

Raul

[mikebounds · Accepted solution]

Looking at the man page, it reads as you need to either run:

fscdsconv -e (for export) on the Solaris system

or

fscdsconv -i (for import) on the Linux system

So can you confirm you ran your command in your post above on the Solaris system and if you did and this has failed, have you tried running the import on the Linux system instead?

Mike

[RaulGomez]

Deleting accidental double post...

[RaulGomez]

Hello Mike,

We are running everything now on the Linux server

Running the command with -i yields a different error message:

UX:vxfs fscdsconv: ERROR: V-3-20318: file system dirty, run fsck first
UX:vxfs fscdsconv: ERROR: V-3-24426: fscdsconv: Failed to migrate.

It seems that an fsck is needed, but running it on Linux gives me another error:

UX:vxfs fsck.vxfs: ERROR: V-3-20012: not a valid vxfs file system invalid super-block
UX:vxfs fsck.vxfs: ERROR: V-3-20694: cannot initialize aggregate file system check failure, aborting ...

Apparently, this is going to work, but I think I'm still missing something.

To give you more context, our Solaris server crashed very badly, so we can't run anything on it. When we imported the DGs, we had to use the -C option in order to clear the message that the DG was still in use on another server "vxdg -o useclonedev=on -o updateid -C import ${DG_NAME}", so this message about the "dirty FS" could be related to that

Do you have any idea about this new message? I think we are going to be able to import the FS

Thank you very much in advance, regards...

Raul

[mikebounds · Accepted solution]

If your Solaris server crashed, then at a diskgroup level, the diskgroup contains the hostname of the crashed server so you have to clear this using the "-C" flag to import the diskgroup.

This is completley independent of the filesystems - if your Solaris server crashed, then the filesystem were not cleanly umounted and therefore the filesystems need to have an fsck to clean up the filesystem, but you can't run an fsck because fsck command does not understand the byte order on Linux

To the fscdsconv import you need to do on a clean filesystem, which you don't have so the only option I can see is to import the diskgroup on any Solaris SPARC (or other systems using the same Endian, such as AIX or HP-ux) that has SF installed so that you run fsck on the vxfs filesystems.

Mike

[RaulGomez]

Hello Mike,

We managed to find an old Solaris server, we are preparing it to try the conversion tomorrow. I'll let you know how it goes

Regards

Raul

[RaulGomez]

Hello Mike,

We are trying to run the fscdsconv in Solaris.

While importing the DGs on Solaris, we found this error with some DGs

VxVM vxvol ERROR V-5-1-1256 Volume dbdata20c-dgdb01-I01 usage type is relayout, not fsgen
VxVM vxrelayout ERROR V-5-1-2348 DST plex is missing in the relayout tree
VxVM vxrelayout ERROR V-5-1-6527 Error in opening device /dev/vx/dsk/dgdb01/dbdata20c-dgdb01-I01
VxVM vxrelayout ERROR V-5-1-10127 associating subdisk tagmastore-usp3_1710-03 with dbdata20c-dgdb01-01:
        Subdisk tagmastore-usp3_1710-02 would overlap subdisk tagmastore-usp0_1692-03
VxVM vxrelayout INFO V-5-1-2291 Attempting to cleanup ...

Searching for a solution in the web, we found that running vxvol -g DG start VOLUME should solve this, but we have this new error:

root@solaris-pivote # vxprint -g dgdb01 -vt | grep -i disa  
v  dbdata20c-db-S01-U01 - DISABLED EMPTY    100619264 SELECT   -        fsgen
v  dbdata20c-db-U01 -     DISABLED EMPTY    251549184 SELECT   -        fsgen
root@solaris-pivote # vxvol -g dgdb01 start dbdata20c-db-S01-U01
VxVM vxvol ERROR V-5-1-1205 Volume dbdata20c-db-S01-U01 has no complete, non-volatile ACTIVE plexes
root@solaris-pivote # vxvol -g dgdb01 start dbdata20c-db-U01
VxVM vxvol ERROR V-5-1-1205 Volume dbdata20c-db-U01 has no complete, non-volatile ACTIVE plexes
root@solaris-pivote # vxprint -g dgdb01 -vt | grep -i disa  
v  dbdata20c-db-S01-U01 - DISABLED EMPTY    100619264 SELECT   -        fsgen
v  dbdata20c-db-U01 -     DISABLED EMPTY    251549184 SELECT   -        fsgen

Do yo have any comment about this?

Thanks in advance, regards...

[RaulGomez]

Mike,

We found that the previus error was caused by a couple of deleted volumes that we are not using anymore, so we proceeded with the fscdsconv in Linux successfully (after running fsck and mounting and unmounting the volumes in Solaris). Right now, we are converting the endian of the Oracle .dbf DataFiles :D This process is going to take a few hours (there's around 12TB of .dbf DataFiles) but it is going great so far...

As a note: We had to run the fscdsconv in Linux because we had an error in Solaris saying there wasn't enough disk space to store the recorevy files, that was because the metadata of the generated files said they were of the size of the volume it represented. For some reason, Solaris was unable to detect the correct size and refused to try to write the files on disk. In Linux, the files were written, if you run an "ls -l" it showed files of several TB in size, but running "du -h" on each file showed their real size of about a few hundred of MB

Thank you very much for your help and advices, best regards...

Raul