Sistemas de Ficheiros Linux - Presentation Transcript
Sistemas de Ficheiros Miguel Mascarenhas Filipe, Junho de 2009, SAPO.PT Mergulho Profundo
Mapa
Ideias e Conceitos
Sistemas de Ficheiros Actuais
Características diferenciadoras
Problemas
Desenvolvimentos Actuais
Reiser4
Ext4
ZFS
BtrFS
Algumas Ideias, Conceitos
Block based
Journaling
Log based
Hashtables
Fragmentação
Extent based
Copy on Write
Btrees, Htrees
Bitmaps, Listas
Solid State Disks
Mais Ideias e Conceitos
Fiabilidade perante erros:
Dos dados
Dos meta-dados
Como ?
Redundância interna
Códigos de correcção de erros
Canários
RAID (?)
Integrar no FS :
Gestão de volumes
Gestão de discos
Backups
Snapshots
Compressão
Cifra ( encriptação )
Data dedup
Sistemas de Ficheiros actuais
Ext2 e Ext3
XFS
ReiserFS
... outros ...
Ext3
Evolução do Ext2
Journaling FS
Muito rápido em operações com metadata
Performance muito equilibrada numa grande variedade de workloads
Muito fiável e muito robusto a “ crashes ”
Desenho simples e bem dominado (quando comparado com os competidores)
Um ficheiro em Ext3
Ext3- Limitações
Directorias:
Com mais de 32k sub-directorias (limite de contador)
Com mais de ~32k ficheiros (degradação de performance)
Recentemente usa Htree's, tive problemas nos ~1M
Data intensive workloads
Nº máximo de ficheiros determinado na criação
Não lida muito bem com:
Ficheiros de grande dimensões (>1Gb)
Sistemas de ficheiros de grandes dimensões
Tolera mal corrupção de dados no hardware/disco
XFS
Optimizado para “ data intensive workloads ”
Muito bom a lidar com:
Ficheiros de grandes dimensões
Sistemas de ficheiros de grandes dimensões
Streaming de dados a baixas latências
Streaming de dados à velocidade dos disco ( platter speed )
Arrays de discos de alta capacidade
Muito bom a tirar partido de multi-processador
XFS – limitações
Mais difícil de manter, poucas pessoas com conhecimento para o manter/desenvolver
Código muito complexo, é um port /evolução do XFS presente no IRIX nos anos 90
Menos bom em operações com metadata
Por design o sistema de journaling é mais “ sensível ” que o Ext3
Tolera mal corrupção de dados no hardware/disco
ReiserFS
Muito bom com ficheiros de dimensão reduzida (<4k)
Tail packing
Muito rápido
Escala muito bem em:
Nº de ficheiros
Tamanho do sistema de ficheiros
ReiserFS – Limitações
Já não é mantido pelos criadores
Filesystem aging
Alguns bugs de corrupção de dados
Escala mal em sistemas SMP (trinco global a cada mount-point)
Código difícil de manter/seguir
Tolera mal corrupção de dados no hardware/disco
Limitações de todos
O aumento de capacidade dos discos não é acompanhada pela velocidade de leitura ou tempos de seek
Gerir maior volume de dados:
Quantidade de ficheiros/directorias
Tamanho dos ficheiros/directorias
Tempo de criação, Fsck, reparação, desfragmentação
Gerir maior carga de IO
Manter platter speed
Mais Limitações
Discos terão cada vez mais bad blocks e mais faltas silenciosas
Comportamento perante corrupção (activa e passiva) dos dados
Gestão de Backups
Gestão de volumes lógicos
Gestão de discos físicos, RAIDs
Boa performance com Solid State Disks
Reiser4
Btrees (dancing trees)
Transaccional
Journaled
Abstração para o “on-disk format”:
Plugins para compressão, cifra, etc..
Ficheiro como directório
Corridas e problemas de segurança
Delayed Allocation
Anunciada performance impressionante
Reiser4
Problemas:
Comunicação com a comunidade
Objecções técnicas a decisões arquitecturais
Hans Reiser (o criador) foi preso
Empresa foi desmantelada
Desenvolvimento parou
Não procura resolver problemas de:
Corrupção de dados no hardware/disco
Gestão de volumes, snapshots, backups
Ext4
Escala melhor, mais velocidade, mais robustês
Lida melhor com ficheiros/sistemas de grandes dimensões.
Extent based filesystem
Delayed Allocation
Persistent Pre-allocation
Faster fsck ( proporcional aos dados na partição )
Online Defragmentation
Htrees para extents, directory entries e links
Ext4
Tolera melhor faltas no hardware/disco:
Checksumming do journal
canários/health checks nos inodes válidos
Suporte para gigantes (>1 EB):
Volumes e Ficheiros (2^48/48bits)
Retro compatível
Resolução de tempo ao nanosegundo
Fsck() bastante mais rápido
Journal é opcional
ZFS Grande pioneiro de novos avanços e desenvolvimento em sistemas de ficheiros. “ The last word on File Systems” “ The Zettabyte File System” 1 ZB (10^21) = 1024 EB; 1 EB (10^18) = 1024 PB; 1 PB (10^15) = 1024 TB
ZFS
Suporte “multi-volume”/storage pool
Capacidade de gerir/usar vários discos.
Níveis de RAID: 0, 1, z, 2z...
RAIDz e RAIDz2 são melhorias do raid5 e 6
Unifica gestão de volumes, discos, mount-points.
Copy-On-Write:
Snapshotting/backups
Desfragmentação automática
Algumas capacidades transaccionais.
Data e Metadata checksumming
ZFS
Self-Healing
Sistema integrado raid/checksumming permite detectar faltas silenciosas no hardware/disco
Corrige automáticamente, notifica administrador
Dimensões gigantes (2^128/128bit)
Volumes
Nº de ficheiros
Nº de directorias ou ficheiros por directoria
Tamanho de ficheiros
Nº de sub-volumes e snapshots
ZFS
Licença incompatível com a GPL
Não integraria bem com os internals do Linux
Linux port : ZFS-FUSE
Várias ineficiências de performance
Problemas de fiabilidade, corrupção de dados
Desenvolvimento estagnou
ZFS tem vários problemas
Mas são pouco conhecidos, porque...
Base de utilizadores efectiva é muito pequena
BtrFS
Novo FS, começou em 2007, integrado no Linux-2.6.29 (experimental). Criado por Chris Mason, kernel hacker da Oracle
Bem recebido pela comunidade de hackers do Linux kernel.
Pretensões de ser o sucessor do Ext4
Desenvolvido em parceria pela comunidade Linux, com investimento explícito de:
Oracle, HP, IBM, RedHat, SuSE, outros
BtrFS
Extent Based, Copy on Write, Delayed Allocation
Dimensões gigantes (2^64/64bit)
nº ficheiros, tamanho de ficheiros, volumes, snapshots ...
Multi-Disco e Multi-Volume
Writable Snapshots
Data e Metadata checksumming
Compressão, cifra e data “ dedup ”
BtrFS
Online fsck e desfragmentação
Offline fsck muito rápido
B-Tree para tudo:
Sub-Volumes, Snapshots
dados (extents), Dir entries, inodes
Multi-threaded, multi-processador friendly
Design contempla Solid State Disks
Grande foco em minimizar o nº de seeks
Redundância distinta para meta-dados e dados
BtrFS
Desenho modular, podemos desligar/ligar:
Checksumming de dados
Checksumming de meta-dados
Copy-on-Write (é mau para BDs)
modo SSD ou modo normal
Forte integração com outros componentes do kernel
Multi-disk: md layer: raid5, raid6 e outros (planeado)
Bio, thread-pool, locking, rcu, buffer cache, etc
BtrFS
O nome BtrFS vem de:
Baseado em B-Tree
Better FS
Possível migrar um volume ext3 ou ext4 para btrfs usando o espaço livre da partição.
0 comments
Post a comment