• Nenhum resultado encontrado

Compartilhamento de Arquivos

No documento Sis to Per 2001 (páginas 77-79)

Isto significa que o(s) arquivo(s) pode(m) ser acessado(s) por vários usuários ao mesmo tempo. Para isto ser viável o arquivo e as operações sobre ele devem ser multiplexadas no espaço ou no tempo.

No primeiro caso há várias cópias do arquivo e portanto os acessos a ele se sobrepõem. Há duas vantagens em manter cópias de um arquivo em pontos distintos do sistema, são elas: aumenta a disponibilidade dos dados e melhora o desempenho do sistema, pois o tempo para atender uma requisição será menor quando for usada um cópia mais próxima do cliente; e às vezes é interessante manter um cópia de trabalho do arquivo para armazenar alterações temporárias, até que as

alterações definitivas sejam definidas e possam ser efetuadas no arquivo. Todavia, nestes casos ocorre o problema de controle de coerência dos dados, isto é, deve-se decidir se a cópia na memória local é coerente com a cópia original, ou não.

No segundo caso os acessos ao arquivo são entrelaçados, ou seja, permitem que várias seqüências de operações oriundas de diversos clientes sejam executadas como em um sistema de compartilhamento do tempo. O problema neste caso, é evitar que as seqüências de operações interfiram umas com as outras evitando inconsistências e a geração de resultados errados, problema este conhecido por controle de concorrência.

O acesso a arquivos compartilhados pode ser remoto, via cache ou por carga e descarga. Em cada

caso pode ser feito para simples leitura ou escrita, para transações ou para sessões. Cada leitura/escrita, para transações ou para sessões. Cada leitura/escrita é uma solicitação/resposta ao/do servidor de arquivos. Transações são seqüências de operações de leitura/escrita, tratadas atenciosamente, ao mesmo arquivo. Geralmente, estas seqüências são delimitadas por construtores tipobegin/end. Sessões são seqüências de transações e operações de leitura e escrita.

O acesso remoto não mantém arquivos no cliente, todo o pedido de acesso é enviado ao servidor remoto via rede. Deste modo, só há uma cópia do arquivo e os acessos a ela são serializados pelo servidor. O problema é que esta serialização impede a concorrência e provoca atrasos. No caso de solicitações simples de leitura/escrita não há compartilhamento real e no caso de transações é necessário um controle de concorrência.

No acesso via cache parte do arquivo é mantido localmente para leitura e operações de escrita,

assim como falhas no acesso à cache local, resultam em acesso remoto e a correspondente

atualização da cache. Este procedimento reduz os atrasos e melhora a concorrência no sistema. O

controle de concorrência é usado tanto para operações simples de leitura e escrita quanto para transações, mas nestas também é controlada a coerência dos dados.

No acesso para carga ou descarga todo o arquivo é carregado para acesso local. Quando atualizado, o arquivo e carregado remotamente. Nos casos de leitura/escrita simples e de transações, os controles são os mesmos que os utilizados no acesso via cache. No caso de sessões, o

compartilhamento é ignorado, por se tratar de composições dos casos anteriores.

Como foi visto, o compartilhamento de arquivos cria problemas de coerência e de consistência dos dados, cuja solução depende do modelo semântico utilizado no procedimento de atualização dos dados nos arquivos compartilhados. Três modelos populares são:

(1) Modelo semântico do UNIX: o resultado de uma operação de escrita é propagado para o arquivo principal e suas cópias, imediatamente. O problema é que neste modelo supõe-se que não há atrasos além dos de propagação na rede de comunicação, que os arquivos compartilhados não são copiados e que todas as operações de leitura e escrita são dirigidas e podem ser serializadas pelo servidor de arquivos. Como em um sistema distribuído isto não é possível, deve-se utilizar uma política de controle write-through associada a um protocolo write-invalidate ou write-update para garantir a coerência das cópias obtendo, assim, um

modelo funcionalmente equivalente à semântica do UNIX.

(2) Semântica de transações: Os resultados de operações de escrita são armazenados temporariamente em uma memória de trabalho e só são efetivados no final da transação, quando determinadas condições de consistência forem satisfeitas. Neste caso, as cópias dos dados não são necessariamente sempre coerentes, mas garante-se a consistência dos resultados segundo alguma ordem de execução das transações. Caso algo de errado durante a execução de determinada transação os resultados parciais são descartados e o sistema é mantido no estado em que se encontrava antes do início da transação.

(3) O modelo semântico de sessões: o cliente utiliza uma cópia do arquivo na qual todas as alterações são feitas temporariamente. O resultado só é escrito permanentemente no final da

sessão, isto é, as atualizações permanentes são atrasadas mais do que no caso do modelo de transações. Neste caso, essencialmente não há compartilhamento de arquivos abertos simultaneamente por clientes diferentes, uma vez que as atualizações só são efetivadas quando do encerramento das sessões.

O problema do modelo de sessões é como fazer com que as cópias de arquivos escritos em seqüência sejam coerentes. Uma possibilidade é exigir que a toda operação de escrita corresponda um “fechar arquivo”, forçando sua atualização. Isto equivaleria à semântica do UNIX com política

write-through. Outra possibilidade é criar cópias apenas para leitura. Quando se desejar escrever

algo no arquivo, deve-se criar uma nova versão do mesmo, para atualizá-lo. O controle destas versões pode ser feito por uma função do serviço de diretório, o qual está em um nível hierárquico superior ao do serviço de arquivos. As atualizações seriam mantidas em um local temporário até a finalização da sessão. Quando alguém quiser escrever algo no arquivo é criada um nova versão, que se torna a versão corrente. Quando alguém quiser abrir um arquivo, sempre lhe é dada a versão mais recente.

Há vários esquemas para a resolução de conflitos pelo controle de versão, quando da escrita de um arquivo. Estes esquemas devem ser utilizados quando um processos tenta atualizar um arquivo, baseado em uma versão desatualizada, devido à atualização da versão corrente por outro processo. Três possíveis esquemas são:

(a) ignora conflito: Cria-se uma nova versão independentemente do que possa ter ocorrido no sistema

(b) resolve conflito de versão: Se o conjunto de dados atualizado no arquivo temporário e aquele gravado na versão corrente forem disjuntos é possível combinar os dois arquivos, mantendo todas as atualizações feitas.

(c) Resolve conflito de seriação: Se houver interseção entre o conjunto de dados no arquivo temporário e os já atualizados na versão corrente, as atualizações podem ser descartadas e o processo pode ser recomeçado com a cópia corrente do arquivo. Isto força uma ordenação serial e aleatória das atualizações.

No documento Sis to Per 2001 (páginas 77-79)

Documentos relacionados