Je nejaka cesta, jak tu vzquotu nepouzivat, resp. vypnout, aby to pri
startu nepocitalo? Linux, ext4 :) Zfs neverim :)
Dne 15. 3. 2014 23:08, Pavel Snajdr napsal(a):
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
No dobre, tak jeste teda nejdu spat, tak se trochu rozepisu a
vysvetlim, o co jde:
- - kazdej kontejner je slozka na FS
- - coz znamena, ze abych mohl limitovat diskspace kontejneru, musel
bych mit FS per kontejner, coz trochu drti nektery vyhody kontejneru
(napr. agregace mista pri shared FS se proste neda udelat elegantneji)
V OpenVZ to vyresili tak, ze mezi ext*fs/xfs a "simfs" (simulovany fs
kontejneru) vlozili vzquotu, coz je neco jako tabulka mapovani muj
inode -> node na FS + accounting infromace o velikosti.
Diky tomu pak i funguje second-level quota (tzn. normalni linuxova
user/group quota) - coz je neco, co budeme muset do ZFS doimplementovat.
Nevyhoda vzquoty se pozna pri resetu systemu, kdyz nema cas si
syncnout ten mapujici soubor na disk. Pak musi vzquota pri startu
kazdyho kontejneru projit jeho soubory a znova je namapovat. To je
prave to, co ti muze rozhazet cisla inodu.
Bootovani serveru s vzquotou po resetu je pak tragedie a masina s 90
VPS muze naskakovat klidne 3-4 hodiny.
Krom toho je vzquota nachylna na random rozbijeni se i pres tu
kontrolu integrity, da se rozbit ze ukazuje min/vic zabranyho
mista/inodes, akorat nevim, jak k tomu dochazi (co je trigger toho
rozbiti), deje se to jenom zridkakdy.
Also, ukazalo se ze mit vic kontejneru na EXT4 je totalni blbost, v
ext4 je nejfatalnejsi problem journal. Stane se bottleneckem celyho
toho FS a proste neda se nic. Obzvlast, kdyz nad tim FS bezi par
databazi. Iowait leti nahoru, disky seekujou jak pomateny a
propustnost filesystemu jde do kytek.
Oproti tomu node se ZFS ma tech 90 VPS nastartovanych do tak 10ti
minut jako absolutni maximum.
A tech MySQL muze na serveru bezet, co zvlada CPU, protoze na
synchronnni zapisy a fuckup unixovyho sveta jmenem sync() ma ZFS
mechanismus jmenem Intent Log a moznost ho vysoupnout na dedikovany
device.
Oproti tomu ext4 ani s dedikovanym journalem na SSD nedela temer zadny
rozdil. Pak uz disky tolik neseekujou, ale vykon porad nikde.
Btw tahle "vlastnost" ext4ky donutila OpenVZ lidi implementovat ploop,
takze pak delaji ext4 in a file per container. So much win! :)
Urcite budem dal pracovat na ZFS podpore, linuxovy filesystemy jsou
jedna velka tragedie. Navic se diky tomu muzem zbavit ty tragedie vzquoty.
/snajpa
On 03/15/2014 10:55 PM, Pavel Snajdr wrote:
A na doplneni: na nodech se ZFS uz vzquota neni,
tam se to dit
nebude :)
S pozdravem
Pavel Snajdr
+421 948 816 186 | +420 720 107 791 | 110-010-956 CTO of
Relbit | Predseda vpsFree.cz, o.s. | RHCE
http://relbit.com |
http://vpsfree.cz |
https://www.redhat.com
On 03/15/2014 10:52 PM, Ondrej Mikle wrote:
Ahoj,
ma OpenVZ vlastnost, ze napriklad pri premigrovani kontejneru
nebo nejake jine zmene se taky zmeni inode numbers souboru na
filesystemu?
Ptam se proto, ze rkhunter to "spatne nese" a reportuje to. Pri
porovnani SHA256 checksumu s cistym systemem i s rpm --verify
checksumy sedi. Souboru se zmenenym inode je velka spousta, tim
padem z predchoziho vyplyva, ze jde o spis false alarm.
Setkal se s tim i nekdo jiny?
Dik, Ondro
_______________________________________________
Community-list
mailing list Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list
mailing list Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird -
http://www.enigmail.net/
iF4EAREIAAYFAlMkz1cACgkQMBKdi9lkZ6qPcQEAr2brTAOTd9+4FcAB2IOlJw0V
MmD7Uso5IIzsU3UjbP4BAMMFyCprg/9r6AClllGYjWh5AdM/fDJw7viLOi2Azcb6
=f3v/
-----END PGP SIGNATURE-----
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list