1 |
Oi, |
2 |
|
3 |
Algum de vcs que discorda da minha afirmação de que LVM É UMA BOSTA EM |
4 |
DESEMPENHO, já usou em cima de ORACLE por exemplo? |
5 |
Só uma curiosidade pra saber onde foi a experiência pessoal que os |
6 |
levou a concluir que LVM compensa. kkkkkkkkkkk |
7 |
|
8 |
Att, |
9 |
Raphael Bastos |
10 |
|
11 |
=============================================== |
12 |
Bastos Service Manutenção Industrial Ltda. |
13 |
http://www.bastosservice.com.br |
14 |
Linux Reg. User: 388431 // LPI ID: LPI000214711 |
15 |
email:~> $ echo "vgepqnqikcBdcuvquugtxkeg0eqo0dt" | perl -pe \ |
16 |
's/(.)/chr(ord($1)-2)/ge' |
17 |
Projeto pessoal:~> http://wiki.hackstore.com.br |
18 |
=============================================== |
19 |
|
20 |
|
21 |
Em 11 de setembro de 2012 01:06, Daniel da Veiga |
22 |
<danieldaveiga@×××××.com> escreveu: |
23 |
> 2012/9/11 Pablo Hess <natunobilis@××××××××.org>: |
24 |
>>>> LVM é uma bosta em desempenho. :D |
25 |
>>> |
26 |
>>> Faz sentido. =) |
27 |
>> |
28 |
>> Faz não. Nenhum. |
29 |
>> |
30 |
>> E a flexibilidade que se ganha é significativamente maior, |
31 |
>> principalmente se você quiser usar máquinas virtuais sobre KVM. Já |
32 |
>> experimentou abrigar VMs em arquivos .img em comparação com o uso de |
33 |
>> LV's para isso? A diferença de velocidade é gritante *a favor* do LVM. |
34 |
>> |
35 |
>> Não à toa, algumas distribuições já usam LVM no layout padrão do disco |
36 |
>> (exemplos: Fedora e família Red Hat). |
37 |
>> |
38 |
>> E mesmo sem KVM, cadê os comparativos pra embasar sua afirmação? Os |
39 |
>> últimos números que vi nesse sentido foram publicados no Phoronix e |
40 |
>> mostraram o mesmo desempenho com e sem LVM. Na verdade, até foi MELHOR |
41 |
>> com LVM, mas só porque o teste sem LVM não estava desativando as |
42 |
>> barriers, enquanto que o LVM não usava barriers. |
43 |
>> |
44 |
> |
45 |
> Até onde eu saiba, LVM não tem impacto significativo na velocidade. No |
46 |
> entanto, é mais uma camada de abstração, que torna todo o setup mais |
47 |
> complicado (desnecessariamente complicado para uma instalação desktop, |
48 |
> no caso). A única razão para se fazer isso seria no uso de VMs, o que, |
49 |
> convenhamos, também geralmente não é o caso em um desktop comum, e a |
50 |
> performance usando uma partição, um volume lógico ou mesmo uma imagem |
51 |
> não vai impedir ninguém de usar o mais fácil (eu ao menos não espero |
52 |
> performance gritante de meu XP ou 7 virtualizado, ele não é rápido nem |
53 |
> rodando direto no hardware). |
54 |
> |
55 |
> Então, se a performance não é um bom motivo, que tal a complexidade |
56 |
> envolvida? Convenhamos, tem uma curva de aprendizado. Eu não sei como |
57 |
> é hoje, mas quando testei, era necessário usar initram, o que hoje |
58 |
> também me afastaria, já que não tenho praticamente nada em módulos e |
59 |
> até o genkernel parei de usar, por adicionar complicações |
60 |
> desnecessárias. |
61 |
> |
62 |
> Enfim, hoje, em um desktop, eu elimino complicações, se fosse um |
63 |
> notebook por exemplo, já falamos de encriptação e outros sistemas de |
64 |
> segurança, mas no meu desktop não vejo motivos para ter isso. Quanto |
65 |
> mais straigh forward melhor. |
66 |
> |
67 |
> -- |
68 |
> Daniel da Veiga |
69 |
> |