Guia Completo de Armazenamento

Entender onde e como armazenar seus dados no GridUnesp é crucial para o bom desempenho dos seus jobs e para a segurança dos seus dados.

Perigo

ATENÇÃO CRÍTICA:

• ❌ NÃO HÁ BACKUP de nenhum dado no GridUnesp

• ❌ NÃO HÁ QUOTAS de disco (use com responsabilidade)

• ⚠️ Você é 100% responsável pelos seus dados

• ⚠️ Falhas de hardware, erros humanos ou problemas técnicos podem causar perda permanente de dados

Se o dado é importante, faça backup em outro local!

Sistemas de Armazenamento

O GridUnesp possui três sistemas de armazenamento principais:

Comparação dos sistemas

Sistema	Capacidade	Velocidade	Persistência	Uso recomendado
/home/	120 TB	Média (NFS)	Permanente	Scripts, código, dados pequenos
/tmp/	~120 GB/nó	⚡⚡⚡ Muito rápida (local)	Temporária (apenas durante o job)	I/O intensivo, arquivos temporários
/store/	7 TB	⚡ Média (NFS)	Permanente	Arquivos grandes (>100 GB), dados compartilhados

/home/ - Diretório Pessoal

Seu diretório /home/seu-usuario é seu espaço pessoal permanente no cluster.

Características

• Acesso: Disponível em todos os nós (access, compute, GPU)

• Velocidade: Média (acesso via rede NFS)

• Backup: NÃO (dados NÃO são copiados)

• Quota: NÃO (use com responsabilidade)

• Persistência: Permanente (dados ficam até você deletar)

O que guardar no /home/

✅ Recomendado:

• Scripts de submissão (.sh)

• Código fonte

• Executáveis pequenos

• Arquivos de configuração

• Dados pequenos (<1 GB)

• Resultados finais importantes

❌ Não recomendado:

• Arquivos temporários de jobs

• Dados intermediários volumosos

• Arquivos muito grandes (>10 GB)

• Dados que serão processados intensivamente

Organização sugerida:

/home/seu-usuario/
├── projetos/
│   ├── projeto1/
│   │   ├── codigo/
│   │   ├── scripts/
│   │   └── resultados_finais/
│   └── projeto2/
├── software/
│   ├── programa1/
│   └── programa2/
└── bin/              # Executáveis pessoais

/tmp/ - Armazenamento Local Temporário

Cada nó de processamento tem seu próprio diretório /tmp/ local.

Características

• Acesso: Apenas no nó onde o job está executando

• Velocidade: ⚡⚡⚡ Muito rápida (disco local SSD/HD)

• Capacidade: Limitada (~120 GB por nó)

• Persistência: TEMPORÁRIA - arquivos são removidos ao final do job

• Compartilhamento: Não compartilhado entre nós

Aviso

IMPORTANTE SOBRE /tmp/:

• Arquivos em /tmp/ podem ser deletados sem aviso

• Ao terminar o job, dados em /tmp/ são perdidos

• NUNCA use /tmp/ para dados únicos ou importantes

• SEMPRE copie resultados importantes de /tmp/ para /home/ ou /store/

Quando usar /tmp/

✅ Ideal para:

• Arquivos temporários durante execução

• Dados intermediários descartáveis

• I/O intensivo (leitura/escrita frequente)

• Checkpoints temporários (se recriáveis)

❌ Nunca use para:

• Resultados finais

• Dados únicos não recriáveis

• Armazenamento entre jobs

Usando /tmp/ corretamente

usando_tmp.sh

#!/bin/bash
#SBATCH -J tmp_example
#SBATCH -N 1
#SBATCH -n 28
#SBATCH -t 06:00:00

export INPUT="dados_entrada.dat"
export OUTPUT="resultado_final.dat"
# job-nanny usará /tmp/ automaticamente (1 nó, sem flags)

job-nanny srun ./processador dados_entrada.dat

/store/ - Armazenamento Compartilhado

/store/ é um sistema de arquivos compartilhado entre todos os nós.

Características

• Acesso: Visível em todos os nós

• Velocidade: Média (acesso via rede NFS)

• Capacidade: 7 TB (compartilhado)

• Persistência: Permanente

• Compartilhamento: Visível para todos os nós

Quando usar /store/

✅ Ideal para:

• Jobs com múltiplos nós (MPI)

• Arquivos de entrada/saída muito grandes (>100 GB)

• Dados compartilhados entre usuários

• Datasets de referência

⚠️ Use com cuidado:

• Não é otimizado para I/O intensivo

• Pode ficar lento com muitos acessos simultâneos

Usando /store/

Automaticamente (jobs multi-nó):

job_multinode.sh

#!/bin/bash
#SBATCH -J mpi_job
#SBATCH -N 4
#SBATCH --ntasks-per-node=28
#SBATCH -t 48:00:00

export INPUT="dados_grandes/"
export OUTPUT="resultados_mpi/"
# Com -N 4, job-nanny usará /store/ automaticamente

module load openmpi/4.1.5
job-nanny mpirun -np $SLURM_NTASKS ./programa_mpi

Forçando uso do /store/ em job de 1 nó:

job_grande_1node.sh

#!/bin/bash
#SBATCH -J big_job
#SBATCH -N 1
#SBATCH -n 28
#SBATCH -t 72:00:00

export INPUT="dataset_500GB.bin"
export OUTPUT="resultados/"
export LARGE_FILES="true"      # Força uso do /store/

job-nanny srun ./processador dataset_500GB.bin

Gerenciando Espaço em Disco

Verificando uso do disco

# Uso total do seu /home/
du -sh /home/$USER

# Uso detalhado por subdiretórios
du -h --max-depth=1 /home/$USER | sort -hr

# Encontrar arquivos grandes (>1GB)
find /home/$USER -type f -size +1G -exec ls -lh {} \;

# Ver espaço livre no sistema
df -h /home
df -h /store

Exemplo de saída:

$ du -sh /home/joaox
45G     /home/joaox

$ du -h --max-depth=1 /home/joaox | sort -hr
28G     /home/joaox/projeto2
15G     /home/joaox/projeto1
2.1G    /home/joaox/software
512M    /home/joaox/scripts
45G     /home/joaox

Limpeza de arquivos

# Remover arquivos de log antigos (>90 dias)
find /home/$USER -name "*.log" -mtime +90 -delete
find /home/$USER -name "slurm-*.out" -mtime +30 -delete

# Remover diretórios temporários
rm -rf /home/$USER/tmp/
rm -rf /home/$USER/resultados_antigos/

# Comprimir dados antigos (antes de remover)
tar -czf projeto_antigo.tar.gz projeto_antigo/
rm -rf projeto_antigo/

# Limpar cache do Conda (se usar)
conda clean --all

Compartilhando Dados com Outros Usuários

Para compartilhar dados com colegas do mesmo projeto:

# Criar diretório em /home/ (recomendado para dados compartilhados)
mkdir -p /home/$USER/projeto_compartilhado
chmod 750 /home/$USER/projeto_compartilhado

# Copiar dados
cp -r seus_dados /home/$USER/projeto_compartilhado/

# Ajustar permissões (grupo pode ler/executar)
chmod -R 750 /home/$USER/projeto_compartilhado
chgrp -R nome_do_grupo /home/$USER/projeto_compartilhado

# Verificar permissões
ls -la /home/$USER/projeto_compartilhado

Para dados menores em /home/:

# Dar permissão de leitura para o grupo
chmod g+r arquivo_compartilhado.dat
chmod g+rx diretorio_compartilhado/

# Remover permissões para outros (segurança)
chmod o-rwx diretorio_compartilhado/

Política de Limpeza Automática

/tmp/:

• Arquivos em /tmp/ são automaticamente removidos ao final do job

• Podem ser removidos antes se o nó precisar de espaço

• NÃO HÁ GARANTIA de quanto tempo arquivos ficarão em /tmp/

/home/ e /store/:

• Atualmente não há limpeza automática

• Caso o job finalize com sucesso, o job-nanny remove arquivos/diretórios automaticamente do /store

• Porém, o acúmulo excessivo pode levar a:

  • Lentidão do sistema

  • Falhas em jobs por falta de espaço

  • Solicitação de limpeza pela equipe

Recomendações:

• Mantenha apenas o necessário para processamento atual/futuro

• Transfira resultados importantes para seu computador local

• Limpe regularmente arquivos temporários e resultados antigos

• Use /store/ para dados grandes, mas também mantenha organizado

Estratégias de Backup

Dada a ausência de backup no GridUnesp, você deve implementar suas próprias estratégias.

Opção 1: Backup Manual com rsync

# Do seu computador local, faça backup do GridUnesp
rsync -avz --progress seu-usuario@access.grid.unesp.br:/home/seu-usuario/ ~/backup-gridunesp/

# Automatize com cron (Linux/Mac)
# Adicione ao crontab (crontab -e):
0 2 * * 0 rsync -avz seu-usuario@access.grid.unesp.br:/home/seu-usuario/ ~/backup-gridunesp/

Opção 2: Git para Código

# No GridUnesp, dentro do seu projeto
git init
git add .
git commit -m "Initial commit"

# Conectar ao GitHub/GitLab (criar repositório primeiro)
git remote add origin https://github.com/seu-usuario/seu-projeto.git
git push -u origin main

Vantagens:

• Versionamento de código

• Backup automático na nuvem

• Colaboração facilitada

Opção 3: Cloud Storage (rclone)

# Configurar rclone (uma vez)
# Siga as instruções para conectar ao Google Drive, Dropbox, etc.
rclone config

# Fazer backup
rclone sync /home/$USER/projeto-importante remote:backup-gridunesp/

# Agendar com cron
0 3 * * * rclone sync /home/$USER/resultados-importantes remote:backup/

Opção 4: Tarball Periódico

backup_script.sh

#!/bin/bash
# Script para criar backup compactado

DATA=$(date +%Y-%m-%d)
BACKUP_DIR="/home/$USER/backups"
mkdir -p $BACKUP_DIR

# Lista de diretórios importantes
DIRS=(
    "/home/$USER/projeto1"
    "/home/$USER/projeto2"
    "/home/$USER/scripts"
)

# Criar arquivo tar.gz
tar -czf $BACKUP_DIR/backup-$DATA.tar.gz "${DIRS[@]}"

# Copiar para local seguro (exemplo: servidor institucional)
scp $BACKUP_DIR/backup-$DATA.tar.gz usuario@servidor-seguro:/backups/

# Manter apenas últimos 5 backups
ls -t $BACKUP_DIR/backup-*.tar.gz | tail -n +6 | xargs -r rm

Melhores Práticas

Regra 3-2-1

• 3 cópias dos dados

• Em 2 mídias diferentes

• 1 cópia off-site

Checklist de Backup

• [ ] Código fonte em Git (GitHub/GitLab)

• [ ] Resultados importantes copiados para computador local

• [ ] Scripts e configurações versionados

• [ ] Dados brutos (se não recriáveis) têm cópia externa

• [ ] Backup testado periodicamente (tente restaurar!)

Otimização de I/O

Para melhor performance de leitura/escrita:

1. Minimize número de arquivos

   # Ruim: 10000 arquivos pequenos
   for i in {1..10000}; do
       echo "$i" >> file_$i.txt
   done
   
   # Bom: 1 arquivo
   for i in {1..10000}; do
       echo "$i"
   done > all_data.txt
   

2. Use formatos binários eficientes

   • HDF5 para dados científicos multidimensionais

   • NetCDF para dados geoespaciais/climáticos

   • Parquet para dados tabulares grandes

   • NPY/NPZ para arrays NumPy

3. Comprima dados inativos

   # Comprimir
   tar -czf dados-2023.tar.gz dados-2023/
   
   # Quando precisar (mais lento, mas economiza espaço)
   tar -xzf dados-2023.tar.gz
   

Solução de Problemas

“No space left on device”

# Verificar uso
df -h /home
du -sh /home/$USER | sort -hr | head -20

# Limpar arquivos grandes/desnecessários
find /home/$USER -name "core.*" -delete
find /home/$USER -name "*.tmp" -delete
find /home/$USER -name "slurm-*.out" -mtime +30 -delete

“Permission denied” ao acessar /store/

# Verificar permissões
ls -la /store/$USER

# Corrigir se necessário
### Acesso total ao proprietário (leitura, escrita e execução)
### e permissão de leitura e execução para o grupo e outros usuários
chmod 755 /store/$USER
### Acesso para que o dono possa ler e alterar,
### e os outros usuários possam apenas ler
chmod 644 /store/$USER/*

Arquivos sumiram de /tmp/

• É normal e esperado. /tmp/ é temporário!

• Solução:

  • Sempre copie resultados para /home/

  • job-nanny cópia automaticamente ao fim de jobs que finalizaram com sucesso

Performance de I/O lenta

1. Verifique se está usando /tmp/ para I/O intensivo

2. Reduza número de arquivos pequenos

3. Use formatos binários em vez de texto

4. Evite listar diretórios com muitos arquivos (ls)

Dúvidas Frequentes

P: Posso aumentar minha quota de disco?

R: Não há quotas! Mas use com responsabilidade. O espaço é compartilhado com todos os usuários.

P: Quanto tempo os dados ficam em /store/?

R: Permanentemente, até você deletar ou o hardware falhar. Faça backup!

P: Por que dados do job em /store/ foram apagados?

R: O job-nanny apaga dados automaticamente após o fim de jobs que finazaram com sucesso.

P: Posso recuperar dados deletados acidentalmente?

R: Não. O GridUnesp não tem sistema de recuperação. Use backups.

P: Como compartilhar dados com colegas?

R: Use /store/ e ajuste permissões de grupo, ou use /home/ com permissões adequadas.

P: Posso montar /home/ no meu computador local?

R: Não diretamente. Use scp, rsync, ou sshfs para acesso remoto.

P: O que acontece se o /store/ encher?

R: Jobs podem falhar, e o sistema pode ficar lento. Limpe dados desnecessários.

Ver também

• Boas Práticas - Recomendações gerais

• Processando Simulações - Como usar os sistemas em jobs

• Usando o job-nanny - Gerenciamento automático de arquivos

• Transferindo Arquivos - Como transferir dados