Um parâmetro de projeto importante para o desempenho OS foi, o que levou a minha escolha para o sistema de arquivos. Eu tinha aprendido um punhado de técnicas de gerenciamento de arquivos, e passei algum tempo analisando o que eu sabia antes de fazer uma escolha. Estes eram os candidatos:
North Star DOS eo UCSD p-sistema utilizado o método mais simples: de alocação de arquivos contíguos. Ou seja, cada arquivo ocupa setores consecutivos no disco. O diretório do disco só precisa manter o controle do primeiro setor e o comprimento para cada arquivo - muito compacto. Acesso aleatório aos dados do arquivo é tão rápido quanto o acesso sequencial, porque é trivial para calcular o setor que você deseja. Mas a grande desvantagem é que uma vez que um arquivo é encaixotados por outros arquivos no disco, ele não pode crescer. O arquivo inteiro teria então de ser transferido para um novo local com mais espaço livre contíguo, com a localização de idade deixando um "buraco". Depois de um tempo, tudo o que resta são os buracos. Então você tem que fazer um time-consuming "pack" para baralhar todos os arquivos juntos e fechar os buracos. Decidi as desvantagens da alocação contígua eram muito graves.
UNIX utiliza uma abordagem multi-camadas inteligente. Para arquivos pequenos, a entrada de diretório para um arquivo tem uma pequena tabela dos setores que compõem o arquivo. Esses setores não precisam ser contíguos, por isso é fácil de estender o arquivo. Se o arquivo fica muito grande para a lista para caber na tabela, UNIX adiciona uma camada. Os setores listados na tabela há dados de referência mais longo no arquivo, em vez disso, cada entrada identifica um setor que em si não contém nada, mas uma lista de setores de dados de arquivo. Se o arquivo fica enorme, ainda outra camada é adicionada - as entradas da tabela de referência de cada um setor cujas entradas de referência de um sector cujas entradas identificar os dados do arquivo. Acesso aleatório aos dados do arquivo é muito rápido para arquivos pequenos, mas como os arquivos ficam maiores e o número de camadas de crescer, se vai levar um ou dois discos adicionais lê apenas para encontrar a localização dos dados que você realmente quer.
CP / M não controlar espaço em disco diretamente em termos de setores. Em vez disso, agrupados setores juntos em um "cluster" ou "unidade de alocação". A CP original / M foi projetado especificamente em torno de 8 "discos, que tinha 2.002 setores de 128 bytes cada. Fazendo cada cluster 8 sectores (1K), havia menos de 256 clusters em um disco. Assim, os clusters podem ser identificadas usando apenas um byte. A entrada de diretório para CP / M tinha uma tabela de 16 entradas dos clusters no arquivo, portanto, para um arquivo de acesso 16K ou menos tanto aleatório e seqüencial foram rápida e eficiente. Mas quando um arquivo excedeu 16K, precisava de uma entrada de diretório completamente novo para armazenar um número adicional de 16K cluster. Não houve ligação entre essas entradas, pois eles simplesmente continha o mesmo nome e um número identificando qual seção do arquivo que representava (o "ponto"). Isso levou a um pesadelo em potencial de desempenho, especialmente para acesso aleatório. Ao alternar entre extensões, o sistema teve que realizar sua busca padrão linear do diretório para um arquivo com o nome correto e extensão. Esta pesquisa pode levar várias leituras de disco antes de os dados solicitados foi localizado.
Microsoft Stand-Alone Disk BASIC usou o File Allocation Table (FAT). Ao contrário de todos os outros sistemas de arquivos, o sistema FAT separa a entrada de diretório (que tem o nome do arquivo, tamanho, etc) a partir do mapa de como os dados são armazenados (o FAT). Eu não vou dar uma explicação detalhada de como isso funcionou aqui como o sistema tem sido bem documentada, como o meu artigo 1983 Um olhar do interior em MS-DOS em http://www.patersontech.com/dos/Byte/InsideDos.htm Como CP / M, BASIC usado um cluster 1K de modo que, mais uma vez, havia menos de 256 no padrão 8 "disquete do dia. O FAT precisa de uma entrada por cluster, bem como a entrada do BASIC necessário para ser apenas um byte, então o ajuste FAT dentro de dois setores de 128 bytes. Este tamanho reduzido também significava que era prático, mesmo com a memória limitada do tempo, para manter o FAT inteiro na memória em todos os momentos.
Para mim, o grande apelo do sistema FAT foi que você nunca teve de ler o disco apenas para encontrar a localização dos dados que você realmente queria. Entradas FAT estão em uma cadeia - você não pode chegar ao fim sem visitar cada entrada no meio - para que seja possível o sistema operacional teria de passar por muitas entradas encontrar a localização dos dados. Mas com o FAT inteiramente na memória, passando por uma longa cadeia ainda seria 100 vezes mais rápido do que um único setor ler de um disquete.
Outra coisa que eu gostei sobre FAT foi sua eficiência espaço. Não havia mesas de setores ou grupos que podem ser meio cheio, porque o arquivo não foi grande o suficiente para precisar delas. O tamanho do FAT foi criado pelo tamanho do disco.
Quando eu projetei DOS eu sabia que ajuste o número de cluster em um único byte, limitando o número de clusters a 256, não iria fazer o trabalho como discos ficou maior. Eu aumentei a entrada de FAT para 12 bits, permitindo que mais de 4000 clusters. Com um tamanho de cluster de até 16K bytes, isso permitiria que para discos tão grande quanto 64 MB. Você poderia até mesmo empurrá-lo para um cluster de 32K e tamanho do disco de 128 MB, apesar de que grande cluster poderia desperdiçar um espaço muito. Estes tamanhos de disco parecia enorme para mim em 1980. Só recentemente se tivéssemos visto os discos de 10MB primeiro disco saiu para microcomputadores, e que o tamanho parecia absurdamente luxuoso (e caro).
Obviamente, eu não sou visionário. Tamanho do disco tem crescido mais rapidamente do que qualquer atributo de computador, até por um fator de 100.000. (Tamanho da memória típica é até por um fator de 30.000, enquanto a velocidade do clock é apenas até 1000x.) Microsoft estendeu a entrada do FAT para 16 bits, em seguida, para 32 bits para acompanhar. Mas aí o FAT tão grande que já não era mantido inteiramente na memória, tirando a vantagem de desempenho.
North Star DOS eo UCSD p-sistema utilizado o método mais simples: de alocação de arquivos contíguos. Ou seja, cada arquivo ocupa setores consecutivos no disco. O diretório do disco só precisa manter o controle do primeiro setor e o comprimento para cada arquivo - muito compacto. Acesso aleatório aos dados do arquivo é tão rápido quanto o acesso sequencial, porque é trivial para calcular o setor que você deseja. Mas a grande desvantagem é que uma vez que um arquivo é encaixotados por outros arquivos no disco, ele não pode crescer. O arquivo inteiro teria então de ser transferido para um novo local com mais espaço livre contíguo, com a localização de idade deixando um "buraco". Depois de um tempo, tudo o que resta são os buracos. Então você tem que fazer um time-consuming "pack" para baralhar todos os arquivos juntos e fechar os buracos. Decidi as desvantagens da alocação contígua eram muito graves.
UNIX utiliza uma abordagem multi-camadas inteligente. Para arquivos pequenos, a entrada de diretório para um arquivo tem uma pequena tabela dos setores que compõem o arquivo. Esses setores não precisam ser contíguos, por isso é fácil de estender o arquivo. Se o arquivo fica muito grande para a lista para caber na tabela, UNIX adiciona uma camada. Os setores listados na tabela há dados de referência mais longo no arquivo, em vez disso, cada entrada identifica um setor que em si não contém nada, mas uma lista de setores de dados de arquivo. Se o arquivo fica enorme, ainda outra camada é adicionada - as entradas da tabela de referência de cada um setor cujas entradas de referência de um sector cujas entradas identificar os dados do arquivo. Acesso aleatório aos dados do arquivo é muito rápido para arquivos pequenos, mas como os arquivos ficam maiores e o número de camadas de crescer, se vai levar um ou dois discos adicionais lê apenas para encontrar a localização dos dados que você realmente quer.
CP / M não controlar espaço em disco diretamente em termos de setores. Em vez disso, agrupados setores juntos em um "cluster" ou "unidade de alocação". A CP original / M foi projetado especificamente em torno de 8 "discos, que tinha 2.002 setores de 128 bytes cada. Fazendo cada cluster 8 sectores (1K), havia menos de 256 clusters em um disco. Assim, os clusters podem ser identificadas usando apenas um byte. A entrada de diretório para CP / M tinha uma tabela de 16 entradas dos clusters no arquivo, portanto, para um arquivo de acesso 16K ou menos tanto aleatório e seqüencial foram rápida e eficiente. Mas quando um arquivo excedeu 16K, precisava de uma entrada de diretório completamente novo para armazenar um número adicional de 16K cluster. Não houve ligação entre essas entradas, pois eles simplesmente continha o mesmo nome e um número identificando qual seção do arquivo que representava (o "ponto"). Isso levou a um pesadelo em potencial de desempenho, especialmente para acesso aleatório. Ao alternar entre extensões, o sistema teve que realizar sua busca padrão linear do diretório para um arquivo com o nome correto e extensão. Esta pesquisa pode levar várias leituras de disco antes de os dados solicitados foi localizado.
Microsoft Stand-Alone Disk BASIC usou o File Allocation Table (FAT). Ao contrário de todos os outros sistemas de arquivos, o sistema FAT separa a entrada de diretório (que tem o nome do arquivo, tamanho, etc) a partir do mapa de como os dados são armazenados (o FAT). Eu não vou dar uma explicação detalhada de como isso funcionou aqui como o sistema tem sido bem documentada, como o meu artigo 1983 Um olhar do interior em MS-DOS em http://www.patersontech.com/dos/Byte/InsideDos.htm Como CP / M, BASIC usado um cluster 1K de modo que, mais uma vez, havia menos de 256 no padrão 8 "disquete do dia. O FAT precisa de uma entrada por cluster, bem como a entrada do BASIC necessário para ser apenas um byte, então o ajuste FAT dentro de dois setores de 128 bytes. Este tamanho reduzido também significava que era prático, mesmo com a memória limitada do tempo, para manter o FAT inteiro na memória em todos os momentos.
Para mim, o grande apelo do sistema FAT foi que você nunca teve de ler o disco apenas para encontrar a localização dos dados que você realmente queria. Entradas FAT estão em uma cadeia - você não pode chegar ao fim sem visitar cada entrada no meio - para que seja possível o sistema operacional teria de passar por muitas entradas encontrar a localização dos dados. Mas com o FAT inteiramente na memória, passando por uma longa cadeia ainda seria 100 vezes mais rápido do que um único setor ler de um disquete.
Outra coisa que eu gostei sobre FAT foi sua eficiência espaço. Não havia mesas de setores ou grupos que podem ser meio cheio, porque o arquivo não foi grande o suficiente para precisar delas. O tamanho do FAT foi criado pelo tamanho do disco.
Quando eu projetei DOS eu sabia que ajuste o número de cluster em um único byte, limitando o número de clusters a 256, não iria fazer o trabalho como discos ficou maior. Eu aumentei a entrada de FAT para 12 bits, permitindo que mais de 4000 clusters. Com um tamanho de cluster de até 16K bytes, isso permitiria que para discos tão grande quanto 64 MB. Você poderia até mesmo empurrá-lo para um cluster de 32K e tamanho do disco de 128 MB, apesar de que grande cluster poderia desperdiçar um espaço muito. Estes tamanhos de disco parecia enorme para mim em 1980. Só recentemente se tivéssemos visto os discos de 10MB primeiro disco saiu para microcomputadores, e que o tamanho parecia absurdamente luxuoso (e caro).
Obviamente, eu não sou visionário. Tamanho do disco tem crescido mais rapidamente do que qualquer atributo de computador, até por um fator de 100.000. (Tamanho da memória típica é até por um fator de 30.000, enquanto a velocidade do clock é apenas até 1000x.) Microsoft estendeu a entrada do FAT para 16 bits, em seguida, para 32 bits para acompanhar. Mas aí o FAT tão grande que já não era mantido inteiramente na memória, tirando a vantagem de desempenho.
Também tiraremos, em breve, informações do site de Tim Paterson.
Pesquisado por André Luiz Cardoso.
Fonte: http://dosmandrivel.blogspot.com/ ( Blog Tim Paterson)
Nenhum comentário:
Postar um comentário