Trabalhando em arquivos grandes através de uma LAN [closed]

1

Eu trabalho em uma pequena loja de design / web (6 funcionários). Temos um servidor de arquivos que usamos para armazenar documentos de design grandes (arquivos do photoshop, arquivos de origem do flash, indesign etc) e outros trabalhos em andamento. O servidor é apenas uma máquina básica do Windows com alguns discos rígidos e compartilhamento de arquivos habilitado. (Estamos no processo de mudar para uma solução usando o FreeNAS).

O designer proprietário / líder da empresa adora trabalhar diretamente nos arquivos do servidor (em vez de fazer uma cópia local e trabalhar nisso). Isso, claro, leva a todos os tipos de corrupção de arquivos e problemas de acesso a arquivos. Mostrei a ele os artigos de suporte no site da Adobe, explicando que seu fluxo de trabalho é uma péssima ideia. Ele continua convencido de que o problema é, na verdade, apenas um 'problema de permissões' e, se apenas mudarmos para usar o NFS em vez de compartilhamentos do Windows / Samba, tudo ficará bem.

Minha pergunta é: Você pode recomendar algum outro recurso que possa me ajudar a mudar de ideia? Alternativamente, você pode recomendar algum recurso que possa ajudar a mudar a mente do meu ? Ele usa um Mac, portanto, se houver algo específico para esse sistema operacional, ele pode ter mais peso do que informações gerais.

Atualmente, eu sei sobre:

por Johrn 30.07.2010 / 18:48

5 respostas

4

A corrupção de arquivos não pode ser causada por problemas de permissão. Assim que você tiver mais de um usuário trabalhando no mesmo arquivo ao mesmo tempo, a corrupção ocorrerá a menos que o aplicativo bloqueie o arquivo enquanto ele estiver aberto (para que apenas um usuário por vez possa abrir o arquivo) e o bloqueio funciona no seu sistema de compartilhamento de arquivos (NFS / samba /…). Usar o NFS em vez do samba pode ajudar com o último, mas isso é irrelevante, pois, de acordo com as referências citadas, os aplicativos com os quais seu grupo trabalha não recebem bloqueios.

Alguns lugares tentam disciplina, em que todos precisam pedir permissão antes de trabalhar em um arquivo e se reportam ao gerente de permissão quando terminam o trabalho. A lei de Murphy garante que ela falhe (especialmente no dia antes do prazo, quando todos estão em um frenesi).

Um sistema de controle de versão é a solução certa: checkout, work, commit; se duas pessoas trabalharem no arquivo ao mesmo tempo, a operação de confirmação falhará e o segundo committer será informado de que ele deve mesclar seu trabalho com o primeiro committer. Os sistemas de controle de versão têm o benefício adicional de manter um histórico de alterações.

Infelizmente, você está enfrentando um problema social, e não um problema técnico. Você pode tentar mostrar os artigos do seu chefe exaltando as virtudes do controle de versão (google algo como “por que controle de versão” e filtrar qualquer coisa que se concentre em desenvolvedores), mas as chances são de que ele simplesmente os dispensará. Pode ser que o melhor que você possa fazer é ter certeza de que, quando as besteiras acontecem, elas o envolvem, e ele sabe por que elas acontecem. Boa sorte.

    
por 30.07.2010 / 21:32
1

Eu li o artigo do flash 2009 e concordo que isso é ridículo. Um único usuário acessando um arquivo pela rede deve funcionar de maneira semelhante ao armazenamento local.

O NFS não é uma resposta para o problema e nem o iSCSI. O iSCSI apresentará um drive para um sistema, mas uma vez que o drive esteja montado, você precisaria "compartilhá-lo" e, assim, estaria na mesma situação em que estava antes.

Se o objetivo é ter um repositório central e você respeitar a restrição ridícula da adobe de que " Uso de arquivos Flash em redes locais não é suportado em nenhum contexto ", você precisará usar algum tipo de sistema que verifica arquivos para você. Não tenho certeza dos detalhes, mas o subversion ou outro sistema cvs poderia se encaixar.

    
por 30.07.2010 / 19:28
0

Acho que trabalhar em um arquivo grande no servidor é perfeitamente aceitável e uso isso sem problemas. São arquivos de tipos diferentes, do photoshop às pastas pessoais do outlook que chegam perto de 2GB cada e nunca têm problemas de corrupção se a rede (ou o disco do servidor, é claro) não falhar. Você deve garantir que o bloqueio de arquivos funcione e sua rede precisa ser confiável. Eu uso o NFSv4 para os desktops linux e o Samba para os desktops windows (nos mesmos arquivos). Antes eu estava usando tudo via samba mas como estou movendo todas as janelas para o linux eu instalei o nfs4 também e tudo está funcionando bem.

De qualquer forma, copiar o arquivo para local durante a edição não é absolutamente uma solução! O que você fará com duas cópias modificadas de forma silmutânea? Para fazer isso, você não precisa de um servidor de arquivos ... Você ficaria mais seguro com cada arquivo em um computador definido e teria que sentar nele para editar o arquivo como nos tempos anteriores à rede. O dono da sua loja está perfeitamente certo nisso.

    
por 31.07.2010 / 17:09
-1

O problema continuará e piorará e não será resolvido até que você mude a maneira como trabalha (a engenharia social mencionada acima) passando para um regime brutal de check-in / check-out ou mudando para uma solução isso é mais indulgente quanto ao modo como o designer líder quer trabalhar e -guess what? - isso significa encontrar uma implementação AFP moderna para seus compartilhamentos de arquivos. [Estamos mudando de compartilhamentos do Windows 'vanilla' (SMB, conectados via ADmitMac) para compartilhamentos do Windows apresentados pelo ExtremeZ-IP. Nossos testes mostram que o InDesign se comporta com um pouco mais de graça quando aberto na rede (você não pode, por exemplo, abrir e EDITAR o mesmo documento em dois Macs simultaneamente com o AFP!)]. No entanto, você ainda terá o problema de estar trabalhando além dos parâmetros de design da Adobe para o aplicativo InDesign, que inclui (estou parafraseando aqui) "acesso aleatório imediato e frequente a um rápido armazenamento LOCAL".

Boa sorte!

    
por 13.09.2011 / 11:25
-2

O iSCSI parece uma solução.

    
por 30.07.2010 / 18:52