On Mon, 16 Jul 2001, Heber Blain Goncalves wrote:
> - Onde ficam armazenados no disco esses inodes? Na FAT?
Existem 4 �reas de um filesystem num dispositivo (disco): boot,
superblock, inodetable, datablocks. O boot tem tamanho fixo
(normalmente) e no superblock est�o as informa��es de tamanho do
filesystem, n�mero de inodes, free datablocks table. Existem muitas
c�pias do superblock espalhadas num dispositivo, para permitir que se
recupere o resto do sistema mesmo que o v�rios dos superblocks sejam
perdidos.
> - Por usar o mesmo inode, o hardlink ocuparia menos espaco em disco do
> que o symlink?
Sim. Um hardlink ocupa apenas uma entrada num diret�rio, n�o "gasta"
outro inode. O symbol link n�o "garante" que o conte�do do arquivo
(inode+databloks) continuem existindo se o arquivo principal for
removido (o symbol link passa a apontar para um arquivo inexistente).
> - Em que situacao eu utilizaria um hardlink, ja que me eh costumeiro
> somente criar symlinks?
Muitas coisas usam hardlink. A mais comum � ter um �nico programa com
v�rios nomes (gzip/gunzip, sendmail/newaliases/mailq, ...).
ls -l `which gzip gunzip sendmail newaliases mailq`
Ah, o sendmail usa link simb�lico... :)
symbol link pode apontar para qualquer coisa, j� hardlink tem que
apontar para algo que tenha um inode, e um inode no MESMO filesystem
do diret�rio onde ele vai ser associado a um nome de arquivo.
Sistema de "news" tem um arquivo por mensagem e cada �rea est� num
diret�rio, s� que uma mensagem pode estar em v�rias �reas
(crossposting) e usa-se hardlink para evitar excesso de arquivos
duplicados. A diferen�a de uso de disco nesses casos � mostruosa.
A aplica��o mais comum com hardlinks (e realmente VITAL para o
funcionamento de v�rios aplicativos no Unix) � para se criar arquivos
de forma controlada, evitando que v�rias tasks usem um mesmo recurso,
criando uma situa��o onde somente UMA task ter� direito de usar o
recurso.
O recurso � usualmente um arquivo como um mailbox, um arquivo de
dispositivo como /dev/ttyS1, ...
Imagine uma situa��o onde v�rios programas podem estar querendo
acessar um mesmo recurso, um arquivo por exemplo. Uma situa��o t�pica
� o mailbox do usu�rio:
- O procmail � acionado pelo sendmail quando chega uma mensagem
- O POP server vai ler a caixa postal
- Um programa local (pine, mutt) podem querer abrir a caixa
postal
O sistema � multitask, essas tasks podem todas, num mesmo momento,
querer acessar a caixa postal do usu�rio em /var/spool/mail/logname, e
alterar o conte�do desse arquivo.
Se n�o houver conten��o de acesso entre as tasks, vai sair besteira
com 100% de certeza.
Existe a t�cnica chamada de "lockfile" onde um outro arquivo � criado,
e somente UMA task ter� controle sobre esse arquivo, e essa task ent�o
poder� acessar o arquivo de interesse sabendo que s� ela tem direito
de alterar o conte�do.
O kernel GARANTE que a opera��o de "ln" e "mv" s�o "at�micas", isto �,
somente UMA task vai receber OK quando tentar mover/linkar um arquivo
com outro nome, de forma que somente essa task ter� o "direito" de
acesso ao recurso. A opera��o � equivalente aos comandos:
echo $$ >tmp_file_de_nome_unico
ln tmp_file_de_nome_unico file.lock
"tmp_file_de_nome_unico" � um arquivo que somente a task sabe o nome,
e deve ser construido de forma a n�o coincidir com qualquer outro nome
que outra task queira usar.
"file.lock" � um nome padronizado e que todas as tasks que quiserem
usar o determinado recurso devem "concordar em usar". Para mailbox �
/var/spool/mail/logname.lock.
O conte�do do lockfile tamb�m �, usualmente, o "task number" da task
que est� querendo o recurso ($$ num shellscript). Isso permite que um
programa inspecione o file.lock e descubra que a task_number al�
armazenada j� n�o est� mais rodando no sistema, e com isso o programa
pode eliminar o "dead lockfile" e tentar obter o controle sobreo
lockfile novamente.
Um "dead lockfile" � o resultado de algum problema que impediu a task
que tinha controle sobre o lockfile de remove-lo ao finalizar a
opera��o (bug, reset, "kill -9", ...).
A task que "conseguiu sucesso" na chamada do ln passa ent�o a poder
fazer o que quiser com o mailbox, e no final ela deve eliminar o
lockfile.
As outras tasks ficam executando "sleep N" e tentando novamente mover
seu "tmp_file_de_nome_unico" para "file.lock" para poder acessar a
caixa postal (e verificando se n�o � um dead lockfile).
Os kernels hoje em dia tem a fun��o de "lock", mas existem muitas
coisas que ainda usam lockfile por "tradi��o", e os programas mant�m
essa tradi��o para garantir que sempre ir�o funcionar da mesma forma
em qualquer unix-like.
A atomicidade das fun��es de ln e mv s�o garantidas desde o projeto
original do primeiro Unix criado, e nenhum unix-like vai quebrar essa
caracter�stica do filesystem.
Por isso � imposs�vel querer usar um filesystem como FAT ou samba para
serem "nativamente" os root-filesystems de um sistema Unix: n�o h�
como simular opera��es elementares como essas nestes sistemas de
aquivos.
--- Wagner [EMAIL PROTECTED]
Assinantes em 16/07/2001: 2250
Mensagens recebidas desde 07/01/1999: 123249
Historico e [des]cadastramento: http://linux-br.conectiva.com.br
Assuntos administrativos e problemas com a lista:
mailto:[EMAIL PROTECTED]
