Re: [FUG-BR] Acesso ao disco em vmware
Fiz um novo teste /extração usando freebsd 9 64bis, com disco pre-alocado, o resultado é de 14.20 min... Já com Freebsd 8 32bits, com disco não pre-alocado, ficou com tempo de 13.12 min. Alguém chegou a alguma conclusão para esta thread? Em 19 de maio de 2012 11:22, Welinaldo Lopes Nascimento < welina...@bsd.com.br> escreveu: > Estou implementando um servidor HP proliant com 4gb, até amanhã posto aqui > este resultado também.. > > Ari, qual foi o seu tempo para remoção? > > > > > Em 19 de maio de 2012 11:18, Welinaldo Lopes Nascimento < > welina...@bsd.com.br> escreveu: > > É um notebook Dell XPS, i7 2630QM, 8GB ram, só para estudo básico. >> >> Em 19 de maio de 2012 09:19, Ari Arantes Filho escreveu: >> >> 13minutos é muito tempo também. >>> >>> Qual a configuração da sua máquina? >>> >>> >>> Em 19 de maio de 2012 02:26, Welinaldo Lopes Nascimento >>> escreveu: >>> > e pra remover: >>> > >>> > 0.238 3.642s 3:44.30 1.7% >>> > >>> > Em 19 de maio de 2012 02:11, Welinaldo Lopes Nascimento < >>> > welina...@bsd.com.br> escreveu: >>> > >>> >> Ari, fiz o teste aqui no meu e ficou o seguinte: >>> >> >>> >> 7.088u 19.307s 13:12.91 3.3% >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> Em 18 de maio de 2012 18:37, Ari Arantes Filho >>> escreveu: >>> >> >>> >> Testei com o disco sem o thinprovisioning: >>> >>> >>> >>> # time tar xzf ports.tar.gz >>> >>> >>> >>> real16m8.904s >>> >>> >>> >>> mesma coisa, péssima performance. >>> >>> >>> >>> >>> >>> >>> >>> Em 18 de maio de 2012 17:17, Welinaldo Lopes Nascimento >>> >>> escreveu: >>> >>> > Beleza Ari, vamos ficar aguardando o resultado... >>> >>> > Amanhã vou fazer o mesmo e posto aqui também o resultado. >>> >>> > >>> >>> > Em 18 de maio de 2012 17:08, Ari Arantes Filho >>> >>> escreveu: >>> >>> > >>> >>> >> Vou reinstalar um FreeBSD 9 e utilizar um disco sem o >>> thinprovisioning >>> >>> >> e reporto aqui na lista os resultados. >>> >>> >> >>> >>> >> Em 18 de maio de 2012 17:01, Rafael Henrique Faria >>> >>> >> escreveu: >>> >>> >> > 2012/5/18 Ari Arantes Filho >>> >>> >> > >>> >>> >> >> 1) sempre rodo o tar xzf ports.tar.gz e depois rm -rf ports, ou >>> >>> seja, >>> >>> >> >> libero o espaço e teoricamente o vmware não precisará aumentar >>> >>> >> >> novamente >>> >>> >> >> >>> >>> >> > >>> >>> >> > Eu posso estar errado, os mais experientes neste caso que me >>> >>> corrijam, >>> >>> >> mas >>> >>> >> > o UFS2 em uso no caso do FreeBSD não faz isso que você está >>> >>> imaginando. >>> >>> >> > >>> >>> >> > Quando você descompacta a primeira vez o ports.tar.gz, o UFS2 >>> vai >>> >>> alocar >>> >>> >> o >>> >>> >> > espaço para o mesmo. E quando você apaga o mesmo, apesar do >>> espaço >>> >>> ficar >>> >>> >> > "livre", o UFS2 não apaga o conteũdo do disco. E uma nova >>> gravação, >>> >>> não >>> >>> >> irá >>> >>> >> > utilizar o espaço liberado, mas sim um espaço livre "virgem". O >>> >>> espaço >>> >>> >> > liberado somente será utilizando quando o disco não tiver mais >>> >>> espaços >>> >>> >> > livres. >>> >>> >> > >>> >>> >> > Ao utilizar recursos como este em HDs reais, o file system tem >>> uma >>> >>> >> melhora >>> >>> >> > de performance, pois não precisa ficar apagando o disco... ele >>> vai >>> >>> usando >>> >>> >> > espaços livres até que realmente seja necessário uma limpeza do >>> file >>> >>> >> system >>> >>> >> > por ter acabado o espaço livre. >>> >>> >> > >>> >>> >> > Ultimamente percebi que após algum tempo, algumas horas, o >>> espaço >>> >>> acaba >>> >>> >> > sendo liberado para uso... então acredito que tenha sido feita >>> uma >>> >>> >> > alteração para algum processo de varredura ir liberando o >>> espaço de >>> >>> tempo >>> >>> >> > em tempo.. mas isso não é em tempo real. >>> >>> >> > >>> >>> >> > Um exemplo prático disso: >>> >>> >> > >>> >>> >> > - esgote o espaço em disco com arquivos grandes. >>> >>> >> > - apague um dos arquivos grandes. >>> >>> >> > - o espaço não será liberado imediatamente... o disco vai >>> continuar >>> >>> >> > reclamando que não tem espaço livre o suficiente. >>> >>> >> > >>> >>> >> > Normalmente isso não apresenta grandes problemas... pois um bom >>> >>> >> > administrador nunca irá deixar esgotar o espaço em disco. >>> >>> >> > >>> >>> >> > Porém, no caso do thinprovisioning isso é um problema. Pois a >>> cada >>> >>> nova >>> >>> >> > gravação ele vai precisar requisitar do HOST um novo espaço em >>> >>> disco. O >>> >>> >> que >>> >>> >> > acaba ficando lendo. >>> >>> >> > >>> >>> >> > Eu sinceramente evito usar thinprovisioning em servidores de >>> >>> >> virtualização, >>> >>> >> > tanto por causa deste problema, quanto pelo efeito surpresa, de >>> você >>> >>> >> alocar >>> >>> >> > 10 HDs de 1TB em um volume de 7TB, e acontecer de os 10 HDs >>> >>> precisaram >>> >>> >> usar >>> >>> >> > os 1TB oferecidos para o mesmo. Claro que é um exemplo, na >>> prática >>> >>> >> teremos >>> >>> >> > 40 máquinas com HDs de tamanhos variados, que se tornará difícil >>> >>> ficar >>> >
Re: [FUG-BR] Acesso ao disco em vmware
Estou implementando um servidor HP proliant com 4gb, até amanhã posto aqui este resultado também.. Ari, qual foi o seu tempo para remoção? Em 19 de maio de 2012 11:18, Welinaldo Lopes Nascimento < welina...@bsd.com.br> escreveu: > É um notebook Dell XPS, i7 2630QM, 8GB ram, só para estudo básico. > > Em 19 de maio de 2012 09:19, Ari Arantes Filho escreveu: > > 13minutos é muito tempo também. >> >> Qual a configuração da sua máquina? >> >> >> Em 19 de maio de 2012 02:26, Welinaldo Lopes Nascimento >> escreveu: >> > e pra remover: >> > >> > 0.238 3.642s 3:44.30 1.7% >> > >> > Em 19 de maio de 2012 02:11, Welinaldo Lopes Nascimento < >> > welina...@bsd.com.br> escreveu: >> > >> >> Ari, fiz o teste aqui no meu e ficou o seguinte: >> >> >> >> 7.088u 19.307s 13:12.91 3.3% >> >> >> >> >> >> >> >> >> >> >> >> Em 18 de maio de 2012 18:37, Ari Arantes Filho >> escreveu: >> >> >> >> Testei com o disco sem o thinprovisioning: >> >>> >> >>> # time tar xzf ports.tar.gz >> >>> >> >>> real16m8.904s >> >>> >> >>> mesma coisa, péssima performance. >> >>> >> >>> >> >>> >> >>> Em 18 de maio de 2012 17:17, Welinaldo Lopes Nascimento >> >>> escreveu: >> >>> > Beleza Ari, vamos ficar aguardando o resultado... >> >>> > Amanhã vou fazer o mesmo e posto aqui também o resultado. >> >>> > >> >>> > Em 18 de maio de 2012 17:08, Ari Arantes Filho >> >>> escreveu: >> >>> > >> >>> >> Vou reinstalar um FreeBSD 9 e utilizar um disco sem o >> thinprovisioning >> >>> >> e reporto aqui na lista os resultados. >> >>> >> >> >>> >> Em 18 de maio de 2012 17:01, Rafael Henrique Faria >> >>> >> escreveu: >> >>> >> > 2012/5/18 Ari Arantes Filho >> >>> >> > >> >>> >> >> 1) sempre rodo o tar xzf ports.tar.gz e depois rm -rf ports, ou >> >>> seja, >> >>> >> >> libero o espaço e teoricamente o vmware não precisará aumentar >> >>> >> >> novamente >> >>> >> >> >> >>> >> > >> >>> >> > Eu posso estar errado, os mais experientes neste caso que me >> >>> corrijam, >> >>> >> mas >> >>> >> > o UFS2 em uso no caso do FreeBSD não faz isso que você está >> >>> imaginando. >> >>> >> > >> >>> >> > Quando você descompacta a primeira vez o ports.tar.gz, o UFS2 vai >> >>> alocar >> >>> >> o >> >>> >> > espaço para o mesmo. E quando você apaga o mesmo, apesar do >> espaço >> >>> ficar >> >>> >> > "livre", o UFS2 não apaga o conteũdo do disco. E uma nova >> gravação, >> >>> não >> >>> >> irá >> >>> >> > utilizar o espaço liberado, mas sim um espaço livre "virgem". O >> >>> espaço >> >>> >> > liberado somente será utilizando quando o disco não tiver mais >> >>> espaços >> >>> >> > livres. >> >>> >> > >> >>> >> > Ao utilizar recursos como este em HDs reais, o file system tem >> uma >> >>> >> melhora >> >>> >> > de performance, pois não precisa ficar apagando o disco... ele >> vai >> >>> usando >> >>> >> > espaços livres até que realmente seja necessário uma limpeza do >> file >> >>> >> system >> >>> >> > por ter acabado o espaço livre. >> >>> >> > >> >>> >> > Ultimamente percebi que após algum tempo, algumas horas, o espaço >> >>> acaba >> >>> >> > sendo liberado para uso... então acredito que tenha sido feita >> uma >> >>> >> > alteração para algum processo de varredura ir liberando o espaço >> de >> >>> tempo >> >>> >> > em tempo.. mas isso não é em tempo real. >> >>> >> > >> >>> >> > Um exemplo prático disso: >> >>> >> > >> >>> >> > - esgote o espaço em disco com arquivos grandes. >> >>> >> > - apague um dos arquivos grandes. >> >>> >> > - o espaço não será liberado imediatamente... o disco vai >> continuar >> >>> >> > reclamando que não tem espaço livre o suficiente. >> >>> >> > >> >>> >> > Normalmente isso não apresenta grandes problemas... pois um bom >> >>> >> > administrador nunca irá deixar esgotar o espaço em disco. >> >>> >> > >> >>> >> > Porém, no caso do thinprovisioning isso é um problema. Pois a >> cada >> >>> nova >> >>> >> > gravação ele vai precisar requisitar do HOST um novo espaço em >> >>> disco. O >> >>> >> que >> >>> >> > acaba ficando lendo. >> >>> >> > >> >>> >> > Eu sinceramente evito usar thinprovisioning em servidores de >> >>> >> virtualização, >> >>> >> > tanto por causa deste problema, quanto pelo efeito surpresa, de >> você >> >>> >> alocar >> >>> >> > 10 HDs de 1TB em um volume de 7TB, e acontecer de os 10 HDs >> >>> precisaram >> >>> >> usar >> >>> >> > os 1TB oferecidos para o mesmo. Claro que é um exemplo, na >> prática >> >>> >> teremos >> >>> >> > 40 máquinas com HDs de tamanhos variados, que se tornará difícil >> >>> ficar >> >>> >> > acompanhando o crescimento, e o tamanho configurado para cada >> uma no >> >>> >> > momento da crianção da máquina. >> >>> >> > >> >>> >> > -- >> >>> >> > Rafael Henrique da Silva Faria >> >>> >> > - >> >>> >> > Histórico: http://www.fug.com.br/historico/html/freebsd/ >> >>> >> > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >> >>> >> - >> >>> >> Histórico: http://www.fug.com.br/historico/html/freebsd/ >> >>> >> Sai
Re: [FUG-BR] Acesso ao disco em vmware
É um notebook Dell XPS, i7 2630QM, 8GB ram, só para estudo básico. Em 19 de maio de 2012 09:19, Ari Arantes Filho escreveu: > 13minutos é muito tempo também. > > Qual a configuração da sua máquina? > > > Em 19 de maio de 2012 02:26, Welinaldo Lopes Nascimento > escreveu: > > e pra remover: > > > > 0.238 3.642s 3:44.30 1.7% > > > > Em 19 de maio de 2012 02:11, Welinaldo Lopes Nascimento < > > welina...@bsd.com.br> escreveu: > > > >> Ari, fiz o teste aqui no meu e ficou o seguinte: > >> > >> 7.088u 19.307s 13:12.91 3.3% > >> > >> > >> > >> > >> > >> Em 18 de maio de 2012 18:37, Ari Arantes Filho > escreveu: > >> > >> Testei com o disco sem o thinprovisioning: > >>> > >>> # time tar xzf ports.tar.gz > >>> > >>> real16m8.904s > >>> > >>> mesma coisa, péssima performance. > >>> > >>> > >>> > >>> Em 18 de maio de 2012 17:17, Welinaldo Lopes Nascimento > >>> escreveu: > >>> > Beleza Ari, vamos ficar aguardando o resultado... > >>> > Amanhã vou fazer o mesmo e posto aqui também o resultado. > >>> > > >>> > Em 18 de maio de 2012 17:08, Ari Arantes Filho > >>> escreveu: > >>> > > >>> >> Vou reinstalar um FreeBSD 9 e utilizar um disco sem o > thinprovisioning > >>> >> e reporto aqui na lista os resultados. > >>> >> > >>> >> Em 18 de maio de 2012 17:01, Rafael Henrique Faria > >>> >> escreveu: > >>> >> > 2012/5/18 Ari Arantes Filho > >>> >> > > >>> >> >> 1) sempre rodo o tar xzf ports.tar.gz e depois rm -rf ports, ou > >>> seja, > >>> >> >> libero o espaço e teoricamente o vmware não precisará aumentar > >>> >> >> novamente > >>> >> >> > >>> >> > > >>> >> > Eu posso estar errado, os mais experientes neste caso que me > >>> corrijam, > >>> >> mas > >>> >> > o UFS2 em uso no caso do FreeBSD não faz isso que você está > >>> imaginando. > >>> >> > > >>> >> > Quando você descompacta a primeira vez o ports.tar.gz, o UFS2 vai > >>> alocar > >>> >> o > >>> >> > espaço para o mesmo. E quando você apaga o mesmo, apesar do espaço > >>> ficar > >>> >> > "livre", o UFS2 não apaga o conteũdo do disco. E uma nova > gravação, > >>> não > >>> >> irá > >>> >> > utilizar o espaço liberado, mas sim um espaço livre "virgem". O > >>> espaço > >>> >> > liberado somente será utilizando quando o disco não tiver mais > >>> espaços > >>> >> > livres. > >>> >> > > >>> >> > Ao utilizar recursos como este em HDs reais, o file system tem uma > >>> >> melhora > >>> >> > de performance, pois não precisa ficar apagando o disco... ele vai > >>> usando > >>> >> > espaços livres até que realmente seja necessário uma limpeza do > file > >>> >> system > >>> >> > por ter acabado o espaço livre. > >>> >> > > >>> >> > Ultimamente percebi que após algum tempo, algumas horas, o espaço > >>> acaba > >>> >> > sendo liberado para uso... então acredito que tenha sido feita uma > >>> >> > alteração para algum processo de varredura ir liberando o espaço > de > >>> tempo > >>> >> > em tempo.. mas isso não é em tempo real. > >>> >> > > >>> >> > Um exemplo prático disso: > >>> >> > > >>> >> > - esgote o espaço em disco com arquivos grandes. > >>> >> > - apague um dos arquivos grandes. > >>> >> > - o espaço não será liberado imediatamente... o disco vai > continuar > >>> >> > reclamando que não tem espaço livre o suficiente. > >>> >> > > >>> >> > Normalmente isso não apresenta grandes problemas... pois um bom > >>> >> > administrador nunca irá deixar esgotar o espaço em disco. > >>> >> > > >>> >> > Porém, no caso do thinprovisioning isso é um problema. Pois a cada > >>> nova > >>> >> > gravação ele vai precisar requisitar do HOST um novo espaço em > >>> disco. O > >>> >> que > >>> >> > acaba ficando lendo. > >>> >> > > >>> >> > Eu sinceramente evito usar thinprovisioning em servidores de > >>> >> virtualização, > >>> >> > tanto por causa deste problema, quanto pelo efeito surpresa, de > você > >>> >> alocar > >>> >> > 10 HDs de 1TB em um volume de 7TB, e acontecer de os 10 HDs > >>> precisaram > >>> >> usar > >>> >> > os 1TB oferecidos para o mesmo. Claro que é um exemplo, na prática > >>> >> teremos > >>> >> > 40 máquinas com HDs de tamanhos variados, que se tornará difícil > >>> ficar > >>> >> > acompanhando o crescimento, e o tamanho configurado para cada uma > no > >>> >> > momento da crianção da máquina. > >>> >> > > >>> >> > -- > >>> >> > Rafael Henrique da Silva Faria > >>> >> > - > >>> >> > Histórico: http://www.fug.com.br/historico/html/freebsd/ > >>> >> > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > >>> >> - > >>> >> Histórico: http://www.fug.com.br/historico/html/freebsd/ > >>> >> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > >>> >> > >>> > > >>> > > >>> > > >>> > -- > >>> > .:: Welinaldo L N > >>> > .:: Estudante de Desenvolvimento de Sistemas > >>> > .:: FreeBSD Community Member #BSD/OS > >>> > .:: Antes de imprimir, veja se realmente é necessário! > >>> > .ılı..ılı. > >>> > - > >>> > Histórico: http://www.fug.com.br/historico/
Re: [FUG-BR] Acesso ao disco em vmware
13minutos é muito tempo também. Qual a configuração da sua máquina? Em 19 de maio de 2012 02:26, Welinaldo Lopes Nascimento escreveu: > e pra remover: > > 0.238 3.642s 3:44.30 1.7% > > Em 19 de maio de 2012 02:11, Welinaldo Lopes Nascimento < > welina...@bsd.com.br> escreveu: > >> Ari, fiz o teste aqui no meu e ficou o seguinte: >> >> 7.088u 19.307s 13:12.91 3.3% >> >> >> >> >> >> Em 18 de maio de 2012 18:37, Ari Arantes Filho escreveu: >> >> Testei com o disco sem o thinprovisioning: >>> >>> # time tar xzf ports.tar.gz >>> >>> real 16m8.904s >>> >>> mesma coisa, péssima performance. >>> >>> >>> >>> Em 18 de maio de 2012 17:17, Welinaldo Lopes Nascimento >>> escreveu: >>> > Beleza Ari, vamos ficar aguardando o resultado... >>> > Amanhã vou fazer o mesmo e posto aqui também o resultado. >>> > >>> > Em 18 de maio de 2012 17:08, Ari Arantes Filho >>> escreveu: >>> > >>> >> Vou reinstalar um FreeBSD 9 e utilizar um disco sem o thinprovisioning >>> >> e reporto aqui na lista os resultados. >>> >> >>> >> Em 18 de maio de 2012 17:01, Rafael Henrique Faria >>> >> escreveu: >>> >> > 2012/5/18 Ari Arantes Filho >>> >> > >>> >> >> 1) sempre rodo o tar xzf ports.tar.gz e depois rm -rf ports, ou >>> seja, >>> >> >> libero o espaço e teoricamente o vmware não precisará aumentar >>> >> >> novamente >>> >> >> >>> >> > >>> >> > Eu posso estar errado, os mais experientes neste caso que me >>> corrijam, >>> >> mas >>> >> > o UFS2 em uso no caso do FreeBSD não faz isso que você está >>> imaginando. >>> >> > >>> >> > Quando você descompacta a primeira vez o ports.tar.gz, o UFS2 vai >>> alocar >>> >> o >>> >> > espaço para o mesmo. E quando você apaga o mesmo, apesar do espaço >>> ficar >>> >> > "livre", o UFS2 não apaga o conteũdo do disco. E uma nova gravação, >>> não >>> >> irá >>> >> > utilizar o espaço liberado, mas sim um espaço livre "virgem". O >>> espaço >>> >> > liberado somente será utilizando quando o disco não tiver mais >>> espaços >>> >> > livres. >>> >> > >>> >> > Ao utilizar recursos como este em HDs reais, o file system tem uma >>> >> melhora >>> >> > de performance, pois não precisa ficar apagando o disco... ele vai >>> usando >>> >> > espaços livres até que realmente seja necessário uma limpeza do file >>> >> system >>> >> > por ter acabado o espaço livre. >>> >> > >>> >> > Ultimamente percebi que após algum tempo, algumas horas, o espaço >>> acaba >>> >> > sendo liberado para uso... então acredito que tenha sido feita uma >>> >> > alteração para algum processo de varredura ir liberando o espaço de >>> tempo >>> >> > em tempo.. mas isso não é em tempo real. >>> >> > >>> >> > Um exemplo prático disso: >>> >> > >>> >> > - esgote o espaço em disco com arquivos grandes. >>> >> > - apague um dos arquivos grandes. >>> >> > - o espaço não será liberado imediatamente... o disco vai continuar >>> >> > reclamando que não tem espaço livre o suficiente. >>> >> > >>> >> > Normalmente isso não apresenta grandes problemas... pois um bom >>> >> > administrador nunca irá deixar esgotar o espaço em disco. >>> >> > >>> >> > Porém, no caso do thinprovisioning isso é um problema. Pois a cada >>> nova >>> >> > gravação ele vai precisar requisitar do HOST um novo espaço em >>> disco. O >>> >> que >>> >> > acaba ficando lendo. >>> >> > >>> >> > Eu sinceramente evito usar thinprovisioning em servidores de >>> >> virtualização, >>> >> > tanto por causa deste problema, quanto pelo efeito surpresa, de você >>> >> alocar >>> >> > 10 HDs de 1TB em um volume de 7TB, e acontecer de os 10 HDs >>> precisaram >>> >> usar >>> >> > os 1TB oferecidos para o mesmo. Claro que é um exemplo, na prática >>> >> teremos >>> >> > 40 máquinas com HDs de tamanhos variados, que se tornará difícil >>> ficar >>> >> > acompanhando o crescimento, e o tamanho configurado para cada uma no >>> >> > momento da crianção da máquina. >>> >> > >>> >> > -- >>> >> > Rafael Henrique da Silva Faria >>> >> > - >>> >> > Histórico: http://www.fug.com.br/historico/html/freebsd/ >>> >> > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >>> >> - >>> >> Histórico: http://www.fug.com.br/historico/html/freebsd/ >>> >> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >>> >> >>> > >>> > >>> > >>> > -- >>> > .:: Welinaldo L N >>> > .:: Estudante de Desenvolvimento de Sistemas >>> > .:: FreeBSD Community Member #BSD/OS >>> > .:: Antes de imprimir, veja se realmente é necessário! >>> > .ılı..ılı. >>> > - >>> > Histórico: http://www.fug.com.br/historico/html/freebsd/ >>> > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >>> - >>> Histórico: http://www.fug.com.br/historico/html/freebsd/ >>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >>> >> >> >> >> -- >> .:: Welinaldo L N >> .:: Estudante de Desenvolvimento de Sistemas >> .:: FreeBSD Community Member #BSD/OS >> .:: Antes de imprimir, veja se realmente é necessá
Re: [FUG-BR] Acesso ao disco em vmware
e pra remover: 0.238 3.642s 3:44.30 1.7% Em 19 de maio de 2012 02:11, Welinaldo Lopes Nascimento < welina...@bsd.com.br> escreveu: > Ari, fiz o teste aqui no meu e ficou o seguinte: > > 7.088u 19.307s 13:12.91 3.3% > > > > > > Em 18 de maio de 2012 18:37, Ari Arantes Filho escreveu: > > Testei com o disco sem o thinprovisioning: >> >> # time tar xzf ports.tar.gz >> >> real16m8.904s >> >> mesma coisa, péssima performance. >> >> >> >> Em 18 de maio de 2012 17:17, Welinaldo Lopes Nascimento >> escreveu: >> > Beleza Ari, vamos ficar aguardando o resultado... >> > Amanhã vou fazer o mesmo e posto aqui também o resultado. >> > >> > Em 18 de maio de 2012 17:08, Ari Arantes Filho >> escreveu: >> > >> >> Vou reinstalar um FreeBSD 9 e utilizar um disco sem o thinprovisioning >> >> e reporto aqui na lista os resultados. >> >> >> >> Em 18 de maio de 2012 17:01, Rafael Henrique Faria >> >> escreveu: >> >> > 2012/5/18 Ari Arantes Filho >> >> > >> >> >> 1) sempre rodo o tar xzf ports.tar.gz e depois rm -rf ports, ou >> seja, >> >> >> libero o espaço e teoricamente o vmware não precisará aumentar >> >> >> novamente >> >> >> >> >> > >> >> > Eu posso estar errado, os mais experientes neste caso que me >> corrijam, >> >> mas >> >> > o UFS2 em uso no caso do FreeBSD não faz isso que você está >> imaginando. >> >> > >> >> > Quando você descompacta a primeira vez o ports.tar.gz, o UFS2 vai >> alocar >> >> o >> >> > espaço para o mesmo. E quando você apaga o mesmo, apesar do espaço >> ficar >> >> > "livre", o UFS2 não apaga o conteũdo do disco. E uma nova gravação, >> não >> >> irá >> >> > utilizar o espaço liberado, mas sim um espaço livre "virgem". O >> espaço >> >> > liberado somente será utilizando quando o disco não tiver mais >> espaços >> >> > livres. >> >> > >> >> > Ao utilizar recursos como este em HDs reais, o file system tem uma >> >> melhora >> >> > de performance, pois não precisa ficar apagando o disco... ele vai >> usando >> >> > espaços livres até que realmente seja necessário uma limpeza do file >> >> system >> >> > por ter acabado o espaço livre. >> >> > >> >> > Ultimamente percebi que após algum tempo, algumas horas, o espaço >> acaba >> >> > sendo liberado para uso... então acredito que tenha sido feita uma >> >> > alteração para algum processo de varredura ir liberando o espaço de >> tempo >> >> > em tempo.. mas isso não é em tempo real. >> >> > >> >> > Um exemplo prático disso: >> >> > >> >> > - esgote o espaço em disco com arquivos grandes. >> >> > - apague um dos arquivos grandes. >> >> > - o espaço não será liberado imediatamente... o disco vai continuar >> >> > reclamando que não tem espaço livre o suficiente. >> >> > >> >> > Normalmente isso não apresenta grandes problemas... pois um bom >> >> > administrador nunca irá deixar esgotar o espaço em disco. >> >> > >> >> > Porém, no caso do thinprovisioning isso é um problema. Pois a cada >> nova >> >> > gravação ele vai precisar requisitar do HOST um novo espaço em >> disco. O >> >> que >> >> > acaba ficando lendo. >> >> > >> >> > Eu sinceramente evito usar thinprovisioning em servidores de >> >> virtualização, >> >> > tanto por causa deste problema, quanto pelo efeito surpresa, de você >> >> alocar >> >> > 10 HDs de 1TB em um volume de 7TB, e acontecer de os 10 HDs >> precisaram >> >> usar >> >> > os 1TB oferecidos para o mesmo. Claro que é um exemplo, na prática >> >> teremos >> >> > 40 máquinas com HDs de tamanhos variados, que se tornará difícil >> ficar >> >> > acompanhando o crescimento, e o tamanho configurado para cada uma no >> >> > momento da crianção da máquina. >> >> > >> >> > -- >> >> > Rafael Henrique da Silva Faria >> >> > - >> >> > Histórico: http://www.fug.com.br/historico/html/freebsd/ >> >> > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >> >> - >> >> Histórico: http://www.fug.com.br/historico/html/freebsd/ >> >> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >> >> >> > >> > >> > >> > -- >> > .:: Welinaldo L N >> > .:: Estudante de Desenvolvimento de Sistemas >> > .:: FreeBSD Community Member #BSD/OS >> > .:: Antes de imprimir, veja se realmente é necessário! >> > .ılı..ılı. >> > - >> > Histórico: http://www.fug.com.br/historico/html/freebsd/ >> > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >> - >> Histórico: http://www.fug.com.br/historico/html/freebsd/ >> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >> > > > > -- > .:: Welinaldo L N > .:: Estudante de Desenvolvimento de Sistemas > .:: FreeBSD Community Member #BSD/OS > .:: Antes de imprimir, veja se realmente é necessário! > .ılı..ılı. > > -- .:: Welinaldo L N .:: Estudante de Desenvolvimento de Sistemas .:: FreeBSD Community Member #BSD/OS .:: Antes de imprimir, veja se realmente é necessário! .ılı..ılı. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lis
Re: [FUG-BR] Acesso ao disco em vmware
Ari, fiz o teste aqui no meu e ficou o seguinte: 7.088u 19.307s 13:12.91 3.3% Em 18 de maio de 2012 18:37, Ari Arantes Filho escreveu: > Testei com o disco sem o thinprovisioning: > > # time tar xzf ports.tar.gz > > real16m8.904s > > mesma coisa, péssima performance. > > > > Em 18 de maio de 2012 17:17, Welinaldo Lopes Nascimento > escreveu: > > Beleza Ari, vamos ficar aguardando o resultado... > > Amanhã vou fazer o mesmo e posto aqui também o resultado. > > > > Em 18 de maio de 2012 17:08, Ari Arantes Filho escreveu: > > > >> Vou reinstalar um FreeBSD 9 e utilizar um disco sem o thinprovisioning > >> e reporto aqui na lista os resultados. > >> > >> Em 18 de maio de 2012 17:01, Rafael Henrique Faria > >> escreveu: > >> > 2012/5/18 Ari Arantes Filho > >> > > >> >> 1) sempre rodo o tar xzf ports.tar.gz e depois rm -rf ports, ou seja, > >> >> libero o espaço e teoricamente o vmware não precisará aumentar > >> >> novamente > >> >> > >> > > >> > Eu posso estar errado, os mais experientes neste caso que me corrijam, > >> mas > >> > o UFS2 em uso no caso do FreeBSD não faz isso que você está > imaginando. > >> > > >> > Quando você descompacta a primeira vez o ports.tar.gz, o UFS2 vai > alocar > >> o > >> > espaço para o mesmo. E quando você apaga o mesmo, apesar do espaço > ficar > >> > "livre", o UFS2 não apaga o conteũdo do disco. E uma nova gravação, > não > >> irá > >> > utilizar o espaço liberado, mas sim um espaço livre "virgem". O espaço > >> > liberado somente será utilizando quando o disco não tiver mais espaços > >> > livres. > >> > > >> > Ao utilizar recursos como este em HDs reais, o file system tem uma > >> melhora > >> > de performance, pois não precisa ficar apagando o disco... ele vai > usando > >> > espaços livres até que realmente seja necessário uma limpeza do file > >> system > >> > por ter acabado o espaço livre. > >> > > >> > Ultimamente percebi que após algum tempo, algumas horas, o espaço > acaba > >> > sendo liberado para uso... então acredito que tenha sido feita uma > >> > alteração para algum processo de varredura ir liberando o espaço de > tempo > >> > em tempo.. mas isso não é em tempo real. > >> > > >> > Um exemplo prático disso: > >> > > >> > - esgote o espaço em disco com arquivos grandes. > >> > - apague um dos arquivos grandes. > >> > - o espaço não será liberado imediatamente... o disco vai continuar > >> > reclamando que não tem espaço livre o suficiente. > >> > > >> > Normalmente isso não apresenta grandes problemas... pois um bom > >> > administrador nunca irá deixar esgotar o espaço em disco. > >> > > >> > Porém, no caso do thinprovisioning isso é um problema. Pois a cada > nova > >> > gravação ele vai precisar requisitar do HOST um novo espaço em disco. > O > >> que > >> > acaba ficando lendo. > >> > > >> > Eu sinceramente evito usar thinprovisioning em servidores de > >> virtualização, > >> > tanto por causa deste problema, quanto pelo efeito surpresa, de você > >> alocar > >> > 10 HDs de 1TB em um volume de 7TB, e acontecer de os 10 HDs precisaram > >> usar > >> > os 1TB oferecidos para o mesmo. Claro que é um exemplo, na prática > >> teremos > >> > 40 máquinas com HDs de tamanhos variados, que se tornará difícil ficar > >> > acompanhando o crescimento, e o tamanho configurado para cada uma no > >> > momento da crianção da máquina. > >> > > >> > -- > >> > Rafael Henrique da Silva Faria > >> > - > >> > Histórico: http://www.fug.com.br/historico/html/freebsd/ > >> > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > >> - > >> Histórico: http://www.fug.com.br/historico/html/freebsd/ > >> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > >> > > > > > > > > -- > > .:: Welinaldo L N > > .:: Estudante de Desenvolvimento de Sistemas > > .:: FreeBSD Community Member #BSD/OS > > .:: Antes de imprimir, veja se realmente é necessário! > > .ılı..ılı. > > - > > Histórico: http://www.fug.com.br/historico/html/freebsd/ > > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > -- .:: Welinaldo L N .:: Estudante de Desenvolvimento de Sistemas .:: FreeBSD Community Member #BSD/OS .:: Antes de imprimir, veja se realmente é necessário! .ılı..ılı. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Acesso ao disco em vmware
Testei com o disco sem o thinprovisioning: # time tar xzf ports.tar.gz real16m8.904s mesma coisa, péssima performance. Em 18 de maio de 2012 17:17, Welinaldo Lopes Nascimento escreveu: > Beleza Ari, vamos ficar aguardando o resultado... > Amanhã vou fazer o mesmo e posto aqui também o resultado. > > Em 18 de maio de 2012 17:08, Ari Arantes Filho escreveu: > >> Vou reinstalar um FreeBSD 9 e utilizar um disco sem o thinprovisioning >> e reporto aqui na lista os resultados. >> >> Em 18 de maio de 2012 17:01, Rafael Henrique Faria >> escreveu: >> > 2012/5/18 Ari Arantes Filho >> > >> >> 1) sempre rodo o tar xzf ports.tar.gz e depois rm -rf ports, ou seja, >> >> libero o espaço e teoricamente o vmware não precisará aumentar >> >> novamente >> >> >> > >> > Eu posso estar errado, os mais experientes neste caso que me corrijam, >> mas >> > o UFS2 em uso no caso do FreeBSD não faz isso que você está imaginando. >> > >> > Quando você descompacta a primeira vez o ports.tar.gz, o UFS2 vai alocar >> o >> > espaço para o mesmo. E quando você apaga o mesmo, apesar do espaço ficar >> > "livre", o UFS2 não apaga o conteũdo do disco. E uma nova gravação, não >> irá >> > utilizar o espaço liberado, mas sim um espaço livre "virgem". O espaço >> > liberado somente será utilizando quando o disco não tiver mais espaços >> > livres. >> > >> > Ao utilizar recursos como este em HDs reais, o file system tem uma >> melhora >> > de performance, pois não precisa ficar apagando o disco... ele vai usando >> > espaços livres até que realmente seja necessário uma limpeza do file >> system >> > por ter acabado o espaço livre. >> > >> > Ultimamente percebi que após algum tempo, algumas horas, o espaço acaba >> > sendo liberado para uso... então acredito que tenha sido feita uma >> > alteração para algum processo de varredura ir liberando o espaço de tempo >> > em tempo.. mas isso não é em tempo real. >> > >> > Um exemplo prático disso: >> > >> > - esgote o espaço em disco com arquivos grandes. >> > - apague um dos arquivos grandes. >> > - o espaço não será liberado imediatamente... o disco vai continuar >> > reclamando que não tem espaço livre o suficiente. >> > >> > Normalmente isso não apresenta grandes problemas... pois um bom >> > administrador nunca irá deixar esgotar o espaço em disco. >> > >> > Porém, no caso do thinprovisioning isso é um problema. Pois a cada nova >> > gravação ele vai precisar requisitar do HOST um novo espaço em disco. O >> que >> > acaba ficando lendo. >> > >> > Eu sinceramente evito usar thinprovisioning em servidores de >> virtualização, >> > tanto por causa deste problema, quanto pelo efeito surpresa, de você >> alocar >> > 10 HDs de 1TB em um volume de 7TB, e acontecer de os 10 HDs precisaram >> usar >> > os 1TB oferecidos para o mesmo. Claro que é um exemplo, na prática >> teremos >> > 40 máquinas com HDs de tamanhos variados, que se tornará difícil ficar >> > acompanhando o crescimento, e o tamanho configurado para cada uma no >> > momento da crianção da máquina. >> > >> > -- >> > Rafael Henrique da Silva Faria >> > - >> > Histórico: http://www.fug.com.br/historico/html/freebsd/ >> > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >> - >> Histórico: http://www.fug.com.br/historico/html/freebsd/ >> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >> > > > > -- > .:: Welinaldo L N > .:: Estudante de Desenvolvimento de Sistemas > .:: FreeBSD Community Member #BSD/OS > .:: Antes de imprimir, veja se realmente é necessário! > .ılı..ılı. > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Acesso ao disco em vmware
Beleza Ari, vamos ficar aguardando o resultado... Amanhã vou fazer o mesmo e posto aqui também o resultado. Em 18 de maio de 2012 17:08, Ari Arantes Filho escreveu: > Vou reinstalar um FreeBSD 9 e utilizar um disco sem o thinprovisioning > e reporto aqui na lista os resultados. > > Em 18 de maio de 2012 17:01, Rafael Henrique Faria > escreveu: > > 2012/5/18 Ari Arantes Filho > > > >> 1) sempre rodo o tar xzf ports.tar.gz e depois rm -rf ports, ou seja, > >> libero o espaço e teoricamente o vmware não precisará aumentar > >> novamente > >> > > > > Eu posso estar errado, os mais experientes neste caso que me corrijam, > mas > > o UFS2 em uso no caso do FreeBSD não faz isso que você está imaginando. > > > > Quando você descompacta a primeira vez o ports.tar.gz, o UFS2 vai alocar > o > > espaço para o mesmo. E quando você apaga o mesmo, apesar do espaço ficar > > "livre", o UFS2 não apaga o conteũdo do disco. E uma nova gravação, não > irá > > utilizar o espaço liberado, mas sim um espaço livre "virgem". O espaço > > liberado somente será utilizando quando o disco não tiver mais espaços > > livres. > > > > Ao utilizar recursos como este em HDs reais, o file system tem uma > melhora > > de performance, pois não precisa ficar apagando o disco... ele vai usando > > espaços livres até que realmente seja necessário uma limpeza do file > system > > por ter acabado o espaço livre. > > > > Ultimamente percebi que após algum tempo, algumas horas, o espaço acaba > > sendo liberado para uso... então acredito que tenha sido feita uma > > alteração para algum processo de varredura ir liberando o espaço de tempo > > em tempo.. mas isso não é em tempo real. > > > > Um exemplo prático disso: > > > > - esgote o espaço em disco com arquivos grandes. > > - apague um dos arquivos grandes. > > - o espaço não será liberado imediatamente... o disco vai continuar > > reclamando que não tem espaço livre o suficiente. > > > > Normalmente isso não apresenta grandes problemas... pois um bom > > administrador nunca irá deixar esgotar o espaço em disco. > > > > Porém, no caso do thinprovisioning isso é um problema. Pois a cada nova > > gravação ele vai precisar requisitar do HOST um novo espaço em disco. O > que > > acaba ficando lendo. > > > > Eu sinceramente evito usar thinprovisioning em servidores de > virtualização, > > tanto por causa deste problema, quanto pelo efeito surpresa, de você > alocar > > 10 HDs de 1TB em um volume de 7TB, e acontecer de os 10 HDs precisaram > usar > > os 1TB oferecidos para o mesmo. Claro que é um exemplo, na prática > teremos > > 40 máquinas com HDs de tamanhos variados, que se tornará difícil ficar > > acompanhando o crescimento, e o tamanho configurado para cada uma no > > momento da crianção da máquina. > > > > -- > > Rafael Henrique da Silva Faria > > - > > Histórico: http://www.fug.com.br/historico/html/freebsd/ > > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > -- .:: Welinaldo L N .:: Estudante de Desenvolvimento de Sistemas .:: FreeBSD Community Member #BSD/OS .:: Antes de imprimir, veja se realmente é necessário! .ılı..ılı. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Acesso ao disco em vmware
Vou reinstalar um FreeBSD 9 e utilizar um disco sem o thinprovisioning e reporto aqui na lista os resultados. Em 18 de maio de 2012 17:01, Rafael Henrique Faria escreveu: > 2012/5/18 Ari Arantes Filho > >> 1) sempre rodo o tar xzf ports.tar.gz e depois rm -rf ports, ou seja, >> libero o espaço e teoricamente o vmware não precisará aumentar >> novamente >> > > Eu posso estar errado, os mais experientes neste caso que me corrijam, mas > o UFS2 em uso no caso do FreeBSD não faz isso que você está imaginando. > > Quando você descompacta a primeira vez o ports.tar.gz, o UFS2 vai alocar o > espaço para o mesmo. E quando você apaga o mesmo, apesar do espaço ficar > "livre", o UFS2 não apaga o conteũdo do disco. E uma nova gravação, não irá > utilizar o espaço liberado, mas sim um espaço livre "virgem". O espaço > liberado somente será utilizando quando o disco não tiver mais espaços > livres. > > Ao utilizar recursos como este em HDs reais, o file system tem uma melhora > de performance, pois não precisa ficar apagando o disco... ele vai usando > espaços livres até que realmente seja necessário uma limpeza do file system > por ter acabado o espaço livre. > > Ultimamente percebi que após algum tempo, algumas horas, o espaço acaba > sendo liberado para uso... então acredito que tenha sido feita uma > alteração para algum processo de varredura ir liberando o espaço de tempo > em tempo.. mas isso não é em tempo real. > > Um exemplo prático disso: > > - esgote o espaço em disco com arquivos grandes. > - apague um dos arquivos grandes. > - o espaço não será liberado imediatamente... o disco vai continuar > reclamando que não tem espaço livre o suficiente. > > Normalmente isso não apresenta grandes problemas... pois um bom > administrador nunca irá deixar esgotar o espaço em disco. > > Porém, no caso do thinprovisioning isso é um problema. Pois a cada nova > gravação ele vai precisar requisitar do HOST um novo espaço em disco. O que > acaba ficando lendo. > > Eu sinceramente evito usar thinprovisioning em servidores de virtualização, > tanto por causa deste problema, quanto pelo efeito surpresa, de você alocar > 10 HDs de 1TB em um volume de 7TB, e acontecer de os 10 HDs precisaram usar > os 1TB oferecidos para o mesmo. Claro que é um exemplo, na prática teremos > 40 máquinas com HDs de tamanhos variados, que se tornará difícil ficar > acompanhando o crescimento, e o tamanho configurado para cada uma no > momento da crianção da máquina. > > -- > Rafael Henrique da Silva Faria > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Acesso ao disco em vmware
2012/5/18 Ari Arantes Filho > 1) sempre rodo o tar xzf ports.tar.gz e depois rm -rf ports, ou seja, > libero o espaço e teoricamente o vmware não precisará aumentar > novamente > Eu posso estar errado, os mais experientes neste caso que me corrijam, mas o UFS2 em uso no caso do FreeBSD não faz isso que você está imaginando. Quando você descompacta a primeira vez o ports.tar.gz, o UFS2 vai alocar o espaço para o mesmo. E quando você apaga o mesmo, apesar do espaço ficar "livre", o UFS2 não apaga o conteũdo do disco. E uma nova gravação, não irá utilizar o espaço liberado, mas sim um espaço livre "virgem". O espaço liberado somente será utilizando quando o disco não tiver mais espaços livres. Ao utilizar recursos como este em HDs reais, o file system tem uma melhora de performance, pois não precisa ficar apagando o disco... ele vai usando espaços livres até que realmente seja necessário uma limpeza do file system por ter acabado o espaço livre. Ultimamente percebi que após algum tempo, algumas horas, o espaço acaba sendo liberado para uso... então acredito que tenha sido feita uma alteração para algum processo de varredura ir liberando o espaço de tempo em tempo.. mas isso não é em tempo real. Um exemplo prático disso: - esgote o espaço em disco com arquivos grandes. - apague um dos arquivos grandes. - o espaço não será liberado imediatamente... o disco vai continuar reclamando que não tem espaço livre o suficiente. Normalmente isso não apresenta grandes problemas... pois um bom administrador nunca irá deixar esgotar o espaço em disco. Porém, no caso do thinprovisioning isso é um problema. Pois a cada nova gravação ele vai precisar requisitar do HOST um novo espaço em disco. O que acaba ficando lendo. Eu sinceramente evito usar thinprovisioning em servidores de virtualização, tanto por causa deste problema, quanto pelo efeito surpresa, de você alocar 10 HDs de 1TB em um volume de 7TB, e acontecer de os 10 HDs precisaram usar os 1TB oferecidos para o mesmo. Claro que é um exemplo, na prática teremos 40 máquinas com HDs de tamanhos variados, que se tornará difícil ficar acompanhando o crescimento, e o tamanho configurado para cada uma no momento da crianção da máquina. -- Rafael Henrique da Silva Faria - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Acesso ao disco em vmware
Realmente, como o Pedro disse, notei também em algum momento erro de IO em meus testes... Em 18 de maio de 2012 16:41, Pedro Madsen escreveu: > Ari, > > pode ser no suporte ao SO mesmo. No caso do Hiper-V, o Linux funciona (mais > lento mas funciona) e o FreeBSD tem uma performance tão ruim que fica > acusando erro de IO como se o disco tivesse inacessível. Não é a toa que > dou preferencia para usar Jails ao invés da virtualização em muitos casos, > o suporte ao FreeBSD por parte dos virtualizadores não é prioritário. > > Em 18 de maio de 2012 16:36, Ari Arantes Filho escreveu: > > > Ainda que tenha esse HD dinâmico, conhecia como thinprovisioning, > > concordo que ele cresce qdo precisa e nesse momento fica mais lento, > > mas 2 coisas: > > 1) sempre rodo o tar xzf ports.tar.gz e depois rm -rf ports, ou seja, > > libero o espaço e teoricamente o vmware não precisará aumentar > > novamente > > 2) os 2 servidores (freebsd e ubuntu) estão idênticos, ou seja, se tem > > esse problema de crescer o disco dinamicamente, tem para os 2 > > servidores. > > > > O que quero descobrir é como deixar o BSD mais rápido. Onde podemos > mexer. > > > > > > Em 18 de maio de 2012 16:31, Pedro Madsen escreveu: > > > Agora que o Hiper-V vai suportar FreeBSD, isso deve melhorar... mas > como > > > disse noutro post, é uma criança carregando um adulto no colo. > > > > > > Em 18 de maio de 2012 16:30, Welinaldo Lopes Nascimento < > > > welina...@bsd.com.br> escreveu: > > > > > >> Interessante a observação do Pedro Madsen, e inclusive vou checar > > isto... > > >> Sempre usei esta configuração para expandir dinamicamente e também > notei > > >> lentidão ao realizar os testes informado pelo Ari :-) > > >> > > >> Em 18 de maio de 2012 16:16, Pedro Madsen > escreveu: > > >> > > >> > Pelo proprio virtualizador, veja se o espaço do disco já foi > > préa-locado > > >> ou > > >> > se ele irá expandir dinamicamente conforme o uso. No caso do > Hiper-V, > > >> isso > > >> > demora pois após o FreeBSD solicitar espaço no disco, o tempo de > > repasse > > >> > para o virtualizador e a resposta da alocação do próprio Windows > gera > > uma > > >> > latência alta demais que engargala os processos da máquina virtual. > No > > >> caso > > >> > do espaço pré-alocado, o virtualizador não demora a responder a > > >> > solicitação. > > >> > > > >> > Em 18 de maio de 2012 08:02, Ari Arantes Filho > > escreveu: > > >> > > > >> > > Como eu vejo se está dinâmico ou não? No vmware ou no SO? > > >> > > > > >> > > 2 duas VMs: > > >> > > SCSI controller --> LSI Logic Parallel > > >> > > SCSI Bus Sharing --> None > > >> > > > > >> > > HD1 --> Virtual --> SCSI (0:0) > > >> > > > > >> > > Ambos são thinprovisiniong. > > >> > > > > >> > > Mount e fdisk no FreeBSD: > > >> > > # mount > > >> > > /dev/da0p2 on / (ufs, local, journaled soft-updates) > > >> > > devfs on /dev (devfs, local, multilabel) > > >> > > > > >> > > # fdisk /dev/da0 > > >> > > *** Working on device /dev/da0 *** > > >> > > parameters extracted from in-core disklabel are: > > >> > > cylinders=1305 heads=255 sectors/track=63 (16065 blks/cyl) > > >> > > > > >> > > Figures below won't work with BIOS for partitions not in cyl 1 > > >> > > parameters to be used for BIOS calculations are: > > >> > > cylinders=1305 heads=255 sectors/track=63 (16065 blks/cyl) > > >> > > > > >> > > Media sector size is 512 > > >> > > Warning: BIOS sector numbering starts with sector 1 > > >> > > Information from DOS bootblock is: > > >> > > The data for partition 1 is: > > >> > > sysid 238 (0xee),(EFI GPT) > > >> > >start 1, size 20971519 (10239 Meg), flag 80 (active) > > >> > >beg: cyl 0/ head 0/ sector 2; > > >> > >end: cyl 1023/ head 255/ sector 63 > > >> > > The data for partition 2 is: > > >> > > > > >> > > The data for partition 3 is: > > >> > > > > >> > > The data for partition 4 is: > > >> > > > > >> > > > > >> > > > > >> > > Mount e fdisk no ubuntu: > > >> > > # mount > > >> > > /dev/mapper/coringa-root on / type ext4 (rw,errors=remount-ro) > > >> > > proc on /proc type proc (rw,noexec,nosuid,nodev) > > >> > > none on /sys type sysfs (rw,noexec,nosuid,nodev) > > >> > > none on /sys/fs/fuse/connections type fusectl (rw) > > >> > > none on /sys/kernel/debug type debugfs (rw) > > >> > > none on /sys/kernel/security type securityfs (rw) > > >> > > none on /dev type devtmpfs (rw,mode=0755) > > >> > > none on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620) > > >> > > none on /dev/shm type tmpfs (rw,nosuid,nodev) > > >> > > none on /var/run type tmpfs (rw,nosuid,mode=0755) > > >> > > none on /var/lock type tmpfs (rw,noexec,nosuid,nodev) > > >> > > none on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) > > >> > > /dev/sda1 on /boot type ext2 (rw) > > >> > > > > >> > > # fdisk -l > > >> > > > > >> > > Disk /dev/sda: 10.7 GB, 10737418240 bytes > > >> > > 255 heads, 63 sectors/track, 1305 cylinders > > >> > > Units = cylinders of 16065 * 512 = 8225280 bytes > > >> > > Sector si
Re: [FUG-BR] Acesso ao disco em vmware
Ari, ontem realizei estes mesmos testes utilizando quase o mesmo cenário.. também observei uma demora imensa ao descompactar e remover este arquivo. Em 18 de maio de 2012 16:36, Ari Arantes Filho escreveu: > Ainda que tenha esse HD dinâmico, conhecia como thinprovisioning, > concordo que ele cresce qdo precisa e nesse momento fica mais lento, > mas 2 coisas: > 1) sempre rodo o tar xzf ports.tar.gz e depois rm -rf ports, ou seja, > libero o espaço e teoricamente o vmware não precisará aumentar > novamente > 2) os 2 servidores (freebsd e ubuntu) estão idênticos, ou seja, se tem > esse problema de crescer o disco dinamicamente, tem para os 2 > servidores. > > O que quero descobrir é como deixar o BSD mais rápido. Onde podemos mexer. > > > Em 18 de maio de 2012 16:31, Pedro Madsen escreveu: > > Agora que o Hiper-V vai suportar FreeBSD, isso deve melhorar... mas como > > disse noutro post, é uma criança carregando um adulto no colo. > > > > Em 18 de maio de 2012 16:30, Welinaldo Lopes Nascimento < > > welina...@bsd.com.br> escreveu: > > > >> Interessante a observação do Pedro Madsen, e inclusive vou checar > isto... > >> Sempre usei esta configuração para expandir dinamicamente e também notei > >> lentidão ao realizar os testes informado pelo Ari :-) > >> > >> Em 18 de maio de 2012 16:16, Pedro Madsen escreveu: > >> > >> > Pelo proprio virtualizador, veja se o espaço do disco já foi > préa-locado > >> ou > >> > se ele irá expandir dinamicamente conforme o uso. No caso do Hiper-V, > >> isso > >> > demora pois após o FreeBSD solicitar espaço no disco, o tempo de > repasse > >> > para o virtualizador e a resposta da alocação do próprio Windows gera > uma > >> > latência alta demais que engargala os processos da máquina virtual. No > >> caso > >> > do espaço pré-alocado, o virtualizador não demora a responder a > >> > solicitação. > >> > > >> > Em 18 de maio de 2012 08:02, Ari Arantes Filho > escreveu: > >> > > >> > > Como eu vejo se está dinâmico ou não? No vmware ou no SO? > >> > > > >> > > 2 duas VMs: > >> > > SCSI controller --> LSI Logic Parallel > >> > > SCSI Bus Sharing --> None > >> > > > >> > > HD1 --> Virtual --> SCSI (0:0) > >> > > > >> > > Ambos são thinprovisiniong. > >> > > > >> > > Mount e fdisk no FreeBSD: > >> > > # mount > >> > > /dev/da0p2 on / (ufs, local, journaled soft-updates) > >> > > devfs on /dev (devfs, local, multilabel) > >> > > > >> > > # fdisk /dev/da0 > >> > > *** Working on device /dev/da0 *** > >> > > parameters extracted from in-core disklabel are: > >> > > cylinders=1305 heads=255 sectors/track=63 (16065 blks/cyl) > >> > > > >> > > Figures below won't work with BIOS for partitions not in cyl 1 > >> > > parameters to be used for BIOS calculations are: > >> > > cylinders=1305 heads=255 sectors/track=63 (16065 blks/cyl) > >> > > > >> > > Media sector size is 512 > >> > > Warning: BIOS sector numbering starts with sector 1 > >> > > Information from DOS bootblock is: > >> > > The data for partition 1 is: > >> > > sysid 238 (0xee),(EFI GPT) > >> > >start 1, size 20971519 (10239 Meg), flag 80 (active) > >> > >beg: cyl 0/ head 0/ sector 2; > >> > >end: cyl 1023/ head 255/ sector 63 > >> > > The data for partition 2 is: > >> > > > >> > > The data for partition 3 is: > >> > > > >> > > The data for partition 4 is: > >> > > > >> > > > >> > > > >> > > Mount e fdisk no ubuntu: > >> > > # mount > >> > > /dev/mapper/coringa-root on / type ext4 (rw,errors=remount-ro) > >> > > proc on /proc type proc (rw,noexec,nosuid,nodev) > >> > > none on /sys type sysfs (rw,noexec,nosuid,nodev) > >> > > none on /sys/fs/fuse/connections type fusectl (rw) > >> > > none on /sys/kernel/debug type debugfs (rw) > >> > > none on /sys/kernel/security type securityfs (rw) > >> > > none on /dev type devtmpfs (rw,mode=0755) > >> > > none on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620) > >> > > none on /dev/shm type tmpfs (rw,nosuid,nodev) > >> > > none on /var/run type tmpfs (rw,nosuid,mode=0755) > >> > > none on /var/lock type tmpfs (rw,noexec,nosuid,nodev) > >> > > none on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) > >> > > /dev/sda1 on /boot type ext2 (rw) > >> > > > >> > > # fdisk -l > >> > > > >> > > Disk /dev/sda: 10.7 GB, 10737418240 bytes > >> > > 255 heads, 63 sectors/track, 1305 cylinders > >> > > Units = cylinders of 16065 * 512 = 8225280 bytes > >> > > Sector size (logical/physical): 512 bytes / 512 bytes > >> > > I/O size (minimum/optimal): 512 bytes / 512 bytes > >> > > Disk identifier: 0x0007fbc2 > >> > > > >> > > Device Boot Start End Blocks Id System > >> > > /dev/sda1 * 1 32 248832 83 Linux > >> > > Partition 1 does not end on cylinder boundary. > >> > > /dev/sda2 321306102338575 Extended > >> > > /dev/sda5 32130610233856 8e Linux LVM > >> > > > >> > > > >> > > > >> > > Em 18 de maio de 2012 00:04, Pedro Madsen > escreveu: > >> > > > O volume e
Re: [FUG-BR] Acesso ao disco em vmware
Ari, pode ser no suporte ao SO mesmo. No caso do Hiper-V, o Linux funciona (mais lento mas funciona) e o FreeBSD tem uma performance tão ruim que fica acusando erro de IO como se o disco tivesse inacessível. Não é a toa que dou preferencia para usar Jails ao invés da virtualização em muitos casos, o suporte ao FreeBSD por parte dos virtualizadores não é prioritário. Em 18 de maio de 2012 16:36, Ari Arantes Filho escreveu: > Ainda que tenha esse HD dinâmico, conhecia como thinprovisioning, > concordo que ele cresce qdo precisa e nesse momento fica mais lento, > mas 2 coisas: > 1) sempre rodo o tar xzf ports.tar.gz e depois rm -rf ports, ou seja, > libero o espaço e teoricamente o vmware não precisará aumentar > novamente > 2) os 2 servidores (freebsd e ubuntu) estão idênticos, ou seja, se tem > esse problema de crescer o disco dinamicamente, tem para os 2 > servidores. > > O que quero descobrir é como deixar o BSD mais rápido. Onde podemos mexer. > > > Em 18 de maio de 2012 16:31, Pedro Madsen escreveu: > > Agora que o Hiper-V vai suportar FreeBSD, isso deve melhorar... mas como > > disse noutro post, é uma criança carregando um adulto no colo. > > > > Em 18 de maio de 2012 16:30, Welinaldo Lopes Nascimento < > > welina...@bsd.com.br> escreveu: > > > >> Interessante a observação do Pedro Madsen, e inclusive vou checar > isto... > >> Sempre usei esta configuração para expandir dinamicamente e também notei > >> lentidão ao realizar os testes informado pelo Ari :-) > >> > >> Em 18 de maio de 2012 16:16, Pedro Madsen escreveu: > >> > >> > Pelo proprio virtualizador, veja se o espaço do disco já foi > préa-locado > >> ou > >> > se ele irá expandir dinamicamente conforme o uso. No caso do Hiper-V, > >> isso > >> > demora pois após o FreeBSD solicitar espaço no disco, o tempo de > repasse > >> > para o virtualizador e a resposta da alocação do próprio Windows gera > uma > >> > latência alta demais que engargala os processos da máquina virtual. No > >> caso > >> > do espaço pré-alocado, o virtualizador não demora a responder a > >> > solicitação. > >> > > >> > Em 18 de maio de 2012 08:02, Ari Arantes Filho > escreveu: > >> > > >> > > Como eu vejo se está dinâmico ou não? No vmware ou no SO? > >> > > > >> > > 2 duas VMs: > >> > > SCSI controller --> LSI Logic Parallel > >> > > SCSI Bus Sharing --> None > >> > > > >> > > HD1 --> Virtual --> SCSI (0:0) > >> > > > >> > > Ambos são thinprovisiniong. > >> > > > >> > > Mount e fdisk no FreeBSD: > >> > > # mount > >> > > /dev/da0p2 on / (ufs, local, journaled soft-updates) > >> > > devfs on /dev (devfs, local, multilabel) > >> > > > >> > > # fdisk /dev/da0 > >> > > *** Working on device /dev/da0 *** > >> > > parameters extracted from in-core disklabel are: > >> > > cylinders=1305 heads=255 sectors/track=63 (16065 blks/cyl) > >> > > > >> > > Figures below won't work with BIOS for partitions not in cyl 1 > >> > > parameters to be used for BIOS calculations are: > >> > > cylinders=1305 heads=255 sectors/track=63 (16065 blks/cyl) > >> > > > >> > > Media sector size is 512 > >> > > Warning: BIOS sector numbering starts with sector 1 > >> > > Information from DOS bootblock is: > >> > > The data for partition 1 is: > >> > > sysid 238 (0xee),(EFI GPT) > >> > >start 1, size 20971519 (10239 Meg), flag 80 (active) > >> > >beg: cyl 0/ head 0/ sector 2; > >> > >end: cyl 1023/ head 255/ sector 63 > >> > > The data for partition 2 is: > >> > > > >> > > The data for partition 3 is: > >> > > > >> > > The data for partition 4 is: > >> > > > >> > > > >> > > > >> > > Mount e fdisk no ubuntu: > >> > > # mount > >> > > /dev/mapper/coringa-root on / type ext4 (rw,errors=remount-ro) > >> > > proc on /proc type proc (rw,noexec,nosuid,nodev) > >> > > none on /sys type sysfs (rw,noexec,nosuid,nodev) > >> > > none on /sys/fs/fuse/connections type fusectl (rw) > >> > > none on /sys/kernel/debug type debugfs (rw) > >> > > none on /sys/kernel/security type securityfs (rw) > >> > > none on /dev type devtmpfs (rw,mode=0755) > >> > > none on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620) > >> > > none on /dev/shm type tmpfs (rw,nosuid,nodev) > >> > > none on /var/run type tmpfs (rw,nosuid,mode=0755) > >> > > none on /var/lock type tmpfs (rw,noexec,nosuid,nodev) > >> > > none on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) > >> > > /dev/sda1 on /boot type ext2 (rw) > >> > > > >> > > # fdisk -l > >> > > > >> > > Disk /dev/sda: 10.7 GB, 10737418240 bytes > >> > > 255 heads, 63 sectors/track, 1305 cylinders > >> > > Units = cylinders of 16065 * 512 = 8225280 bytes > >> > > Sector size (logical/physical): 512 bytes / 512 bytes > >> > > I/O size (minimum/optimal): 512 bytes / 512 bytes > >> > > Disk identifier: 0x0007fbc2 > >> > > > >> > > Device Boot Start End Blocks Id System > >> > > /dev/sda1 * 1 32 248832 83 Linux > >> > > Partition 1 does not end on cylinder boundary. > >> > > /dev/sda2 32
Re: [FUG-BR] Acesso ao disco em vmware
Ainda que tenha esse HD dinâmico, conhecia como thinprovisioning, concordo que ele cresce qdo precisa e nesse momento fica mais lento, mas 2 coisas: 1) sempre rodo o tar xzf ports.tar.gz e depois rm -rf ports, ou seja, libero o espaço e teoricamente o vmware não precisará aumentar novamente 2) os 2 servidores (freebsd e ubuntu) estão idênticos, ou seja, se tem esse problema de crescer o disco dinamicamente, tem para os 2 servidores. O que quero descobrir é como deixar o BSD mais rápido. Onde podemos mexer. Em 18 de maio de 2012 16:31, Pedro Madsen escreveu: > Agora que o Hiper-V vai suportar FreeBSD, isso deve melhorar... mas como > disse noutro post, é uma criança carregando um adulto no colo. > > Em 18 de maio de 2012 16:30, Welinaldo Lopes Nascimento < > welina...@bsd.com.br> escreveu: > >> Interessante a observação do Pedro Madsen, e inclusive vou checar isto... >> Sempre usei esta configuração para expandir dinamicamente e também notei >> lentidão ao realizar os testes informado pelo Ari :-) >> >> Em 18 de maio de 2012 16:16, Pedro Madsen escreveu: >> >> > Pelo proprio virtualizador, veja se o espaço do disco já foi préa-locado >> ou >> > se ele irá expandir dinamicamente conforme o uso. No caso do Hiper-V, >> isso >> > demora pois após o FreeBSD solicitar espaço no disco, o tempo de repasse >> > para o virtualizador e a resposta da alocação do próprio Windows gera uma >> > latência alta demais que engargala os processos da máquina virtual. No >> caso >> > do espaço pré-alocado, o virtualizador não demora a responder a >> > solicitação. >> > >> > Em 18 de maio de 2012 08:02, Ari Arantes Filho escreveu: >> > >> > > Como eu vejo se está dinâmico ou não? No vmware ou no SO? >> > > >> > > 2 duas VMs: >> > > SCSI controller --> LSI Logic Parallel >> > > SCSI Bus Sharing --> None >> > > >> > > HD1 --> Virtual --> SCSI (0:0) >> > > >> > > Ambos são thinprovisiniong. >> > > >> > > Mount e fdisk no FreeBSD: >> > > # mount >> > > /dev/da0p2 on / (ufs, local, journaled soft-updates) >> > > devfs on /dev (devfs, local, multilabel) >> > > >> > > # fdisk /dev/da0 >> > > *** Working on device /dev/da0 *** >> > > parameters extracted from in-core disklabel are: >> > > cylinders=1305 heads=255 sectors/track=63 (16065 blks/cyl) >> > > >> > > Figures below won't work with BIOS for partitions not in cyl 1 >> > > parameters to be used for BIOS calculations are: >> > > cylinders=1305 heads=255 sectors/track=63 (16065 blks/cyl) >> > > >> > > Media sector size is 512 >> > > Warning: BIOS sector numbering starts with sector 1 >> > > Information from DOS bootblock is: >> > > The data for partition 1 is: >> > > sysid 238 (0xee),(EFI GPT) >> > > start 1, size 20971519 (10239 Meg), flag 80 (active) >> > > beg: cyl 0/ head 0/ sector 2; >> > > end: cyl 1023/ head 255/ sector 63 >> > > The data for partition 2 is: >> > > >> > > The data for partition 3 is: >> > > >> > > The data for partition 4 is: >> > > >> > > >> > > >> > > Mount e fdisk no ubuntu: >> > > # mount >> > > /dev/mapper/coringa-root on / type ext4 (rw,errors=remount-ro) >> > > proc on /proc type proc (rw,noexec,nosuid,nodev) >> > > none on /sys type sysfs (rw,noexec,nosuid,nodev) >> > > none on /sys/fs/fuse/connections type fusectl (rw) >> > > none on /sys/kernel/debug type debugfs (rw) >> > > none on /sys/kernel/security type securityfs (rw) >> > > none on /dev type devtmpfs (rw,mode=0755) >> > > none on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620) >> > > none on /dev/shm type tmpfs (rw,nosuid,nodev) >> > > none on /var/run type tmpfs (rw,nosuid,mode=0755) >> > > none on /var/lock type tmpfs (rw,noexec,nosuid,nodev) >> > > none on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) >> > > /dev/sda1 on /boot type ext2 (rw) >> > > >> > > # fdisk -l >> > > >> > > Disk /dev/sda: 10.7 GB, 10737418240 bytes >> > > 255 heads, 63 sectors/track, 1305 cylinders >> > > Units = cylinders of 16065 * 512 = 8225280 bytes >> > > Sector size (logical/physical): 512 bytes / 512 bytes >> > > I/O size (minimum/optimal): 512 bytes / 512 bytes >> > > Disk identifier: 0x0007fbc2 >> > > >> > > Device Boot Start End Blocks Id System >> > > /dev/sda1 * 1 32 248832 83 Linux >> > > Partition 1 does not end on cylinder boundary. >> > > /dev/sda2 32 1306 10233857 5 Extended >> > > /dev/sda5 32 1306 10233856 8e Linux LVM >> > > >> > > >> > > >> > > Em 18 de maio de 2012 00:04, Pedro Madsen escreveu: >> > > > O volume está dinâmico ou estático? Já vi problemas assim com Hiper-V >> > com >> > > > volume dinâmico. >> > > > >> > > > Em 17 de maio de 2012 23:36, Paulo Henrique > > > >escreveu: >> > > > >> > > >> Em 17 de maio de 2012 21:19, Welinaldo Lopes Nascimento < >> > > >> welina...@bsd.com.br> escreveu: >> > > >> >> > > >> > Qual a configuração de hardware deste servidor? >> > > >> > >> > > >> > Em 17 de maio de 2012 18:56, Ari Arantes Filho >> > > escr
Re: [FUG-BR] Acesso ao disco em vmware
Agora que o Hiper-V vai suportar FreeBSD, isso deve melhorar... mas como disse noutro post, é uma criança carregando um adulto no colo. Em 18 de maio de 2012 16:30, Welinaldo Lopes Nascimento < welina...@bsd.com.br> escreveu: > Interessante a observação do Pedro Madsen, e inclusive vou checar isto... > Sempre usei esta configuração para expandir dinamicamente e também notei > lentidão ao realizar os testes informado pelo Ari :-) > > Em 18 de maio de 2012 16:16, Pedro Madsen escreveu: > > > Pelo proprio virtualizador, veja se o espaço do disco já foi préa-locado > ou > > se ele irá expandir dinamicamente conforme o uso. No caso do Hiper-V, > isso > > demora pois após o FreeBSD solicitar espaço no disco, o tempo de repasse > > para o virtualizador e a resposta da alocação do próprio Windows gera uma > > latência alta demais que engargala os processos da máquina virtual. No > caso > > do espaço pré-alocado, o virtualizador não demora a responder a > > solicitação. > > > > Em 18 de maio de 2012 08:02, Ari Arantes Filho escreveu: > > > > > Como eu vejo se está dinâmico ou não? No vmware ou no SO? > > > > > > 2 duas VMs: > > > SCSI controller --> LSI Logic Parallel > > > SCSI Bus Sharing --> None > > > > > > HD1 --> Virtual --> SCSI (0:0) > > > > > > Ambos são thinprovisiniong. > > > > > > Mount e fdisk no FreeBSD: > > > # mount > > > /dev/da0p2 on / (ufs, local, journaled soft-updates) > > > devfs on /dev (devfs, local, multilabel) > > > > > > # fdisk /dev/da0 > > > *** Working on device /dev/da0 *** > > > parameters extracted from in-core disklabel are: > > > cylinders=1305 heads=255 sectors/track=63 (16065 blks/cyl) > > > > > > Figures below won't work with BIOS for partitions not in cyl 1 > > > parameters to be used for BIOS calculations are: > > > cylinders=1305 heads=255 sectors/track=63 (16065 blks/cyl) > > > > > > Media sector size is 512 > > > Warning: BIOS sector numbering starts with sector 1 > > > Information from DOS bootblock is: > > > The data for partition 1 is: > > > sysid 238 (0xee),(EFI GPT) > > >start 1, size 20971519 (10239 Meg), flag 80 (active) > > >beg: cyl 0/ head 0/ sector 2; > > >end: cyl 1023/ head 255/ sector 63 > > > The data for partition 2 is: > > > > > > The data for partition 3 is: > > > > > > The data for partition 4 is: > > > > > > > > > > > > Mount e fdisk no ubuntu: > > > # mount > > > /dev/mapper/coringa-root on / type ext4 (rw,errors=remount-ro) > > > proc on /proc type proc (rw,noexec,nosuid,nodev) > > > none on /sys type sysfs (rw,noexec,nosuid,nodev) > > > none on /sys/fs/fuse/connections type fusectl (rw) > > > none on /sys/kernel/debug type debugfs (rw) > > > none on /sys/kernel/security type securityfs (rw) > > > none on /dev type devtmpfs (rw,mode=0755) > > > none on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620) > > > none on /dev/shm type tmpfs (rw,nosuid,nodev) > > > none on /var/run type tmpfs (rw,nosuid,mode=0755) > > > none on /var/lock type tmpfs (rw,noexec,nosuid,nodev) > > > none on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) > > > /dev/sda1 on /boot type ext2 (rw) > > > > > > # fdisk -l > > > > > > Disk /dev/sda: 10.7 GB, 10737418240 bytes > > > 255 heads, 63 sectors/track, 1305 cylinders > > > Units = cylinders of 16065 * 512 = 8225280 bytes > > > Sector size (logical/physical): 512 bytes / 512 bytes > > > I/O size (minimum/optimal): 512 bytes / 512 bytes > > > Disk identifier: 0x0007fbc2 > > > > > > Device Boot Start End Blocks Id System > > > /dev/sda1 * 1 32 248832 83 Linux > > > Partition 1 does not end on cylinder boundary. > > > /dev/sda2 321306102338575 Extended > > > /dev/sda5 32130610233856 8e Linux LVM > > > > > > > > > > > > Em 18 de maio de 2012 00:04, Pedro Madsen escreveu: > > > > O volume está dinâmico ou estático? Já vi problemas assim com Hiper-V > > com > > > > volume dinâmico. > > > > > > > > Em 17 de maio de 2012 23:36, Paulo Henrique > > >escreveu: > > > > > > > >> Em 17 de maio de 2012 21:19, Welinaldo Lopes Nascimento < > > > >> welina...@bsd.com.br> escreveu: > > > >> > > > >> > Qual a configuração de hardware deste servidor? > > > >> > > > > >> > Em 17 de maio de 2012 18:56, Ari Arantes Filho > > > escreveu: > > > >> > > > > >> > > SCSI controller 0 --> LSI Logic Parallel. A mesma utilizada no > > > Ubuntu. > > > >> > > Não mexi na configuração wizard do vmware. Escolhi FreeBSD 64 > > para o > > > >> > > BSD e Ubuntu 64 para ubuntu. > > > >> > > > > > >> > > > > > >> > > Em 17 de maio de 2012 14:46, Francisco Cardoso < > > frica...@bsd.com.br > > > > > > > >> > > escreveu: > > > >> > > > Em 17 de maio de 2012 11:58, Ari Arantes Filho > > > > >> > escreveu: > > > >> > > >> O servidor é um IBM3550M3. A controladora é a padrão. > > > >> > > >> > > > >> > > >> Também testei com um FreeBSD instalado no storage e não no > > disco > > > >> local > > > >> > > >> do vmware na 3550,
Re: [FUG-BR] Acesso ao disco em vmware
Interessante a observação do Pedro Madsen, e inclusive vou checar isto... Sempre usei esta configuração para expandir dinamicamente e também notei lentidão ao realizar os testes informado pelo Ari :-) Em 18 de maio de 2012 16:16, Pedro Madsen escreveu: > Pelo proprio virtualizador, veja se o espaço do disco já foi préa-locado ou > se ele irá expandir dinamicamente conforme o uso. No caso do Hiper-V, isso > demora pois após o FreeBSD solicitar espaço no disco, o tempo de repasse > para o virtualizador e a resposta da alocação do próprio Windows gera uma > latência alta demais que engargala os processos da máquina virtual. No caso > do espaço pré-alocado, o virtualizador não demora a responder a > solicitação. > > Em 18 de maio de 2012 08:02, Ari Arantes Filho escreveu: > > > Como eu vejo se está dinâmico ou não? No vmware ou no SO? > > > > 2 duas VMs: > > SCSI controller --> LSI Logic Parallel > > SCSI Bus Sharing --> None > > > > HD1 --> Virtual --> SCSI (0:0) > > > > Ambos são thinprovisiniong. > > > > Mount e fdisk no FreeBSD: > > # mount > > /dev/da0p2 on / (ufs, local, journaled soft-updates) > > devfs on /dev (devfs, local, multilabel) > > > > # fdisk /dev/da0 > > *** Working on device /dev/da0 *** > > parameters extracted from in-core disklabel are: > > cylinders=1305 heads=255 sectors/track=63 (16065 blks/cyl) > > > > Figures below won't work with BIOS for partitions not in cyl 1 > > parameters to be used for BIOS calculations are: > > cylinders=1305 heads=255 sectors/track=63 (16065 blks/cyl) > > > > Media sector size is 512 > > Warning: BIOS sector numbering starts with sector 1 > > Information from DOS bootblock is: > > The data for partition 1 is: > > sysid 238 (0xee),(EFI GPT) > >start 1, size 20971519 (10239 Meg), flag 80 (active) > >beg: cyl 0/ head 0/ sector 2; > >end: cyl 1023/ head 255/ sector 63 > > The data for partition 2 is: > > > > The data for partition 3 is: > > > > The data for partition 4 is: > > > > > > > > Mount e fdisk no ubuntu: > > # mount > > /dev/mapper/coringa-root on / type ext4 (rw,errors=remount-ro) > > proc on /proc type proc (rw,noexec,nosuid,nodev) > > none on /sys type sysfs (rw,noexec,nosuid,nodev) > > none on /sys/fs/fuse/connections type fusectl (rw) > > none on /sys/kernel/debug type debugfs (rw) > > none on /sys/kernel/security type securityfs (rw) > > none on /dev type devtmpfs (rw,mode=0755) > > none on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620) > > none on /dev/shm type tmpfs (rw,nosuid,nodev) > > none on /var/run type tmpfs (rw,nosuid,mode=0755) > > none on /var/lock type tmpfs (rw,noexec,nosuid,nodev) > > none on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) > > /dev/sda1 on /boot type ext2 (rw) > > > > # fdisk -l > > > > Disk /dev/sda: 10.7 GB, 10737418240 bytes > > 255 heads, 63 sectors/track, 1305 cylinders > > Units = cylinders of 16065 * 512 = 8225280 bytes > > Sector size (logical/physical): 512 bytes / 512 bytes > > I/O size (minimum/optimal): 512 bytes / 512 bytes > > Disk identifier: 0x0007fbc2 > > > > Device Boot Start End Blocks Id System > > /dev/sda1 * 1 32 248832 83 Linux > > Partition 1 does not end on cylinder boundary. > > /dev/sda2 321306102338575 Extended > > /dev/sda5 32130610233856 8e Linux LVM > > > > > > > > Em 18 de maio de 2012 00:04, Pedro Madsen escreveu: > > > O volume está dinâmico ou estático? Já vi problemas assim com Hiper-V > com > > > volume dinâmico. > > > > > > Em 17 de maio de 2012 23:36, Paulo Henrique > >escreveu: > > > > > >> Em 17 de maio de 2012 21:19, Welinaldo Lopes Nascimento < > > >> welina...@bsd.com.br> escreveu: > > >> > > >> > Qual a configuração de hardware deste servidor? > > >> > > > >> > Em 17 de maio de 2012 18:56, Ari Arantes Filho > > escreveu: > > >> > > > >> > > SCSI controller 0 --> LSI Logic Parallel. A mesma utilizada no > > Ubuntu. > > >> > > Não mexi na configuração wizard do vmware. Escolhi FreeBSD 64 > para o > > >> > > BSD e Ubuntu 64 para ubuntu. > > >> > > > > >> > > > > >> > > Em 17 de maio de 2012 14:46, Francisco Cardoso < > frica...@bsd.com.br > > > > > >> > > escreveu: > > >> > > > Em 17 de maio de 2012 11:58, Ari Arantes Filho > > >> > escreveu: > > >> > > >> O servidor é um IBM3550M3. A controladora é a padrão. > > >> > > >> > > >> > > >> Também testei com um FreeBSD instalado no storage e não no > disco > > >> local > > >> > > >> do vmware na 3550, mas os tempos também são bem parecidos. > > >> > > >> > > >> > > >> Vou testar com a 8.3. > > >> > > >> > > >> > > >> > > >> > > > > > >> > > > Acho que não me expressei bem. Quando falei controladora quis > > dizer a > > >> > > > controladora da máquina virtual, não a do hardware físico do > > >> servidor. > > >> > > > Em outras palavras se a sua máquina virtual usa a controladora > > >> > > > Buslogic, por exemplo, você vai ter problemas de lentidão, já > que > > >> essa > >
Re: [FUG-BR] Acesso ao disco em vmware
Pelo proprio virtualizador, veja se o espaço do disco já foi préa-locado ou se ele irá expandir dinamicamente conforme o uso. No caso do Hiper-V, isso demora pois após o FreeBSD solicitar espaço no disco, o tempo de repasse para o virtualizador e a resposta da alocação do próprio Windows gera uma latência alta demais que engargala os processos da máquina virtual. No caso do espaço pré-alocado, o virtualizador não demora a responder a solicitação. Em 18 de maio de 2012 08:02, Ari Arantes Filho escreveu: > Como eu vejo se está dinâmico ou não? No vmware ou no SO? > > 2 duas VMs: > SCSI controller --> LSI Logic Parallel > SCSI Bus Sharing --> None > > HD1 --> Virtual --> SCSI (0:0) > > Ambos são thinprovisiniong. > > Mount e fdisk no FreeBSD: > # mount > /dev/da0p2 on / (ufs, local, journaled soft-updates) > devfs on /dev (devfs, local, multilabel) > > # fdisk /dev/da0 > *** Working on device /dev/da0 *** > parameters extracted from in-core disklabel are: > cylinders=1305 heads=255 sectors/track=63 (16065 blks/cyl) > > Figures below won't work with BIOS for partitions not in cyl 1 > parameters to be used for BIOS calculations are: > cylinders=1305 heads=255 sectors/track=63 (16065 blks/cyl) > > Media sector size is 512 > Warning: BIOS sector numbering starts with sector 1 > Information from DOS bootblock is: > The data for partition 1 is: > sysid 238 (0xee),(EFI GPT) >start 1, size 20971519 (10239 Meg), flag 80 (active) >beg: cyl 0/ head 0/ sector 2; >end: cyl 1023/ head 255/ sector 63 > The data for partition 2 is: > > The data for partition 3 is: > > The data for partition 4 is: > > > > Mount e fdisk no ubuntu: > # mount > /dev/mapper/coringa-root on / type ext4 (rw,errors=remount-ro) > proc on /proc type proc (rw,noexec,nosuid,nodev) > none on /sys type sysfs (rw,noexec,nosuid,nodev) > none on /sys/fs/fuse/connections type fusectl (rw) > none on /sys/kernel/debug type debugfs (rw) > none on /sys/kernel/security type securityfs (rw) > none on /dev type devtmpfs (rw,mode=0755) > none on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620) > none on /dev/shm type tmpfs (rw,nosuid,nodev) > none on /var/run type tmpfs (rw,nosuid,mode=0755) > none on /var/lock type tmpfs (rw,noexec,nosuid,nodev) > none on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) > /dev/sda1 on /boot type ext2 (rw) > > # fdisk -l > > Disk /dev/sda: 10.7 GB, 10737418240 bytes > 255 heads, 63 sectors/track, 1305 cylinders > Units = cylinders of 16065 * 512 = 8225280 bytes > Sector size (logical/physical): 512 bytes / 512 bytes > I/O size (minimum/optimal): 512 bytes / 512 bytes > Disk identifier: 0x0007fbc2 > > Device Boot Start End Blocks Id System > /dev/sda1 * 1 32 248832 83 Linux > Partition 1 does not end on cylinder boundary. > /dev/sda2 321306102338575 Extended > /dev/sda5 32130610233856 8e Linux LVM > > > > Em 18 de maio de 2012 00:04, Pedro Madsen escreveu: > > O volume está dinâmico ou estático? Já vi problemas assim com Hiper-V com > > volume dinâmico. > > > > Em 17 de maio de 2012 23:36, Paulo Henrique >escreveu: > > > >> Em 17 de maio de 2012 21:19, Welinaldo Lopes Nascimento < > >> welina...@bsd.com.br> escreveu: > >> > >> > Qual a configuração de hardware deste servidor? > >> > > >> > Em 17 de maio de 2012 18:56, Ari Arantes Filho > escreveu: > >> > > >> > > SCSI controller 0 --> LSI Logic Parallel. A mesma utilizada no > Ubuntu. > >> > > Não mexi na configuração wizard do vmware. Escolhi FreeBSD 64 para o > >> > > BSD e Ubuntu 64 para ubuntu. > >> > > > >> > > > >> > > Em 17 de maio de 2012 14:46, Francisco Cardoso > > >> > > escreveu: > >> > > > Em 17 de maio de 2012 11:58, Ari Arantes Filho > >> > escreveu: > >> > > >> O servidor é um IBM3550M3. A controladora é a padrão. > >> > > >> > >> > > >> Também testei com um FreeBSD instalado no storage e não no disco > >> local > >> > > >> do vmware na 3550, mas os tempos também são bem parecidos. > >> > > >> > >> > > >> Vou testar com a 8.3. > >> > > >> > >> > > >> > >> > > > > >> > > > Acho que não me expressei bem. Quando falei controladora quis > dizer a > >> > > > controladora da máquina virtual, não a do hardware físico do > >> servidor. > >> > > > Em outras palavras se a sua máquina virtual usa a controladora > >> > > > Buslogic, por exemplo, você vai ter problemas de lentidão, já que > >> essa > >> > > > controladora é antiga e em geral só deve ser usada para sistemas > >> > > > legados. > >> > > > > >> > > > Em geral o vsphere oferece como padrão para o FreeBSD a controlado > >> LSI > >> > > > Logic Parallel se não me falha a memória. A performance desta é > >> > > > incomparavelmente melhor do que a Buslogic. > >> > > > > >> > > >> > > >> Só uma pergunta, qual o seu valor de HZ no kernel ? > >> > >> Att. > >> > >> > > >> > > >> > -- > >> > .:: Welinaldo L N > >> > .:: Estudante de Desenvolvimento de Sistemas > >> > .:: Free
Re: [FUG-BR] Acesso ao disco em vmware
Como eu vejo se está dinâmico ou não? No vmware ou no SO? 2 duas VMs: SCSI controller --> LSI Logic Parallel SCSI Bus Sharing --> None HD1 --> Virtual --> SCSI (0:0) Ambos são thinprovisiniong. Mount e fdisk no FreeBSD: # mount /dev/da0p2 on / (ufs, local, journaled soft-updates) devfs on /dev (devfs, local, multilabel) # fdisk /dev/da0 *** Working on device /dev/da0 *** parameters extracted from in-core disklabel are: cylinders=1305 heads=255 sectors/track=63 (16065 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=1305 heads=255 sectors/track=63 (16065 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 238 (0xee),(EFI GPT) start 1, size 20971519 (10239 Meg), flag 80 (active) beg: cyl 0/ head 0/ sector 2; end: cyl 1023/ head 255/ sector 63 The data for partition 2 is: The data for partition 3 is: The data for partition 4 is: Mount e fdisk no ubuntu: # mount /dev/mapper/coringa-root on / type ext4 (rw,errors=remount-ro) proc on /proc type proc (rw,noexec,nosuid,nodev) none on /sys type sysfs (rw,noexec,nosuid,nodev) none on /sys/fs/fuse/connections type fusectl (rw) none on /sys/kernel/debug type debugfs (rw) none on /sys/kernel/security type securityfs (rw) none on /dev type devtmpfs (rw,mode=0755) none on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620) none on /dev/shm type tmpfs (rw,nosuid,nodev) none on /var/run type tmpfs (rw,nosuid,mode=0755) none on /var/lock type tmpfs (rw,noexec,nosuid,nodev) none on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) /dev/sda1 on /boot type ext2 (rw) # fdisk -l Disk /dev/sda: 10.7 GB, 10737418240 bytes 255 heads, 63 sectors/track, 1305 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x0007fbc2 Device Boot Start End Blocks Id System /dev/sda1 * 1 32 248832 83 Linux Partition 1 does not end on cylinder boundary. /dev/sda2 321306102338575 Extended /dev/sda5 32130610233856 8e Linux LVM Em 18 de maio de 2012 00:04, Pedro Madsen escreveu: > O volume está dinâmico ou estático? Já vi problemas assim com Hiper-V com > volume dinâmico. > > Em 17 de maio de 2012 23:36, Paulo Henrique escreveu: > >> Em 17 de maio de 2012 21:19, Welinaldo Lopes Nascimento < >> welina...@bsd.com.br> escreveu: >> >> > Qual a configuração de hardware deste servidor? >> > >> > Em 17 de maio de 2012 18:56, Ari Arantes Filho escreveu: >> > >> > > SCSI controller 0 --> LSI Logic Parallel. A mesma utilizada no Ubuntu. >> > > Não mexi na configuração wizard do vmware. Escolhi FreeBSD 64 para o >> > > BSD e Ubuntu 64 para ubuntu. >> > > >> > > >> > > Em 17 de maio de 2012 14:46, Francisco Cardoso >> > > escreveu: >> > > > Em 17 de maio de 2012 11:58, Ari Arantes Filho >> > escreveu: >> > > >> O servidor é um IBM3550M3. A controladora é a padrão. >> > > >> >> > > >> Também testei com um FreeBSD instalado no storage e não no disco >> local >> > > >> do vmware na 3550, mas os tempos também são bem parecidos. >> > > >> >> > > >> Vou testar com a 8.3. >> > > >> >> > > >> >> > > > >> > > > Acho que não me expressei bem. Quando falei controladora quis dizer a >> > > > controladora da máquina virtual, não a do hardware físico do >> servidor. >> > > > Em outras palavras se a sua máquina virtual usa a controladora >> > > > Buslogic, por exemplo, você vai ter problemas de lentidão, já que >> essa >> > > > controladora é antiga e em geral só deve ser usada para sistemas >> > > > legados. >> > > > >> > > > Em geral o vsphere oferece como padrão para o FreeBSD a controlado >> LSI >> > > > Logic Parallel se não me falha a memória. A performance desta é >> > > > incomparavelmente melhor do que a Buslogic. >> > > > >> > >> > >> Só uma pergunta, qual o seu valor de HZ no kernel ? >> >> Att. >> >> > >> > >> > -- >> > .:: Welinaldo L N >> > .:: Estudante de Desenvolvimento de Sistemas >> > .:: FreeBSD Community Member #BSD/OS >> > .:: Antes de imprimir, veja se realmente é necessário! >> > .ılı..ılı. >> > - >> > Histórico: http://www.fug.com.br/historico/html/freebsd/ >> > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >> > >> >> >> >> -- >> :=)><(=: >> >> Flamers > /dev/null !!! >> - >> Histórico: http://www.fug.com.br/historico/html/freebsd/ >> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >> > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailm
Re: [FUG-BR] Acesso ao disco em vmware
São 2 processadores Xeon E5620, 4 HDs SAS 300Gb e 32Gb de RAM. Em 17 de maio de 2012 21:19, Welinaldo Lopes Nascimento escreveu: > Qual a configuração de hardware deste servidor? > > Em 17 de maio de 2012 18:56, Ari Arantes Filho escreveu: > >> SCSI controller 0 --> LSI Logic Parallel. A mesma utilizada no Ubuntu. >> Não mexi na configuração wizard do vmware. Escolhi FreeBSD 64 para o >> BSD e Ubuntu 64 para ubuntu. >> >> >> Em 17 de maio de 2012 14:46, Francisco Cardoso >> escreveu: >> > Em 17 de maio de 2012 11:58, Ari Arantes Filho escreveu: >> >> O servidor é um IBM3550M3. A controladora é a padrão. >> >> >> >> Também testei com um FreeBSD instalado no storage e não no disco local >> >> do vmware na 3550, mas os tempos também são bem parecidos. >> >> >> >> Vou testar com a 8.3. >> >> >> >> >> > >> > Acho que não me expressei bem. Quando falei controladora quis dizer a >> > controladora da máquina virtual, não a do hardware físico do servidor. >> > Em outras palavras se a sua máquina virtual usa a controladora >> > Buslogic, por exemplo, você vai ter problemas de lentidão, já que essa >> > controladora é antiga e em geral só deve ser usada para sistemas >> > legados. >> > >> > Em geral o vsphere oferece como padrão para o FreeBSD a controlado LSI >> > Logic Parallel se não me falha a memória. A performance desta é >> > incomparavelmente melhor do que a Buslogic. >> > >> > -- >> > >> > Francisco Ricardo >> > ___ >> > Administrador de Redes e Sistemas Unix/Linux >> > Profissional Certificado RedHat | Entusiasta FreeBSD >> > Natal/RN | (84)9461-4801 | frica...@bsd.com.br >> > - >> > Histórico: http://www.fug.com.br/historico/html/freebsd/ >> > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >> - >> Histórico: http://www.fug.com.br/historico/html/freebsd/ >> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >> > > > > -- > .:: Welinaldo L N > .:: Estudante de Desenvolvimento de Sistemas > .:: FreeBSD Community Member #BSD/OS > .:: Antes de imprimir, veja se realmente é necessário! > .ılı..ılı. > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Acesso ao disco em vmware
O volume está dinâmico ou estático? Já vi problemas assim com Hiper-V com volume dinâmico. Em 17 de maio de 2012 23:36, Paulo Henrique escreveu: > Em 17 de maio de 2012 21:19, Welinaldo Lopes Nascimento < > welina...@bsd.com.br> escreveu: > > > Qual a configuração de hardware deste servidor? > > > > Em 17 de maio de 2012 18:56, Ari Arantes Filho escreveu: > > > > > SCSI controller 0 --> LSI Logic Parallel. A mesma utilizada no Ubuntu. > > > Não mexi na configuração wizard do vmware. Escolhi FreeBSD 64 para o > > > BSD e Ubuntu 64 para ubuntu. > > > > > > > > > Em 17 de maio de 2012 14:46, Francisco Cardoso > > > escreveu: > > > > Em 17 de maio de 2012 11:58, Ari Arantes Filho > > escreveu: > > > >> O servidor é um IBM3550M3. A controladora é a padrão. > > > >> > > > >> Também testei com um FreeBSD instalado no storage e não no disco > local > > > >> do vmware na 3550, mas os tempos também são bem parecidos. > > > >> > > > >> Vou testar com a 8.3. > > > >> > > > >> > > > > > > > > Acho que não me expressei bem. Quando falei controladora quis dizer a > > > > controladora da máquina virtual, não a do hardware físico do > servidor. > > > > Em outras palavras se a sua máquina virtual usa a controladora > > > > Buslogic, por exemplo, você vai ter problemas de lentidão, já que > essa > > > > controladora é antiga e em geral só deve ser usada para sistemas > > > > legados. > > > > > > > > Em geral o vsphere oferece como padrão para o FreeBSD a controlado > LSI > > > > Logic Parallel se não me falha a memória. A performance desta é > > > > incomparavelmente melhor do que a Buslogic. > > > > > > > > > Só uma pergunta, qual o seu valor de HZ no kernel ? > > Att. > > > > > > > -- > > .:: Welinaldo L N > > .:: Estudante de Desenvolvimento de Sistemas > > .:: FreeBSD Community Member #BSD/OS > > .:: Antes de imprimir, veja se realmente é necessário! > > .ılı..ılı. > > - > > Histórico: http://www.fug.com.br/historico/html/freebsd/ > > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > > > > > > -- > :=)><(=: > > Flamers > /dev/null !!! > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Acesso ao disco em vmware
Em 17 de maio de 2012 21:19, Welinaldo Lopes Nascimento < welina...@bsd.com.br> escreveu: > Qual a configuração de hardware deste servidor? > > Em 17 de maio de 2012 18:56, Ari Arantes Filho escreveu: > > > SCSI controller 0 --> LSI Logic Parallel. A mesma utilizada no Ubuntu. > > Não mexi na configuração wizard do vmware. Escolhi FreeBSD 64 para o > > BSD e Ubuntu 64 para ubuntu. > > > > > > Em 17 de maio de 2012 14:46, Francisco Cardoso > > escreveu: > > > Em 17 de maio de 2012 11:58, Ari Arantes Filho > escreveu: > > >> O servidor é um IBM3550M3. A controladora é a padrão. > > >> > > >> Também testei com um FreeBSD instalado no storage e não no disco local > > >> do vmware na 3550, mas os tempos também são bem parecidos. > > >> > > >> Vou testar com a 8.3. > > >> > > >> > > > > > > Acho que não me expressei bem. Quando falei controladora quis dizer a > > > controladora da máquina virtual, não a do hardware físico do servidor. > > > Em outras palavras se a sua máquina virtual usa a controladora > > > Buslogic, por exemplo, você vai ter problemas de lentidão, já que essa > > > controladora é antiga e em geral só deve ser usada para sistemas > > > legados. > > > > > > Em geral o vsphere oferece como padrão para o FreeBSD a controlado LSI > > > Logic Parallel se não me falha a memória. A performance desta é > > > incomparavelmente melhor do que a Buslogic. > > > > > Só uma pergunta, qual o seu valor de HZ no kernel ? Att. > > > -- > .:: Welinaldo L N > .:: Estudante de Desenvolvimento de Sistemas > .:: FreeBSD Community Member #BSD/OS > .:: Antes de imprimir, veja se realmente é necessário! > .ılı..ılı. > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > -- :=)><(=: Flamers > /dev/null !!! - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Acesso ao disco em vmware
Qual a configuração de hardware deste servidor? Em 17 de maio de 2012 18:56, Ari Arantes Filho escreveu: > SCSI controller 0 --> LSI Logic Parallel. A mesma utilizada no Ubuntu. > Não mexi na configuração wizard do vmware. Escolhi FreeBSD 64 para o > BSD e Ubuntu 64 para ubuntu. > > > Em 17 de maio de 2012 14:46, Francisco Cardoso > escreveu: > > Em 17 de maio de 2012 11:58, Ari Arantes Filho escreveu: > >> O servidor é um IBM3550M3. A controladora é a padrão. > >> > >> Também testei com um FreeBSD instalado no storage e não no disco local > >> do vmware na 3550, mas os tempos também são bem parecidos. > >> > >> Vou testar com a 8.3. > >> > >> > > > > Acho que não me expressei bem. Quando falei controladora quis dizer a > > controladora da máquina virtual, não a do hardware físico do servidor. > > Em outras palavras se a sua máquina virtual usa a controladora > > Buslogic, por exemplo, você vai ter problemas de lentidão, já que essa > > controladora é antiga e em geral só deve ser usada para sistemas > > legados. > > > > Em geral o vsphere oferece como padrão para o FreeBSD a controlado LSI > > Logic Parallel se não me falha a memória. A performance desta é > > incomparavelmente melhor do que a Buslogic. > > > > -- > > > > Francisco Ricardo > > ___ > > Administrador de Redes e Sistemas Unix/Linux > > Profissional Certificado RedHat | Entusiasta FreeBSD > > Natal/RN | (84)9461-4801 | frica...@bsd.com.br > > - > > Histórico: http://www.fug.com.br/historico/html/freebsd/ > > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > -- .:: Welinaldo L N .:: Estudante de Desenvolvimento de Sistemas .:: FreeBSD Community Member #BSD/OS .:: Antes de imprimir, veja se realmente é necessário! .ılı..ılı. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Acesso ao disco em vmware
SCSI controller 0 --> LSI Logic Parallel. A mesma utilizada no Ubuntu. Não mexi na configuração wizard do vmware. Escolhi FreeBSD 64 para o BSD e Ubuntu 64 para ubuntu. Em 17 de maio de 2012 14:46, Francisco Cardoso escreveu: > Em 17 de maio de 2012 11:58, Ari Arantes Filho escreveu: >> O servidor é um IBM3550M3. A controladora é a padrão. >> >> Também testei com um FreeBSD instalado no storage e não no disco local >> do vmware na 3550, mas os tempos também são bem parecidos. >> >> Vou testar com a 8.3. >> >> > > Acho que não me expressei bem. Quando falei controladora quis dizer a > controladora da máquina virtual, não a do hardware físico do servidor. > Em outras palavras se a sua máquina virtual usa a controladora > Buslogic, por exemplo, você vai ter problemas de lentidão, já que essa > controladora é antiga e em geral só deve ser usada para sistemas > legados. > > Em geral o vsphere oferece como padrão para o FreeBSD a controlado LSI > Logic Parallel se não me falha a memória. A performance desta é > incomparavelmente melhor do que a Buslogic. > > -- > > Francisco Ricardo > ___ > Administrador de Redes e Sistemas Unix/Linux > Profissional Certificado RedHat | Entusiasta FreeBSD > Natal/RN | (84)9461-4801 | frica...@bsd.com.br > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Acesso ao disco em vmware
Em 17 de maio de 2012 11:58, Ari Arantes Filho escreveu: > O servidor é um IBM3550M3. A controladora é a padrão. > > Também testei com um FreeBSD instalado no storage e não no disco local > do vmware na 3550, mas os tempos também são bem parecidos. > > Vou testar com a 8.3. > > Acho que não me expressei bem. Quando falei controladora quis dizer a controladora da máquina virtual, não a do hardware físico do servidor. Em outras palavras se a sua máquina virtual usa a controladora Buslogic, por exemplo, você vai ter problemas de lentidão, já que essa controladora é antiga e em geral só deve ser usada para sistemas legados. Em geral o vsphere oferece como padrão para o FreeBSD a controlado LSI Logic Parallel se não me falha a memória. A performance desta é incomparavelmente melhor do que a Buslogic. -- Francisco Ricardo ___ Administrador de Redes e Sistemas Unix/Linux Profissional Certificado RedHat | Entusiasta FreeBSD Natal/RN | (84)9461-4801 | frica...@bsd.com.br - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Acesso ao disco em vmware
O servidor é um IBM3550M3. A controladora é a padrão. Também testei com um FreeBSD instalado no storage e não no disco local do vmware na 3550, mas os tempos também são bem parecidos. Vou testar com a 8.3. Em 16 de maio de 2012 16:47, Francisco Cardoso escreveu: > Em 15 de maio de 2012 20:19, Ari Arantes Filho escreveu: >> No ubuntu também não tem o vmware-tools instalado. >> >> Em 15 de maio de 2012 18:36, Luiz Gustavo >> escreveu: >>> Em Ter, 2012-05-15 às 18:26 -0300, Ari Arantes Filho escreveu: Pessoal, Tenho alguns servidores em teste no VMware ESXi 5. Porém reparei que o acesso ao disco é extramente lento. Testei a versão 9.0-RELEASE. Alguém sabe o que pode ser feito para melhorar isso? Sem querer gerar polêmica, mas instalei um Ubuntu 10.04 LTS no mesmo servidor com as mesmas configurações e fiz 8 testes em tempos variados. Para descompactar a árvore do ports (tar xzf ports.tar.gz), no Ubuntu, o pior tempo foi de 0m49.005s e o melhor 0m32.784s.Fiz uns 10 testes (sempre depois que rodava o tar xzf ports.tar.gz, rodava um rm -rf ports), sempre pegando os tempos através do time. Já no FreeBSD, os tempos passam de 10m, 12m, um teste foi até 17m. O / no FreeBSD está com soft-update. >>> >>> Dai Ari, tudo bom ? >>> >>> Você instalou o vwmare-guestd ? se não me engano, isso já vem padrão no >>> ubuntu, por isso talvez a grande diferença. >>> >>> Tente instalar o vmware-guestd, acho que pra teu caso é esse: >>> >>> /usr/ports/emulators/vmware-guestd5 >>> >>> >>> Abraços >>> >>> -- >>> Luiz Gustavo Costa (Powered by BSD) >>> *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+ >>> mundoUnix - Consultoria em Software Livre >>> http://www.mundounix.com.br >>> ICQ: 2890831 / MSN: cont...@mundounix.com.br >>> Tel: 55 (21) 4063-7110 / 8194-1905 / (11) 4063-0407 >>> Blog: http://www.luizgustavo.pro.br >>> >>> - >>> Histórico: http://www.fug.com.br/historico/html/freebsd/ >>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >> - >> Histórico: http://www.fug.com.br/historico/html/freebsd/ >> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > > Muito estranho Ari ... 10 minutos para descompactar a árvore de ports? > > Qual a controladora virtual de discos que você usou? Testou com a > versão 8.2/8.3 do Free também? > > > -- > > Francisco Ricardo > ___ > Administrador de Redes e Sistemas Unix/Linux > Profissional Certificado RedHat | Entusiasta FreeBSD > Natal/RN | (84)9461-4801 | frica...@bsd.com.br > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Acesso ao disco em vmware
Em 15 de maio de 2012 20:19, Ari Arantes Filho escreveu: > No ubuntu também não tem o vmware-tools instalado. > > Em 15 de maio de 2012 18:36, Luiz Gustavo > escreveu: >> Em Ter, 2012-05-15 às 18:26 -0300, Ari Arantes Filho escreveu: >>> Pessoal, >>> >>> Tenho alguns servidores em teste no VMware ESXi 5. Porém reparei que o >>> acesso ao disco é extramente lento. Testei a versão 9.0-RELEASE. >>> >>> Alguém sabe o que pode ser feito para melhorar isso? >>> >>> Sem querer gerar polêmica, mas instalei um Ubuntu 10.04 LTS no mesmo >>> servidor com as mesmas configurações e fiz 8 testes em tempos >>> variados. >>> >>> Para descompactar a árvore do ports (tar xzf ports.tar.gz), no Ubuntu, >>> o pior tempo foi de 0m49.005s e o melhor 0m32.784s.Fiz uns 10 testes >>> (sempre depois que rodava o tar xzf ports.tar.gz, rodava um rm -rf >>> ports), sempre pegando os tempos através do time. Já no FreeBSD, os >>> tempos passam de 10m, 12m, um teste foi até 17m. >>> >>> O / no FreeBSD está com soft-update. >> >> Dai Ari, tudo bom ? >> >> Você instalou o vwmare-guestd ? se não me engano, isso já vem padrão no >> ubuntu, por isso talvez a grande diferença. >> >> Tente instalar o vmware-guestd, acho que pra teu caso é esse: >> >> /usr/ports/emulators/vmware-guestd5 >> >> >> Abraços >> >> -- >> Luiz Gustavo Costa (Powered by BSD) >> *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+ >> mundoUnix - Consultoria em Software Livre >> http://www.mundounix.com.br >> ICQ: 2890831 / MSN: cont...@mundounix.com.br >> Tel: 55 (21) 4063-7110 / 8194-1905 / (11) 4063-0407 >> Blog: http://www.luizgustavo.pro.br >> >> - >> Histórico: http://www.fug.com.br/historico/html/freebsd/ >> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Muito estranho Ari ... 10 minutos para descompactar a árvore de ports? Qual a controladora virtual de discos que você usou? Testou com a versão 8.2/8.3 do Free também? -- Francisco Ricardo ___ Administrador de Redes e Sistemas Unix/Linux Profissional Certificado RedHat | Entusiasta FreeBSD Natal/RN | (84)9461-4801 | frica...@bsd.com.br - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Acesso ao disco em vmware
No ubuntu também não tem o vmware-tools instalado. Em 15 de maio de 2012 18:36, Luiz Gustavo escreveu: > Em Ter, 2012-05-15 às 18:26 -0300, Ari Arantes Filho escreveu: >> Pessoal, >> >> Tenho alguns servidores em teste no VMware ESXi 5. Porém reparei que o >> acesso ao disco é extramente lento. Testei a versão 9.0-RELEASE. >> >> Alguém sabe o que pode ser feito para melhorar isso? >> >> Sem querer gerar polêmica, mas instalei um Ubuntu 10.04 LTS no mesmo >> servidor com as mesmas configurações e fiz 8 testes em tempos >> variados. >> >> Para descompactar a árvore do ports (tar xzf ports.tar.gz), no Ubuntu, >> o pior tempo foi de 0m49.005s e o melhor 0m32.784s.Fiz uns 10 testes >> (sempre depois que rodava o tar xzf ports.tar.gz, rodava um rm -rf >> ports), sempre pegando os tempos através do time. Já no FreeBSD, os >> tempos passam de 10m, 12m, um teste foi até 17m. >> >> O / no FreeBSD está com soft-update. > > Dai Ari, tudo bom ? > > Você instalou o vwmare-guestd ? se não me engano, isso já vem padrão no > ubuntu, por isso talvez a grande diferença. > > Tente instalar o vmware-guestd, acho que pra teu caso é esse: > > /usr/ports/emulators/vmware-guestd5 > > > Abraços > > -- > Luiz Gustavo Costa (Powered by BSD) > *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+ > mundoUnix - Consultoria em Software Livre > http://www.mundounix.com.br > ICQ: 2890831 / MSN: cont...@mundounix.com.br > Tel: 55 (21) 4063-7110 / 8194-1905 / (11) 4063-0407 > Blog: http://www.luizgustavo.pro.br > > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Acesso ao disco em vmware
Em Ter, 2012-05-15 às 18:26 -0300, Ari Arantes Filho escreveu: > Pessoal, > > Tenho alguns servidores em teste no VMware ESXi 5. Porém reparei que o > acesso ao disco é extramente lento. Testei a versão 9.0-RELEASE. > > Alguém sabe o que pode ser feito para melhorar isso? > > Sem querer gerar polêmica, mas instalei um Ubuntu 10.04 LTS no mesmo > servidor com as mesmas configurações e fiz 8 testes em tempos > variados. > > Para descompactar a árvore do ports (tar xzf ports.tar.gz), no Ubuntu, > o pior tempo foi de 0m49.005s e o melhor 0m32.784s.Fiz uns 10 testes > (sempre depois que rodava o tar xzf ports.tar.gz, rodava um rm -rf > ports), sempre pegando os tempos através do time. Já no FreeBSD, os > tempos passam de 10m, 12m, um teste foi até 17m. > > O / no FreeBSD está com soft-update. Dai Ari, tudo bom ? Você instalou o vwmare-guestd ? se não me engano, isso já vem padrão no ubuntu, por isso talvez a grande diferença. Tente instalar o vmware-guestd, acho que pra teu caso é esse: /usr/ports/emulators/vmware-guestd5 Abraços -- Luiz Gustavo Costa (Powered by BSD) *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+ mundoUnix - Consultoria em Software Livre http://www.mundounix.com.br ICQ: 2890831 / MSN: cont...@mundounix.com.br Tel: 55 (21) 4063-7110 / 8194-1905 / (11) 4063-0407 Blog: http://www.luizgustavo.pro.br - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
