Não é possível montar um sistema de arquivos UFS de Sparc Solaris para x86_64 Linux

1

Eu tenho um requisito para copiar uma grande quantidade de dados de um sistema Solaris 9 (Sparc) para um sistema SLES11 (x84_64).

O sistema Solaris é bastante antigo e a transferência de dados pela rede leva dias de inatividade.

Meu objetivo é atribuir um LUN de SAN ao meu sistema Solaris, copiar os dados dessa maneira (over fabric em vez de LAN) e reatribuir o LUN ao sistema Linux de destino.

Meu problema é que não consigo descobrir como montar o sistema de arquivos UFS da minha caixa do Linux.

Esta é a tabela de partições atual vista no Solaris:

Volume name = <        >
ascii name  = <HITACHI  OPEN-V      -SUN 7006 ffe00000>
bytes/sector    =  512
sectors = 4292870143
accessible sectors = 4292870110
Part      Tag    Flag     First Sector          Size          Last Sector
  0       root    wm                34       128.00MB           262177
  1       swap    wu            262178       128.00MB           524321
  2 unassigned    wm                 0            0                0
  3 unassigned    wm                 0            0                0
  4 unassigned    wm                 0            0                0
  5 unassigned    wm                 0            0                0
  6        usr    wm            524322         2.00TB           4292853725
  8   reserved    wm        4292853726         8.00MB           4292870109

Quando eu tento listá-lo usando o fdisk no sistema Linux, recebo:

 # fdisk -l /dev/sdl

Disk /dev/sdl: 2199.0 GB, 2199023255552 bytes
255 heads, 63 sectors/track, 267349 cylinders, total 4294967296 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/sdl doesn't contain a valid partition table

O mapeador de dispositivos, no entanto, parece estar ciente das partições (embora elas sejam compensadas por 1):

lrwxrwxrwx 1 root root 7 Nov  5 13:30 /dev/mapper/360060e8006cfd3000000cfd300000087 -> ../dm-3
lrwxrwxrwx 1 root root 8 Nov  5 13:30 /dev/mapper/360060e8006cfd3000000cfd300000087_part1 -> ../dm-38
lrwxrwxrwx 1 root root 8 Nov  5 13:30 /dev/mapper/360060e8006cfd3000000cfd300000087_part2 -> ../dm-39
lrwxrwxrwx 1 root root 8 Nov  5 13:30 /dev/mapper/360060e8006cfd3000000cfd300000087_part7 -> ../dm-40
lrwxrwxrwx 1 root root 8 Nov  5 13:30 /dev/mapper/360060e8006cfd3000000cfd300000087_part9 -> ../dm-41

Eu então tento montar o sistema de arquivos, mas esse é o resultado:

 # mount -t ufs -o ro,ufstype=sun /dev/disk/by-id/scsi-360060e8006cfd3000000cfd300000087-part7 /ldev87
mount: wrong fs type, bad option, bad superblock on /dev/mapper/360060e8006cfd3000000cfd300000087_part7,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

O dmesg não tem informações adicionais para mim. Apenas uma linha cada vez que eu tento montar:

[173168.020980] ufs_read_super: bad magic number

Parece que tenho suporte para o sistema de arquivos do ufs:

# grep ufs /proc/filesystems
        ufs

# modinfo ufs
filename:       /lib/modules/3.0.101-0.15-default/kernel/fs/ufs/ufs.ko
license:        GPL
srcversion:     4BC9796D2E230B27387BE46
depends:
supported:      yes
vermagic:       3.0.101-0.15-default SMP mod_unload modversions
signer:         SUSE Linux Enterprise Secure Boot Signkey
sig_key:        3F:B0:77:B6:CE:BC:6F:F2:52:2E:1C:14:8C:57:C7:77:C7:88:E3:E7
sig_hashalgo:   sha256

# less /proc/modules | grep ufs
ufs 79510 0 - Live 0xffffffffa07e4000

O Linux só consegue abrir volumes da Sun até um determinado tamanho (que está abaixo de 2 TB)? Ou há algo especial que eu preciso fazer no sistema Solaris para preparar o sistema de arquivos para ser lido por um sistema Linux?

Espero que alguém tenha uma ideia.

Atualizar Para qualquer visitante futuro com o mesmo problema, meu problema parece ter sido o tamanho do LUN. 2TB não funcionou e nem 1.8TB, mas 1TB funcionou bem. Eu não tenho tempo para descobrir onde o limite realmente está, mas há claramente um.

    
por Omnipresence 06.11.2014 / 17:39

0 respostas