Página seguinte
Página anterior
Índice
Esta é uma coleção de perguntas que volte e meia são feitas, e que podem cair na categoria das PF (perguntas freqüentes). Se você sentir que há alguma pergunta que deva ser acrescentada a lista, por favor sinta-se à vontade para me enviar (mas, por favor inclua a resposta, obrigado!).
Sinto muito, mas não. O Iomega usa um formato de dados do proprietário nos seus cartuchos de fita 'Ditto 2GB'. O mantenedor de ftape tem sido incapaz de conseguir a informação necessária para incluir o suporte do vendedor.
Você pode alcançar uma cópia de segurança bastante respeitável e restaurar a velocidade com o ftape: um Colorado DJ-20 e um controlador Adaptec 1542CF, que foram medidos a 4.25Mbyte/min e sustentaram o índice de transferência de dados (sem compactação) através de um arquivo de compactação de 70 Mbytes, enquanto comparou-se o arquivo na fita com os dados no disco IDE. A velocidade do ftape é na maior parte dependente do índice de transferência de dados de seu FDC: O AHA1542CF tem um FDC ``post-1991 82077'', e ele empurrará a unidade de fita a 1Mbit/seg. Se você tiver um FDC que pode somente entregar índices de dados a 500Kbit/seg, você verá bem aproximadamente metade do índice de transferência.
Há três maneiras de você fazer isto (por ordem de preferência pessoal).
Enquanto estamos aqui, eis os significados de vários níveis de rastro.
- 0 Bugs
- 1 + Errors
- 2 + Warnings
- 3 + Information
- 4 + More information
- 5 + Program flow
- 6 + FDC/DMA info
- 7 + Data flow
- 8 + Everything else
Usando o insmod para mudar o nível de rastro
Se você estiver usando o mecanismo de módulos para carregar o programador ftape você pode especificar o nível de rastro como uma opção para o comando insmod.
/sbin/insmod ftape.o tracing=<tracing-level>
Usando o mt para mudar o nível de rastro
O controlador ftape tem um programa nele que permite a opção fsr no mt de ser usada para estabelecer o nível de localização. O zftape não tem este programa.
mt -f /dev/ftape fsr <tracing-level>
O uso do comando fsr no mt é um programa, e provavelmente desaparecerá ou mudará com o tempo.
Recompilar para mudar o nível de localização
O arquivo tracing.c contém uma linha int tracing = 3;. Mude o 3 para o que quer que seja apropriado e recompile.
Não. O software DOS combina com as especificações do QIC-80 sobre o desenho do sistema de arquivo do DOS, e deveria ser um pequeno problema para escrever um programa que pode ler/escrever no formato do DOS. Na verdade, eu apostaria que criar uma interface agradável do usuário seria um problema ainda maior.
Estas são realmente perguntas de tar: Por favor leia a página man e a página info. Se você não conseguir em nenhuma delas, tente `tar--help 2>&1 | less'.
Se sua versão do tar é v1.11.1 ou mais antiga, pense em atualizá-la para v1.11.8 - Esta versão pode chamar GNU zip diretamente (isto é: ela suporta a opção -z) e tem uma ajuda elaborada incluída. Também, compila bem da caixa no Linux.
É triste dizer que existem algumas placas SVGA e placas Ethernet que não decodificam seus endereços corretos. Isto tipicamente acontece quando os protetores ftape estão numa faixa de 0x1a0000 a 0x1c0000. De alguma maneira os ciclos de escrita DMA ficam destruídos e todos os outros bytes tem um valor ruim (0xff). Estes problemas aconteceram tanto com SVGA quanto com placas Ethernet. Sabemos de pelo menos uma placa (ruim?) VGA ATI 16bit que ocasionou isto.
A solução mais fácil é colocar a placa num slot de 8bit (não é o suficiente para reconfigurar a placa para os transferidores de 8bits). Mover o protetor ftape para longe da faixa do VGA é uma solução apenas parcial; todos os protetores DMA usados no Linux podem ter este problema! Vamos deixar este aqui claro. Isto não tem nada a ver com o software ftape.
O programa insmod pode verificar a versão kernel contra a versão que ftape foi compilado de duas maneiras: pode diretamente comparar o número da versão kernel gravada no módulo ftape contra a versão do kernel executado, ou se tanto o kernel e o ftape estiverem compilados com símbolos versionados, compare a versão dos símbolos kernel usados.
Se tiver atualizado sua versão de GCC para v2.7.0 ou mais nova, você deve recompilar os utilitários dos módulos com gcc v2.7.x.
As versões mais novas de insmod permitem forçar a inserção de um módulo para dentro de um kernel, mesmo que a linha da versão esteja incorreta.
Quando você diz sim para CONFIG_MODVERSIONS durante o`make config', todos os símbolos exportados pelo kernel, isto é, os símbolos que os módulos carregáveis podem ver são aumentados para incluir uma soma de verificação através dos tipos dos parâmetros de chamada/retorno. Isto permite que o insmod detecte se a definição de uma variável ou de uma função no kernel mudou desde o momento quando o ftape foi compilado.
Isto assegura o alto grau de segurança, de maneira que você não quebra o kernel porque você usou um módulo antiquado com o seu kernel.
Se você capacita CONFIG_MODVERSIONS no kernel, certifique-se de que você tem `-DMODVERSIONS -include /usr/include/linux/modversions.h' não comentado na linha MODULE_OPT no Makefile do ftape. Contrariamente, se você não tiver CONFIG_MODVERSIONS capacitado, certifique-se de que você o tem comentado.
Você lembrou de aplicar o ajuste ksyms.cpara o kernel? Se não, o arquivo README.linux-1.2 na distribuição da fonte.
Você tem esta queixa se você não tiver apagado sua recém formatada fita. Isto é porque o ftape espera um ``cabeçalho mágico'' na fita, para poder interpretar o segmento do cabeçalho de sua própria maneira (por exemplo, marcas de arquivo). Para remover o problema, digamos `mt -f /dev/nftape erase'.
Todas estas ferramentas foram desenvolvidas pelo projeto GNU, e a fonte (página do manual) podem ser buscadas de qualquer servidor que transfere arquivos no mundo (inclusive o ftp.funet.fi, tsx-11.mit.edu, e o sunsite.unc.edu). De qualquer maneira eles podem ser buscados do servidor pessoal GNU oficial: prep.ai.mit.edu [18.71.0.38]:/pub/gnu. As versões mais recentes (como a de 12 de setembro de 1996) são:
cpio: 2.4.2 (cpio-2.4.2.tar.gz)
dd: 3.13 (fileutils-3.13.tar.gz)
mt: 2.4.2 (cpio-2.4.2.tar.gz)
tar: 1.11.8 (tar-1.11.8.tar.gz)
gzip: 1.2.4 (gzip-1.2.4.tar.gz)
Elas todas compilam fora da caixa Linux v1.0.4 / libc v4.5.19 / gcc v2.5.8.
Se você desejar ajudar no desenvolvimento do ftape, ou quiser acrescentar alguma utilidade (por exemplo, um programa de formatação de fita), você vai precisar daqueles padrões QIC apropriados. O(s) padrão(ões) para conseguir é: QIC-80, -117, -3010, e 3020. QIC-117 descreve como os comandos são enviados para a unidade de fita (inclusive a sincronização etc.), por isso você provavelmente nunca vai precisar dele. O QIC-80/3010/3020 descreve a parte de nível mais alto, tal como o projeto da fita, o código ECC, sistema de arquivo padrão. Você pode ter os padrões QIC nos seguintes endereços:
Quarter Inch Cartridge Drive Standards, Inc. 311 East Carrillo Street
Santa Barbara, California 93101
Phone: (805) 963-3853
Fax: (805) 962-1541
Nota: Estão registrados como `Freeman Associates, Inc.' na lista telefônica.
Quando usar a compactação, e em geral ela pode ser benéfica para especificar tar, que deve bloquear a saída para dentro dos blocos grandes. Desde que o ftape corta as coisas para dentro de blocos de 29Kbytes dizendo `-b58' ele deve ser ótimo.
``Por que 29Kbytes?'', eu ouvi você gritar. Bem, o padrão QIC-80 especifica que todos os dados devem ser protegidos por um Código de Correção de Erro (ECC). O código especificado no padrão QIC-80 é conhecido como código Reed-Solomon (R-S). O código R-S leva 29 bytes de dados e gera 3 bytes de paridade. Para melhorar o desempenho do código ECC, os bytes de paridade são gerados através dos setores de 29 1Kbyte. Assim o ftape leva 29Kbytes de dados, adiciona 3Kbytes de paridade ECC, e escreve 32Kbytes para a fita de uma vez. Por este motivo, o ftape lerá e escreverá sempre blocos de 32Kbytes para poder detectar (e corrigir) os erros de dados.
Se você for curioso, e desejar saber mais, olhe nos arquivos ecc.c e ecc.h, para ter uma explicação do código e uma referência a um livro de texto nos códigos Reed-Solomon.
Se você olhar a diferença, você notará que o ftape sempre detecta 2784 setores a mais que o DOS.
O número que o ftape relata é correto (naturalmente:-). Cada fita QIC-3020 corretamente formatada tem 2784 setores em posições fixas que estão marcadas no setor ruim do mapa. Para citar das especificações:
``As faixas 5,7,9,11,13,15,17,19,21,23,25 e 27 dentro de 4 segmentos tanto de EOT ou BOT estão propensas a índices maiores de erros devido a falha de segurança impressa. Por isso, estas regiões devem ser mapeadas como ruins na hora da formatação e entrar no setor ruim indicando que todos os setores dentro dos segmentos identificados são ruins.''
Isto dá 12 faixas dos segmentos * 2 * 4 e dos setores * 29 == 2784 setores.
Assim o ftape escolhe relatar o número real de setores que não podem ser usados na fita, enquanto o DOS dá um número mais otimista dando uma melhor indicação da qualidade da fita (o comportamento do ftape pode mudar no futuro para detectar a formatação correta e exibir os números separados. No entanto isto tem uma prioridade bem baixa).
QIC-3010 e QIC-3020 são fitas parecidas com relação a isso.
As opções de tempo de compilação NO_TRACE e NO_TRACE_AT_ALL no ftape controlam a quantia de registro do sistema. Acrescente o que achar apropriado para a linha FTAPE_OPT no Makefile e recompile.
Tem havido alguns relatórios de polimento de sapato. Isto é quando a fita parece simplesmente correr para trás e para frente interminavelmente. Isto foi visto num Jumbo 250 (74407.3051@compuserve.com) e num Iomega 250 Ditto Insider (tom@opus.cais.com). No último caso foi reduzido devido ao uso de um ELF Linux e imprimindo num disco rígido SCSI (conectado a um Adaptec 1542cf). Por favor faça contato se você tiver atualização para este problema.
O arquivo modversions.h é criado quando o kernel é compilado com o item da configuração CONFIG_MODVERSIONS ligado. Com esta opção capacitada, o arquivo será criado durante o passo make dep.
Mais uma dica conveniente é que um make mrproper removerá /usr/include/linux/modversions.h. Você precisará reconfigurar o kernel e fazer um make dep para conseguir o arquivo de volta.
(EOM é "Fim de Mídia Gravada", a posição logo depois que todos os dados já foram gravados para a fita).
Não se pode usar os arquivos de fita como arquivos num sistema de arquivo comum.
Em princípio, uma fita não permite nada a não ser novos dados acrescidos em EOM. Porém, se um se posiciona exatamente no meio de dados já gravados, e começa a escrever, então o programa de controle primeiro apaga todos os arquivos seguintes (movendo assim o EOM para a posição real) e então começa a escrever.
Deste modo, o novo EOM depois de terminar o processo da escrita, é então colocado depois dos dados recentemente gravados.
Uma das conseqüências é claro, é que escrever para a fita no meio de uma área já gravada, é destrutivo no sentido de que não somente sobrescreve o arquivo onde a fita está posicionada, mas também destrói todos os arquivos seguintes.
Você deve só ver que isto é você tentando o módulo insmod o ftape.o. Tente primeiro executar swapout. Está provido com a fonte fora da rede do ftape. Não aparece na fonte ftape que está provida com o kernel.
Aqui está um exemplo de como você pode estabelecer seu arquivo rc.local para usá-lo:
# Instale o Dispositivo de Disquete
if [ -f /boot/modules/`uname -r`/misc/ftape.o ]; então
echo Installing ftape for Linux `uname -r`
swapout
insmod /boot/modules/`uname -r`/misc/ftape.o
fi
Por favor note que você não terá este tipo de problema se você compilar o programa de controle ftape para dentro do kernel.
Sim. O programa de controle simplesmente atualiza um contador interno quando aqueles comandos são emitidos. A fita deve se mover para o local apropriado no próximo acesso de leitura ou escrita a unidade de fita.
Página seguinte
Página anterior
Índice
|
