| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | | <shameless-plug>
Se estiverem interessados, podem também experimentar o ZFS on FUSE (blog), que apresenta (ou vai apresentar em breve) muitas características em comum com o projecto do artigo, e cujo código do repositório mercurial já está bastante estável.
Aliás, tenciono lançar a 1ª versão beta assim que resolver 2 pequenos problemas de performance :)
</shameless-plug>
|
| | | | | | só falta acrescentar que FUSE é um performance-hit inaceitavel para ambientes 'enterprise'.
|
| | | | Eu pessoalmente penso que a fiabilidade oferecida pelo ZFS é muito mais importante do que a performance bruta em sistemas de ficheiros orientados para empresas.
E o FUSE por si só não causa uma grande queda de performance, dado que muitas vezes a performance de I/O é limitada pela performance dos discos (e também pelas estruturas de dados utilizadas pelos sistemas de ficheiros), e não pelo CPU.
A prova disso é o ntfs-3g ser mais rápido em muitas operações do que o próprio ext3.
Existem muitos casos de sistemas de ficheiros implementados sobre o FUSE a serem usados em sistemas enterprise.
|
| | | | fiabilidade ?
desde quando é que o FUSE é fiavel ?
o ZFS é (em solaris). o FUSE não.
filesystems em Userspace... faz lembrar o IFS em Windows.
é muito giro para gamers, para casa, para uma SMB e afins. num ambiente 'enterprise' onde se pode beneficar a serio do ZFS, o FUSE junto no pacote, IMHO, acaba por ser um contra-senso :)
"A prova disso é o ntfs-3g ser mais rápido em muitas operações do que o próprio ext3."
e depois? que tipo de operações? estás a comparar alhos com bugalhos...
e já agora, filesystem em userspace? ...security comes to mind ;)
|
| | | | Para coisas mesmo grandes (não estou a falar da "enterprise" dali da esquina que vende fruta) tens que usar o userspace. Não há hipótese.
Mesmo uma coisa relativamente simples como o CIFS (era isto que querias dizer com IFS?) em kernel mode no windows foi/é/será um pesadelo tanto em termos de fiabilidade, escalabilidade e "features" como em termos de segurança.
Exacto. Eu acho que estás errado em todos os pontos. (Repara que estou a falar em ambientes tipo google ou k-mart... Não estou a falar da "enterprise da esquina" com 100 ou 200 servers).
Hey. Eu uso filesystems normais, mas eu não preciso de 100GBytes/sec de banda ou de Exabytes de storage nem de um sistema de permissões sofisticadissimo integrado no filesystem (em vez de andarem umas apps desenvolvidas à pressa a tratarem da segurança do filesystem, como o pessoal que desenvolve "sites de e-commerce" para as tais "enterprises da esquina" faz (-: ).
...É de manhã e foste o primeiro que apanhei. Desculpa :-)
paz,
ratao |
| | | | ZFS em Solaris não é User Space :o)
o port que estão a fazer em BSD também não.
explica-lhe lá a necessidade de usar ZFS em FUSE ?
e quanto a filesystems... em parques de 3000 a 5000 servidores, até agora o que vi mais foi Veritas FS.
e suporta ACLS, tem HSM, the works.. ;)
quanto ao IFS, não me refiro ao CIFS. refiro-me ao à layer chamada Installable File System que na pratica é a mesma merda que o FUSE mas pra Windows.
A propria Micro tem cursos dados internamente ou a parceiros Gold (apesar de outsourçados a outra empresa) de desenvolvimento de file systems pra Windows baseado em IFS.
Em que é que vale o IFS?
(retro-)compatibilidade com outros Sistemas Operativos. em poucos dias se faz uma coisa destas.
|
| | | | e levando a coisa mais longe, apesar de não ser open-source, é de borla, é isto.
|
| | | | Tu estavas a cascar no FUSE por ser userspace e parece que gostas das pseudo-enterprises. Pareceu-me um contra-senso.
Só te estava a demonstrar que as coisas *mesmo* grandes, pela extrema complexidade que envolvem, vão ter que ser em userspace. E os filesystems não escapam à realidade :-)
Deixando as generalidades e passando para o particular:
Agora anda toda a gente apaixonada pelo ZFS. Eu até acho bem. Juntamente com o dtrace é a característica que mais gente chama para o opensolaris, e espero que o OS (open solaris eheheh) tenha bastante sucesso.
O único problema (do ZFS) é ser muito recente. Ainda não apareceram as histórias de horror :-)
Quanto à utilidade de ter acesso fiavel ao ZFS em Linux? É a mesma que ter acesso ao NTFS. Comodidade! Do ponto de vista do programador, se calhar depois de ver ZFS à frente durante meses já tem avontade suficiente para colaborar na construção de um driver clássico. Ou quer ser contratado pela Sun. Who cares?
Quanto ao VxFS: tem a vantagem de ser dos primeiros (ou o primeiro?) fs para clusters que era como um fs local. Quanto ao número de 5000 servers: estás a falar duma organização qualquer que tem 5000 servers em 500 clusters separados, provavelmente.
Eu estava a falar de *grande*. Para _começar_ podes imaginar um cluster composto por 50.000 máquinas, ligadas a 2000 SAN, apenas dedicado a exportar um filesystem. Via milhentas portas de dezenas de tipos de interconnects diferentes. (Do outro lado do estão 200.000 webservers ou outro cluster a fazer datamining, mas esta parte já não interessa porque são os meros utilizadores, não o filesystem)
Já há algumas coisas destas a funcionar. E muitas a serem construídas neste momento por simples empresas (não militares e não governamentais e afins).
Um bom link é o www.lustre.org
Quanto ao IFS para Windows: não conhecia. Obrigado pela informação.
paz,
ratao |
| | | | > Quanto à utilidade de ter acesso fiavel ao ZFS em Linux? É a mesma que ter acesso ao NTFS. Comodidade! Do ponto de vista do programador, se calhar depois de ver ZFS à frente durante meses já tem avontade suficiente para colaborar na construção de um driver clássico. Ou quer ser contratado pela Sun. Who cares?
Só a título de curiosidade.. as minhas motivações originais para fazer o port do ZFS foram 3:
1) Ter uma máquina que de vez em quando corrompe dados. Acontecia com o XFS e agora acontece com o ext3, tenho quase a certeza que é um problema de hardware ou de firmware.
2) Achar o design do ZFS simplesmente brilhante! É daquelas poucas coisas que eu não podia esperar pela hora em que pudesse usá-lo em todos os meus discos :-)
3) Participar no Google Summer of Code
Claro que sempre pensei na hipótese de fazer o port para o kernel do Linux.
Contudo, trata-se de um esforço muito maior e seria quase impossível eu conseguir fazê-lo nos 3 meses do Google Summer of Code.
Além disso, actualmente seria ilegal integrar o ZFS no kernel do Linux, pois a licença não o permite :p
Mas se um dia tal fôr possível e eu tiver essa oportunidade, agora que tenho mais experiência, não hesitarei em (tentar) fazê-lo :)
|
| | | | Passaste de XFS para ext3? Para os meus tipos de carga em servidores isso é andar para trás :-) Mesmo assim, boa sorte na resolução desse problema intermitente (são os piores...).
Contudo, trata-se de um esforço muito maior e seria quase impossível eu conseguir fazê-lo nos 3 meses do Google Summer of Code.
É por isso mesmo que alguns tipos de esforços não podem ser implementados no kernel. Simplesmente demorava 5x mais... E se em userspace demora 3 anos, no kernel demoraria uns 15 anos até estabilizar :-P
De qualquer modo o kernel está a ficar infestado de interfaces ultra-rápidos para comunicação com o userspace (inclusivé com zero-copy). O Ingo anda agora com a coisa das syscalls assincronas (syslets) que mal a glibc as implemente (a ver vamos... GPLv3 et al) vai tornar as interacções com o kernel ainda mais rápidas. Quem quiser ser aventireiro até pode usar o KML (http://web.yl.is.s.u-tokyo.ac.jp/~tosh/kml/)
Além disso, actualmente seria ilegal integrar o ZFS no kernel do Linux, pois a licença não o permite :p
Para quem gosta do tema está, já em fase de rescaldo, uma thread na LKML com o título "GPL vs non-GPL device drivers". Ver especialmente as mensagens do Michael K. Edwards. Pelo menos eu passei a ter algumas dúvidas em relação a uma boa parte das licensas tipo GPL e LGPL. E, aparte de uma ou duas mensagens "decentes", ninguém teve argumentos convincentes contra a teoria deste homem...
Bom off-topic, não foi? :-)
E obrigado por responderes e obrigado pelo ZFS para FUSE :-)
paz,
ratao |
| | | | | Acho que te devias informar um pouco mais sobre o FUSE :)
O FUSE, pela minha experiência, é bastante fiável.
Em cerca de 9 meses de desenvolvimento do zfs-fuse (que já teve todo o tipo de problemas de instabilidade - corrupções de memória, deadlocks, etc), nunca consegui crashar o kernel, nem nunca tive de fazer reboot, dado que o processo corre em userspace e as respostas são sempre validadas pelo kernel.
O FUSE é talvez mais fiável que qualquer outro filesystem em Linux, dado que é apenas uma fina camada sobre a VFS que envia pedidos de I/O para o user-space e devolve as respostas respectivas.
Em termos de segurança, até está bem pensado (senão não seria aceite na tree do Linus ;):
- Normalmente, é possível fazer mount a um sistema de ficheiros em que todos os users têm acesso, mas apenas o root pode fazer isso.
- Também é possível um user fazer mount de sistemas de ficheiros (apenas numa directoria cujo owner é ele mesmo), mas apenas esse user terá acesso ao FS.
Quanto ao tipo de operações em que o ntfs-3g era mais rápido, não tenho a certeza, mas lembro-me de ver um benchmark sintético com o bonnie++ em que o ntfs-3g era visivelmente mais rápido em algumas operações, penso que era a criação e a eliminação de ficheiros, talvez outras, não me recordo.
|
| | | | > Em termos de segurança, até está bem pensado (senão não seria aceite na tree do Linus ;): Heh, vai ler as discussões na LKML quando o FUSE foi proposto para inclusão, e depois vem falar de "segurança" e "bem pensado".
|
| | | | "O FUSE é talvez mais fiável que qualquer outro filesystem em Linux, dado que é apenas uma fina camada sobre a VFS que envia pedidos de I/O para o user-space e devolve as respostas respectivas."
ahmmm, não é por ai. mas não vale muito a pena discutir isso...
"- Normalmente, é possível fazer mount a um sistema de ficheiros em que todos os users têm acesso, mas apenas o root pode fazer isso."
not really, man fstab.
e quando falava de segurança, falava do esquema de controlo de acesso aos objectos do file system. tipo ACLs e afins.
|
| | | | "- Normalmente, é possível fazer mount a um sistema de ficheiros em que todos os users têm acesso, mas apenas o root pode fazer isso."
"not really, man fstab."
Transcrevendo do README do FUSE:
"allow_other
...
all users (including root) can access the files. This option is by default only allowed to root, but this restriction can be removed with a configuration option described in the previous section."
"e quando falava de segurança, falava do esquema de controlo de acesso aos objectos do file system. tipo ACLs e afins."
Aqui há 2 possibilidades:
1) O filesystem usa a opção "default_permissions" e o próprio FUSE faz o controlo de acesso no kernel, com permissões UNIX normais. É a opção mais simples.
2) O filesystem faz o seu controlo de acesso, o que permite implementar ACLs.
No caso do zfs-fuse, dado que o ZFS usa ACLs do tipo NFSv4, a gestão do controlo de acesso é feita no daemon do sistema de ficheiros.
|
| |
|
