BR112012004232B1 - método para operar computador, meio legível por computador e dispositivo eletrônico - Google Patents

Abstract

MÉTODO PARA OPERAR COMPUTADOR, PRODUTO DE PROGRAMA DE COMPUTADOR E DISPOSITIVO ELETRÔNICO A presente invenção provê métodos, sistemas, aparelhos, e produtos de programa que são descritos para gerenciar, ativar, e controlar sistemas de arquivo que compartilham dois ou mais O/SS (Sistemas Operacionais) e similares, em um computador ou qualquer aparelho de computação, em uma única sessão, no contexto operacional do computador. A provisão é feita para registrar ("journalizing") e resincronizar os sistemas de arquivo, mesmo onde pelo menos um O/S não tem componentes para torriar reconhecer a presença de outro O/S.

Description

Campo da Invenção

A presente invenção se relaciona geralmente a computadores e dispositivos pessoais, que compartilham arquiteturas similares, e, mais particularmente, a um sistema e método correspondente para gerenciar, ativar, e controlar sistemas de arquivo, compartilhando dois ou mais sistemas operacionais e similares em um aparelho de computação, em uma única sessão ou contexto operacional.

Histórico da Invenção

Modernamente, o uso de computadores, incluindo laptops e notebooks, vem se tornando cada vez mais comum, e, ademais, os computadores vêm aumentando de potência e complexidade, e consumindo cada vez menos energia.

Computadores mais antigos tem um único software operacional, em geral, Windows, por exemplo, Microsoft® Vista®, ou Linux® com GNOME (programa de fonte aberta).

Produtos Windows® e O/Ss de fonte aberta oferecem vantagens exclusivas, que induzem crescentemente os usuários de computadores a desejar dispor e usar ambos. A provisão simultânea de múltiplos produtos de programa para múltiplos O/Ss, no entanto, levanta um número de dificuldades, incluindo multiboost, carregamento ACPI, programa de virtualização hipervisor com suporte de hardware.

Outra questão que surge diz respeito ao compartilhando de dados e, por conseguinte, ao compartilhamento de sistemas de arquivo, através das O/Ss. Isto é particularmente um problema, onde múltiplos O/Ss operam quer simultaneamente ou continuamente e alternadamente em uma única sessão. Tipicamente, para um computador PC, uma sessão de operação é a partir de POST (Power-On Self Test (Teste de Auto-Ligação)) a fechamentos ordenados de O/S, e usualmente seqüência de desligamento. Mutexes, bloqueamento de recursos, e técnicas similares são bem conhecidas na computação, onde múltiplas entidades (threads de execução, núcleos de processador, processadores distribuídos, etc.) precisam compartilhar recursos de arquivo de dados. Tais situações vêm sendo comumente resolvidas por procedimentos de software cooperativos, e garantias de compartilhamento ordenado de recursos, ou pelo menos alocação de recursos ordenado. No entanto, não se espera que um O/S de fonte fechada facilite o compartilhamento de recursos com outros O/Ss, quando o O/S de projeto não reconhece outros O/S.

Uma solução menos geral é requerida, onde arquivos devem ser concorrentemente e alternadamente disponíveis entre dois ou mais O/Ss, e a presente invenção atende pelo menos uma destas situações. Em particular, onde um O/S de fonte fechada implementa componentes sofisticados ou avançados para manuseio de dados, pode parecer que não se comporta bem (ou pelo menos não da maneira conhecida) a outro O/S. A presente invenção atende uma situação particularmente comum.

Soluções anteriores incluíam fazer as O/Ss assumir um controle completo de seu próprio sistema de arquivo que então é visto como somente de leitura a partir de outro O/S. Não apenas indevidamente restritivo na capacidade, mas nem mesmo produz resultados consistentes, quando um FS resulta desemparelhado ou em um estado não-documentado por um O/S, que o FS abriu para escrita-leitura. Nestes casos, tal FS pode ser documentado como não-montável (ou corrompido), mesmo para modo escrita-leitura fora do contexto do O/S, com acesso de leitura-escrita para isto.

Uma vantagem significativa das configurações da presente invenção em relação às soluções anteriores reside no fato de permitir troca de execução entre mais sistemas operacionais, sem precisar fechar ou reiniciar sistemas de arquivo (por conseguinte, ter que reiniciar o sistema operacional) nas trocas de contexto de O/S em uma sessão de operação.

Sumário da Invenção

A presente invenção provê um método para operar um computador, e também a um aparelho incorporando o mesmo. Em adição, pacotes de programa e outros meios de explorar a presente invenção também são apresentados.

De acordo com um aspecto da presente invenção, uma configuração da presente invenção pode prover carregar dois sistemas operacionais, montar um primeiro sistema de arquivo controlado por um segundo sistema operacional para acesso de apenas de leitura pelo primeiro sistema operacional, montar um journal controlado pelo primeiro sistema operacional. Ademais, redirecionar para o journal, dados escritos a partir de um programa aplicativo no primeiro sistema operacional, e, então, retomar a execução do segundo sistema operacional, e aplicar o journal ao primeiro sistema de arquivo no contexto do sistema operacional.

Uma vantagem e/ou aspecto provido ou resultando da implementação da presente invenção, reside no fato de arquivos poderem ser usados em um sistema de arquivo por dois O/Ss alternadamente suspendendo um e outro. Descrição Resumida dos Desenhos

As vantagens e aspectos da presente invenção serão mais bem entendidos e apreciados através de uma leitura mais atenta da descrição detalhada da presente invenção, que se segue, em conexão com os desenhos anexos, que são incorporados como parte da especificação, ilustram uma configuração da presente invenção, e nos quais os mesmos números de referência representam elementos similares.

A figura 1 mostram um diagrama de blocos esquemático de um dispositivo eletrônico configurado para implementar a funcionalidade de segurança de acordo com a presente invenção;

As figuras 2 e 3, em conjunto, representam um fluxograma ilustrando a visão global das etapas realizadas na implementação da configuração da presente invenção;

A figura 4 traz um diagrama que mostra a relação entre componentes de software de uma configuração da invenção;

A figura 5 mostra como uma configuração exemplar da invenção pode ser codificada em computador; e

A figura 6 mostra como uma configuração exemplar da presente invenção pode ser codificada, transmitida, recebida, e decodificada usando ondas eletromagnéticas.

Descrição Detalhada das Configurações

Os numerosos componentes nos desenhos serão apresentados àqueles habilitados na técnica para prover uma descrição da presente invenção. A descrição de componentes bem conhecidos não sendo incluída na descrição, de modo a não estendê-la desnecessariamente, ou reduzir o aspecto de novidade, e seus principais benefícios.

Uma configuração exemplar da presente invenção será agora descrita com referência às figuras. A figura 1 traz um diagrama de blocos esquemático de um dispositivo eletrônico, configurado para implementar a funcionalidade de segurança, de acordo com a presente invenção.

Em uma configuração exemplar, o dispositivo eletrônico 10 pode ser implementado como microcomputador PC, por exemplo, computadores laptops, computadores notebooks, tabletes, ou outros dispositivos de computação adequados. Embora a descrição se relacione à operação de um microcomputador PC, deve ser apreciado, por aqueles habilitados na técnica, que o dispositivo eletrônico 10 também pode ser implementado como assistente digital pessoal PDA, dispositivos de comunicação sem-fio, por exemplo, caixa conversora, celular, controladores ou dispositivos incorporados, tal como caixa conversora (setup box), dispositivos de impressão, e outros dispositivos adequados, ou combinações destes, para operar ou interoperar com a presente invenção.

O dispositivo eletrônico 10 pode incluir pelo menos um processador ou CPU 12, configurado para controlar a operação global do dispositivo eletrônico 10. Controladores similares (ou MPUs) são comuns. O processador 12 tipicamente pode ser acoplado a um controlador de barramento 14, tal como chip Northbridge, através do barramento 13, tal como FSB (Front Side Bus (Barramento Frontal)). O controlador de barramento 14, tipicamente, pode prover uma interface para memória de sistema de escrita-leitura 16, tal como RAM (memória de acesso randômico).

Em uma operação comum, a CPU 12 pode buscar instruções de computador (ou códigos de instruções de computador (não mostrados na figura 1)) da memória de sistema 16. A CPU, então, pode interpretar as instruções de computador buscadas, interpretá-las, e controlar a operação do dispositivo eletrônico 10. Este uso de CPU, memória de sistema, e instruções de computador, tipicamente compreendendo códigos O/S e software, é bem conhecido na técnica.

O controlador de barramento 14 também pode ser acoplado a um barramento de sistema 18 por exemplo DMI (de Direct Mídia Interface (Interface Direta de Mídia)) em configurações tipo Intel® acoplado a DMI 18 pode ser chip chamado Southbridge, tal como chip 24 ICH8 (de Input/ Output Controller Hub type 8 (nó controlador de entrada/ saída type 8)).

Em uma configuração típica, o chip Southbridge 24 pode ser conectado a um barramento PCI 22 (de Peripherical Component Interconnect (Interconexão de Componente de Barramento)) que, por sua vez, pode ser conectado a um subsistema de armazenamento em disco 66, que pode atender vários FS (sistemas de arquivo) nas configurações da presente invenção.

A família HyperspaceTM de produtos da Phoenix Technologies® permite a provisão de vários produtos de programa O/S em um único computador de vários modos. O produto HyperspaceTMdispõe de diversas variantes, notavelmente usando técnicas de Boot Duplo (Dual Boot), Dupla Reinicialização (Dual Resume), ou Máquinas Virtuais, sendo que neste último caso é requerido um suporte de hardware muito distante da configuração universal encontrada nos produtos de computador disponíveis no mercado. A versão de Duplo Boot de produto HyperspaceTMnão provê carregamento simultâneo, mas, ao invés, requer o fechamento do primeiro O/S antes de o segundo O/S carregar e assumir o controle do PC.

A Dupla Reinicialização (Dual Resume) do produto HyperspaceTM facilita carregamento concorrente, como dirigido pelo produto HyperspaceTM dos primeiro e segundo O/Ss, por exemplo, O/S Linux e O/S de fonte fechada, tal como da Microsoft®. Basicamente, na dupla reinicialização do produto HyperspaceTM, dois O/Ss são concorrentemente carregados, mas apenas um deles sendo selecionado para ser ativo a nível de usuário, a partir de um estado quiescente, e reiniciando o outro O/S do estado quiescente para um estado mais ativo. Assim, na configuração descrita da presente invenção, apenas um O/S está ativo, ao nível de aplicativo, a qualquer instante.

A versão de dupla reinicialização do produto HyperspaceTMprovê um compartilhamento limitado de arquivo dos O/Ss. O lado Linux do produto é comumente chamado apenas HS (abreviatura de HyperspaceTM), enquanto o outro lado se refere a um produto O/S da Microsoft®, comumente chamado “Windows”, como normalmente conhecido na técnica. Isto não dá ao Windows®, marca registrada da Microsoft® e X-Windows a partir do MIT (Massachusetts Institute of Technology), a condição de programa de fonte aberta.

Um aspecto chave de vários produtos firmware/ software HyperspaceTM, com certeza, reside no fato de permitir que FSs e, portanto arquivos, sejam compartilhados entre contextos Windows® e HS concorrentes (O/Ss HyperspaceTM ou Linux). Na descrição que se segue de configurações particulares, sistemas de arquivo especificados que, foram implementados tal como NTFS FAT32 WindowLs PSA ext3 (e assim por adiante, todas bem conhecidas na técnica) devem ser vistas como provendo uma descrição de FSs exemplares. A presente invenção não se limita geralmente aos O/Ss descritos, que são meramente paradigmas.

Implementações rudimentares e precariamente aceitáveis (emprestadas de distribuições comuns Linux®) exploram driver NTFS-3g não-modificado (NTFS de New Techonology File System (Sistema de Arquivo de Nova Tecnologia)) para montar e acessar volumes de armazenamento, designados como C, D, etc. no contexto HyperspaceTM. Usando técnica “Duplo Boot”, uma implementação deste tipo, que permite acesso somente de leitura seguro (de O/S tipo Linux) de FSs criados e mantidos por Windows, é precariamente aceitável. Em um produto de dupla reinicialização, esta restrição, muito provavelmente, deve ser totalmente inaceitável à maior parte dos usuários.

Em geral, a escrita de FS é suportada por driver NTFS- 3g mas, sem medidas adicionais preventivas e remediais, o uso deste componente pode causar (e muito provavelmente causa) problemas, que surgem da implementação incompleta pelo NTFS-3g de componentes avançados, tal como MS NTFS VSS (Microsoft® Inc Volume Snap Shot Service de NTFS) e componentes de registro (journalizing) de dados. O MS NTFS VSS é bem conhecido na técnica.

Parte do aproveitamento da oportunidade de resolver as dificuldades acima compreende restringir o acesso de leitura-escrita no NTFS-3g, para prover um completo acesso de leitura-escrita a apenas um subset (subconjunto) limitado de volume em questão. Com isto, o escopo é limitado com respeito a complicações, enquanto provê total acesso NTFS-3g aos arquivos mais prováveis de serem os arquivos para os quais o acesso de leitura-escrita é valioso ao usuário. Limitar o escopo, assim, permite manter o software em um mínimo, evitando o risco de usar uma quantidade excessiva de recursos.

Em uma configuração da presente invenção, o acesso leitura-escrita de arquivos Windows (lado HS) (reinicialização da variante Linux®) é limitado a uma parte pequena controlada do FS. Em uma configuração particular, o acesso de leitura-escrita ao “My Documents” é habilitado. “My Documents” é um componente comum e bem conhecido dos produtos Microsoft®.

O acesso somente de leitura geralmente pode ser provido a todos arquivos sem causar problemas, no entanto, pode ser necessário um número de etapas para garantir que o FS (de File System (Sistema de Arquivo)) do primeiro O/S seja trazido para uma condição ordenada, ao transferir o controle para o segundo O/S. As implementações descritas mitigam os problemas associados ao acesso de FS (especialmente NTFS) do O/S, enquanto outro O/S está suspenso, mas, não obstante, pode exercer uma ação pendente no nível de aplicativo. Estes efeitos serão aparentes àqueles habilitados na técnica.

Assim, no produto de programa Hyperspace TM de dupla reinicialização, os problemas de compartilhar arquivo são desafiadores. Situações surgem nas quais Windows e HS são ambos ativados, mesmo embora não executando programas no nível de aplicativo alternadamente em vez de concorrentemente. Por exemplo, isto pode ocorrer quando um O/S vê Estado O/S de ACPI (de Advanced Configuration and Power Interface (Interface Avançada de Configuração e Energia)) e o outro O/S se considera suspenso em S3. Neste caso, ambos podem ter um sistema de arquivo NTFS do Windows concorrentemente montado, mesmo com um deles suspenso. Sem medidas específicas tomadas para garantir consistência, surge o risco de dados velhos serem lidos e/ou sistemas de arquivo Windows corrompidos, por exemplo, quando houver escritas para NTFS de HS nos períodos em que windows® estiver suspenso.

Especificamente, as seguintes questões serão aparentes e resolvidas na totalidade ou em fração substancial, nas configurações da presente invenção. (A) uma versão em disco de um arquivo em um sistema ou volume de arquivo pode diferir de um arquivo “ainda não salvo" ou “em cachê” na versão de memória deste arquivo. Este é um item bifurcado, no qual ambos ou qualquer O/S pode possuir e controlar o arquivo ou volume FS, e criar um item para o outro O/S resolver. (B) um driver NTFS-3g pode recusar montar volume NTFS que foi desmontado. (C) com um produto HS tipo “dupla reinicialização”, arquivos Windows podem permanecer abertos para editar no instante de troca para HS. (D) implementações NTFS Windows podem incluir funcionalidade aumentada sem NTFS-3g, notavelmente incluindo: (i) pontos de restauro e VSS; (ii) Indexação de arquivo; (iii) uso de drivers filtro por pacotes AV (AudioVisual); e (iv) backup com facilidades de restauro.

Referindo-se à figura 2, em uma configuração da presente invenção que representa iniciando, em 200, em um contexto de um O/S, por exemplo Linux HS, um número de ações sendo tomado. Em 210, HS monta FS, usando NTFS-3g no modo de leitura-escrita. Isto provê o acesso de HS a um ou mais (senão todos) FS Windows no volume selecionado a ser montado no subsistema de software NTFS-3g. Ademais, um O/S Windows pode escrever em vários FSs à maneira tradicional, sem ser afetada pela presença (na verdade sem sequer tomar sua ciência) do contexto ativo no sistema de computador - HyperspaceTM e O/S.

Em 230, quaisquer e todos dados escritos de aplicativos HS para arquivos em qualquer NTFS pertencente a Windows® são escritos para Sombra Virtual (Shadow Virtual) FS controlado e pertencente ao HS. Alocação de volume (disco) de espaço em Sombra Virtual HS pode ser provida a partir de um FS nativo no HS.

Em 240, escritas de HS para Sombra Virtual FS também podem ser logadas em um arquivo journal. O journal pode ser sincronizado ao disco cachê para IDE (de Integrated Drive Eletronics (Componentes Eletrônicos de Drive Integrado)), tal como a cada escrita ou periodicamente a cada poucos segundos, ou segundo um outro critério qualquer. O arquivo journal pode ser implementado em uma área de dados dedicada em um volume, e o arquivo journal também acessado por programas de sistemas operando em contexto Windows®. Por exemplo, o FAT32 (de Filei Allocation Table de 32 bits (Tabela de Alocação de Arquivo de 32 bits)) FS em uma partição de disco estendida dedicada pode ser usado, ou uma área de journal formatado proprietário pode ser implementada no topo de um arquivo rascunho Windows® contíguo não-removível oculto.

Em 250, um, pedido de leitura é feito para ser atendido em um contexto HS, que provoca uma verificação a ser realizada no Sombra Virtual FS, para determinar se os dados pedidos já estão localizados ali. Se não, então o pedido de leitura de dados segue para o arquivo solicitado fora da Sombra Virtual FS, ou o arquivo pedido é encontrado, mas o journal não. Em 260, se o pedido pode ser atendido pela leitura da Sombra FS, então a leitura será feita. Caso contrário, em 270, será lido o NTFS somente de leitura, e arquivo e dados localizados.

Em 280, deve haver uma mudança do contexto HS, em 290, a execução continua em um contexto Windows na figura 3.

Referindo-se agora à figura 3, 300 é o começo da inicialização para execução em um contexto Windows (ou no reboot de partição de recurso Microsoft® Windows®).

Em 310, um serviço Windows, tipicamente como daemon de aplicativo, pode consistentemente verificar (validar) o arquivo journal criado em HS, como descrito acima.

Em 320, um programa filtro plug in instalado em um aplicativo Windows, tal como Explorer, e/ou um driver de filtro FS previamente instalado, pode adiar ou postecipar acessos requeridos de processos Windows a certos arquivos. Arquivos afetados serão aqueles arquivos presentemente sujeitos a modificação, com arquivo journal. O acesso é adiado até depois que o journal de escrita HS tenha sido mesclado (merged) e totalmente aplicado (como descrito acima).

Em 325, o serviço, então, pode aplicar journal aos arquivos NTFS, e, então, em 330, apagar os contextos de journal (tal como, escrevendo dados de todos zeros) e, em 340, marcar Sombra Virtual FS como vazio (ou de alguma forma não-aplicável, porque não contém mais o arquivo journal aplicável). Esta aplicação de arquivo journal, essencialmente, contribui para alcançar a cópia sombra, e garante que os últimos acessos (como em Windows e sem conhecimento da aplicação de Sombra) receberão apenas dados válidos e recentes (i.e. de não-estado).

Em 350, o adiamento dos acessos, imposto em 320, é liberado. Isto permite transferir pendências no contexto de O/S reiniciado para avançar, e qualquer pendência que poderia haver é desembaraçada. Em 390, a seqüência de ações é completada.

A figura 4 é um diagrama que mostra a relação entre componentes de software de uma configuração da presente invenção. Em um nível baixo e usando assistência BIOS, provê-se um suporte de dupla reinicialização HyperspaceTM através de ACPI 490. Acima e além disso tem dois contextos de O/S, contexto de O/S Windows® 400, e contexto de O/S HyperspaceTM 450.

O contexto de O/S Windows® é dividido entre componentes executados em GUI (Graphical User Interface (Interface Gráfica de Usuário)) ou aplicativos daemon 410, e, alternativamente, programas que funcionam como plug in, notavelmente, filtros de arquivo de sistema de arquivo.

O contexto de O/S HyperspaceTM 450 é dividido em espaço de Usuário 455 e espaço Kernel 470.

Os vários componentes de software, que formam uma configuração da presente invenção, serão agora descritos com referência à figura 4. O projeto no lado Windows 400 consiste de diversos componentes: (A) Filtro de Arquivo NTFS 440; (B) Gerenciador de Transição FS 420; e (C) Filtro de Arquivo FAT 450.

O filtro de arquivo NTFS 440 consiste de um driver de sistema de arquivo, ligado uma pilha de sistema de arquivo Windows durante boot, que monitora todos pedidos no driver FS do O/S Windows, e desempenha um importante papel em ajudar o Gerenciador de Transição FS no compartilhamento de arquivos.

Na troca de Windows para HS, o Filtro de Arquivo NTFS 440 descarrega o cachê de disco, quando da notificação do Gerenciador de Transição FS 420. Então, o Filtro de Arquivo NTFS impede que todos FS I/Os (operações de Entrada/Saída (Input e Output)) alcancem FS, enfileirando os IRPs (pacotes de pedido I/O), com base nos manipuladores de arquivo. O bloqueio é iniciado e interrompido em resposta da notificação de Gerenciador de Transição FS 420. O filtro de arquivo bloqueia apenas leitura e escrita, mas permite outros IRPs, tal como PNP IRP (IRP plug in), Energia IRP, WMI IRP (Instrumentação de gerenciamento Windows IRP).

O filtro de arquivo NTFS 440 desempenha um papel vital na implementação de componente OpLock aplicado a arquivos compartilhados por dois O/Ss. OpLock implementa múltiplos leitores e mecanismo de escrita. OpLock garante a integridade dos dados, quando um arquivo, sendo aberto em um O/S, é aberto para edição em um segundo O/S. Quando um aplicativo pede para abrir um arquivo na partição compartilhada, o Filtro de Arquivo NTFS 440 prende IRPS e tenta buscar arquivo em um arquivo log. Se não houver nenhuma entrada para o arquivo solicitado, então, o pedido é permitido. Mas, havendo uma entrada, então o respectivo pedido de aplicativo para abrir o arquivo é negado. Esta técnica provê que os FSs sejam compartilhados nos O/Ss de maneira ordenada, mantendo a condição de travar o arquivo, quando dois aplicativos tentam atualizar um arquivo (não meramente o mesmo FS) de modo concorrente.

Em uma configuração, o arquivo log é implementado usando um driver filtro UnionFS (em HS) que escreve (ou atualiza) uma entrada no arquivo log, sempre que um aplicativo no HS (i.e. em Dom0) abre um manipulador de arquivo. UnionFS é um componente comum no Linux® e bem conhecido na técnica. A entrada log relevante será deletada do arquivo log, quando todas referências ao manipulador de arquivo estiverem fechadas. Apenas o driver UnionFS (lado HS) atualiza o log e o outro domínio (tipicamente em Windows), o respectivo Filtro de Arquivo NTFS meramente lê (i.e. acesso somente escrita).

Similarmente, como corolário, o Filtro de Arquivo NTFS 440 também registra todas entradas de arquivo abertas em um segundo arquivo de logaritmo. Este arquivo log é usado pelo Filtro UnionFS 482 para busca, que permite que o aplicativo (em HS) abra o arquivo para edição. Assim, em uma configuração, a presença da respectiva entrada no segundo log impede que o arquivo seja aberto em HS.

Uma vez que um logger seja usado para implementar OpLock (sendo permitido muitos leitores e um escritor), então os respectivos loggers nos dois O/Ss nem bloqueiam nem registram os detalhes de arquivo em situações nas quais um aplicativo abre um arquivo para acesso somente de leitura. Ademais, uma conseqüência desejável de dois loggers separados é impedir que ambos O/Ss montem a mesma partição (onde está log) no modo leitura-escrita. Assim, o arquivo log Windows pode estar presente em um Volume compartilhado, que um driver filtro Windows pode ler ou escrever, mas lido apenas a partir do HS. Ao contrário, o log HS está presente no Volume Sombra que HS pode atualizar ou editar, mas visto como volume de leitura-escrita ou FS ao outro domínio (em geral o lado Windows).

O Gerenciador de Transição FS é um aplicativo Windows, um serviço executado segundo plano (background). O aplicativo de serviço abre um aplicativo em Windows que abre mensagem pop up. Os aplicativos de serviço tipicamente não acessam função GDI (de Graphical Display Interface (Interface de Representação Gráfica)) e qualquer tentativa de fazer isto diretamente provavelmente produz uma falha na execução. Aplicativos de serviço percebem modificações de SCM (de Service Control Manager (Gerenciador de Controle de Serviço), um componente Windows bem conhecido) e, também, suspendem em Stand by e reiniciam eventos de correção.

O Gerenciador de Transição FS 420 é um componente chave que executa um número de funções: (A) se lança durante fase de logon. Ele monta partição PSA Windows (área de sistema de pacote) e a oculta do nível de usuário; (B) sempre que o Windows estiver ativo, o Gerenciador de Transição FS 420 percebe o disparo para troca de estado de sistema ACPI, e, na recepção, notifica o Filtro de Arquivo NTFS 440 a descarregar cachê de disco e temporariamente bloquear I/Os; (C) sempre que Windows reinicia de um estado Stand by, o aplicativo percebe notificação de “acordar” (wake up) e, na recepção, realiza cópia do Volume Sombra para partição de volume compartilhado. Uma vez a cópia completa, notifica o driver de filtro a desbloquear IRPs pendentes; (D) Gerenciador de Transição 420 também monta volume PSA Windows na reinicialização de Stand by. Em uma configuração da presente invenção, o Volume Sombra se encontra em Windows PSA.

O Filtro de Arquivo FAT 32 450 é um driver de filtro assentado na pilha de sistema de arquivo FAT32. O FAT32 é bem conhecido na técnica. Neste projeto, o Windows PSA é usado como partição Sombra, sendo uma partição FAT32. O Gerenciador de Transição FS 420 monta a partição e realiza a requerida operação de cópia. Uma vez montado, Windows disponibiliza a partição ao usuário que ele pode explorar como necessário. Para evitar qualquer destas operações (potencialmente problemáticas) do Windows PSA, o Filtro de Arquivo FAT32 450 de projeto bloqueia I/O detectada para Windows PSA.

Voltando agora ao projeto do lado HyperspaceTM 450, no espaço Usuário 455 se encontram diversos componentes (D) Gerenciador de Transição HS 460; (E) Gerenciador de Transição UI (interface de usuário) 465; e (F) suporte de Escrita 470. No espaço Kernel 470 ficam filtros de arquivo, VFS 480 (sistema de arquivo Virtual) e UnionFS 482, que operam com FS de vários tipos, “ext3” 484 (FS Linux® DEFAULT), NTFS 486, e FAT32 488.

O Gerenciador de Transição HS gerencia I/O controlada para partições NTFS RO (somente de leitura). Sempre que houver uma transição que não requeira atualização do disco, i.e. qualquer seqüência RO, o Gerenciador de Transição HS 460 lê o arquivo da partição NTFS apropriada e abre no modo RO. Quando qualquer transição requer atualização do disco, então o Gerenciador de Transição HS 460 abre o arquivo a partir da partição NTFS no modo RO, mas, neste caso, a transferência I/O (escrita-reescrita) é direcionada para o Volume Sombra (Shadow Volume), no modo leitura-escrita, ao invés de a transferência I/O ser direcionada para própria partição NTFS.

Em uma configuração da presente invenção, o módulo de Filtro de Arquivo HS é parte do filtro de arquivo para VFS 480 em associação com UnionFS 482. O UnionFS 482 é um tipo de sistema de arquivo que mescla dois pontos de montagem e executa escrita I/O para o Volume Sombra 488, ainda que o aplicativo no espaço usuário é apresentado como vista de escrita I/O que ocorreu diretamente para uma partição NTFS. O uso de UnionFS provê que uma operação de leitura busca os dados apropriadamente, especialmente a partir dos dados editados no Volume Sombra (em vez de dados originais e/ou inalterados), sempre que estes dados forem modificados por uma operação de escrita recente.

O Filtro de Arquivo 480 provê acesso de arquivo geral, tal como diretamente para ext3 484 e NTFS 486, em adição a prover capacidade de módulo de Filtro de Arquivo HS.

O Gerenciador de Transição HS 460 lê informações a respeito do arquivo sendo aberto para escrita I/O a partir dos metadados (não mostrados na figura 4). O arquivo de metadados pode ser implementado como o componente de arquivo log descrito acima, ou criado e mantido separado. O arquivo de metadados existe em uma partição NTFS montada no modo RO. O filtro de arquivo NTFS (em Windows) atualiza este arquivo de metadados com informações a respeito de qualquer arquivo pertinente (potencialmente compartilhável) que está sendo editado ou atualizado via Windows. Alguns arquivos, tal como arquivos de sistema Windows, podem ser excluídos intencionalmente e, assim, permanecerem desconhecidos para o lado aplicativo HS.

As informações contidas no arquivo de metadados incluem nome de arquivo, localização na partição NTFS, estado, número de referências de descritor de arquivo, etc.. Se um arquivo estiver sendo aberto em um modo que permita escrita em HS, e se Gerenciador de Transição HS 460 encontrar no arquivo de metadados que este arquivo se encontra no “Estado Aberto em Windows para Edição”, então o Gerenciador de Transição HS 460 sinaliza ao Gerenciador de Transição HS 465 para o Gerenciador de Transição HS 465 representar uma mensagem apropriada, e impedir abertura do arquivo.

Similarmente, o Gerenciador de Transição HS 460 mantém arquivo de metadados no Volume Sombra. Estrutura interna é similar ao arquivo de metadados na partição NTFS atualizada por Windows. O Gerenciador de Transição HS 460 atualiza o arquivo de metadados sempre que um pedido, a partir de qualquer aplicativo HS, chega, para abrir um arquivo de escrita pertencente à partição NTFS não editada em Windows. Se o arquivo que estiver sendo editado em HS for fechado antes de mudar para Windows, então a entrada deste arquivo será removida do arquivo de metadados. Assim, indicando para Windows que este arquivo pode ser aberto para edição. Junto com metadados, o próprio arquivo é armazenado no Volume Sombra. Sempre que o contexto muda para Windows, este arquivo é copiado pelo Windows em sua posição efetiva na partição NTFS. Esta situação pode particularmente ser aplicada quando um novo arquivo for criado no contexto HS e disposto no lado Windows. Isto também é equivalente a uma situação, na qual o journal é simplesmente todo o arquivo.

O filtro de arquivo HS é implementado por um driver UnionFS 482 Linux. O UnionFS é um tipo de sistema de arquivo disposto entre os drivers VFS e NTFS-3G.

UnionFS é bem conhecido na técnica. Funcionalmente, UnionFS 482 simultaneamente é disposto no topo de diversos sistemas de arquivo 484, 486, 488, ou, algumas vezes, em múltiplos diretórios, em um sistema de arquivo. O UnionFS 482 é sobreposto em diversos diretórios em um ponto de montagem. O UnionFS 482 primeiro tenta acessar o arquivo em uma ramificação de topo e se não for bem sucedido, segue para ramificações de nível inferior. Se o usuário tenta modificar um arquivo em uma ramificação de nível mais baixo que RO, então o arquivo é copiado em uma ramificação de leitura-escrita de nível mais alto. O UnionFS apresenta uma interface de sistema de arquivo a um kernel e, por sua vez, o UnionFS se apresenta como VFS do kernel a sistemas de arquivo, onde está empilhado. Em razão de o UnionFS apresentar uma vista de sistema de arquivo ao kernel, o UnionFS pode ser empregado por aplicativos a nível de usuário. O UnionFS intercepta operações limitadas a sistemas de arquivo de nível inferior, e por conseguinte, o UnionFS pode modificar operações para apresentar uma vista unificada.

Em configurações da presente invenção, os dois sistemas de arquivo podem ser NTFS (somente de leitura) e Volume Sombra FAT32 (leitura-escrita). Aos usuários (aplicativos para o modo usuário) não é permitido acessar Volume Sombra, mas excepcionalmente, sendo permitido ao Gerenciador de Transição HS 460. O Volume Sombra FAT32 488 ainda pode ser usado para manter o arquivo de metadados e novos arquivos buscados a serem criados na partição NTFS 486.

O Gerenciador de Transição HS 460 pode ser implementado (A) como drivers UnionFS FUSE (sistema de arquivo UnionFS no espaço de Usuário) ou, alternativamente, como driver de sistema de arquivo de espaço Kernel UnionFS. Driver UnionFS FUSE não está mostrado na figura 4, mas, no entanto, bem conhecido na técnica.

O suporte de Script 468 provê scripts de inicialização customizados para carregar um módulo kernel UnionFS. Se for usado UnionFS-FUSE, os scripts devem carregar um módulo Kernel FUSE, invocar UnionFS FUSE, e então (independente de se usado (ou não) UnionFS-FUSE) começar o daemon de Gerenciador de Transição HS 460 e Gerenciador de Transição UI 465.

Com respeito à figura 5, as instruções de computador a serem incorporadas em um dispositivo eletrônico 10 podem ser distribuídas como produto de computador de firmware e/ou software 510, usando uma variedade de mídias possíveis 530, com instruções gravadas, tal como usando gravador 520. Freqüentemente, em produtos tão complexos como aqueles que implementam a presente invenção, mais que uma mídia pode ser usada quer para produtos de distribuição e fabricação relevantes. Apenas uma mídia sendo mostrada na figura 5, por motivos de simplicidade, mas, no entanto, mais que uma mídia pode vir a ser usada, e um único produto de computador pode ser dividido em uma pluralidade de mídias.

A figura 6 mostra como uma configuração exemplar da presente invenção pode ser codificada, transmitida, recebida, e decodificada usando ondas eletromagnéticas.

Com respeito à figura 6, adicionalmente, e especialmente, a partir do crescimento no uso da Internet, produtos de computador 610 podem vir a ser distribuídos, codificando os mesmos em sinais modulados em ondas. As formas de onda resultantes, então, podem ser transmitidas por um transmissor 640, e propagadas como ondas portadoras eletromagnéticas moduladas, recebidas pelo receptor 660. Quando da recepção, as ondas portadoras podem ser demoduladas, e o sinal decodificado em uma versão ou cópia adicional do produto de computador 611 em uma memória ou em outro dispositivo de armazenamento, que faz parte de um segundo dispositivo eletrônico 11, e, tipicamente, similar ao dispositivo eletrônico 10.

Outras topologias e/ou dispositivos também podem ser usadas em configurações alternativas da presente invenção. As configurações descritas acima têm caráter meramente exemplar, de nenhum modo limitante, sendo que os limites da presente invenção serão determinados apenas pelas reivindicações. Embora as configurações preferidas desta tenham sido descritas em detalhes, deve ser entendido, por aqueles habilitados na técnica, que muitas variações e/ou modificações introduzidas aos conceitos inventivos básicos aqui ensinados estão englobadas no espírito e escopo da presente invenção, como definidos somente pelas reivindicações anexas.

Claims (17)

1. Método para operar um computador, caracterizado pelo fato de compreender: - carregar um primeiro O/S (sistema operacional) em uma memória; - carregar um segundo O/S (sistema operacional) na memória; - montar um primeiro FS (sistema de arquivo) controlado pelo segundo O/S; - montar o primeiro FS para acesso somente de leitura pelo primeiro O/S; - redirecionar uma pluralidade de dados escrita a partir de um programa aplicativo controlado pelo primeiro O/S para um journal controlado pelo primeiro O/S; - reiniciar a execução do segundo O/S; e - aplicar o journal ao primeiro FS em um contexto do segundo O/S; e - adiar uma transação para o primeiro FS no contexto do segundo O/S, tendo pendente a completação da aplicação do journal, para o primeiro FS, no contexto do segundo O/S.

2. Método, de acordo com a reivindicação 1, caracterizadopelo fato de: - o primeiro FS ser NTFS (Sistema de Arquivo de Nova Tecnologia).

3. Método, de acordo com a reivindicação 1, caracterizadopelo fato de: - a reinicialização ser feita de acordo com uma mudança de estado ACPI (Interface Avançada de Configuração e Energia).

4. Método, de acordo com a reivindicação 1, caracterizadopelo fato de: - o journal ser armazenado em um sistema de arquivo sombra virtual.

5. Método, de acordo com a reivindicação 1, caracterizadopelo fato de adicionalmente compreender: - redirecionar, a partir da união do journal e primeiro FS, uma pluralidade de dados lida no programa aplicativo, controlado pelo primeiro O/S.

6. Método, de acordo com a reivindicação 1, caracterizado pelo fato de a aplicação do journal ao primeiro FS adicionalmente compreender: - realizar verificações de consistência ou validade no journal no contexto do segundo O/S.

7. Método, de acordo com a reivindicação 1, caracterizado pelo fato de um contexto continuamente se alternar entre o primeiro e o segundo O/S de acordo com uma pluralidade de mudanças de estado ACPI.

8. Método, de acordo com a reivindicação 1, caracterizado pelo fato de: - o journal ser compreendido em um segundo FS.

9. Método, de acordo com a reivindicação 8, caracterizado pelo fato de - o primeiro FS ser do tipo NTFS, e o segundo FS tipo FAT32 (Tabela de Alocação de Arquivo).

10. Meio legível por computador não transitório tendo instruções codificadas no mesmo, caracterizado pelo fato de que, quando as instruções são executadas por pelo menos um processador, fazem o citado pelo menos um processador executar o método definido na reivindicação 1.

11. Meio legível por computador, de acordo com a reivindicação 10, caracterizado pelo fato de: - o primeiro FS ser NTFS.

12. Meio legível por computador, de acordo com a reivindicação 10, caracterizado pelo fato de: - o journal ser armazenado em um sistema de arquivo sombra virtual.

13. Meio legível por computador, de acordo com a reivindicação 10, caracterizado pelo fato de que retomar a execução do segundo O/S compreende retomar a execução do segundo O/S de um estado quiescente para um estado ativo.

14. Dispositivo eletrônico, caracterizado pelo fato de compreender: - um controlador; e - um meio legível por computador não transitório tendo instruções codificadas nele, que, as instruções quando executadas pelo citado controlador fazem o controlador: carregar um primeiro O/S (sistema operacional) em uma memória; carregar um segundo O/S (sistema operacional) em uma memória; montar um primeiro FS controlado pelo segundo O/S para acesso somente de leitura pelo primeiro O/S; redirecionar dados escritos a partir de um programa aplicativo controlado pelo primeiro O/S para um journal controlado pelo primeiro O/S; reiniciar a execução do segundo O/S e aplicar o journal ao primeiro FS no contexto do segundo O/S; e adiar uma transação para o primeiro FS no contexto do segundo O/S, tendo pendente a completação de aplicação o journal ao primeiro FS no contexto do segundo O/S.

15. Dispositivo, de acordo com a reivindicação 14, caracterizado pelo fato de: - o primeiro FS ser NTFS.

16. Dispositivo, de acordo com a reivindicação 14, caracterizado pelo fato de: - a reinicialização ser feita de acordo com mudança de Estado ACPI.

17. Dispositivo, de acordo com a reivindicação 14, caracterizado pelo fato de o journal ser armazenado em um sistema de arquivo sombra virtual.

Images