Názory k článku
Red Hat končí s Btrfs, zřejmě nadobro
-
Myslim ze nestastny uz je to jmeno - SAMBA.
Co takhle LAMBADA? treba by to pak nebyl takovej vopruz
http://www.nsaneforums.com/topic/298882-microsoft-wont-patch-smb-flaw-that-only-an-idiot-would-expose/ -
Adam KaliszStříbrný podporovatelAno, protože je to implementované jako md-raid a nad tím btrfs, který se vlastně stará jen o jeden volume/ resp. prakticky nedělá volume management.
-
Ano https://en.wikipedia.org/wiki/HAMMER , ale portu pro Linux se asi jen tak nedočkáš.
-
Izak (neregistrovaný)
Jasne NetApp ;-))) ... ZFS v jadre je i jako moduly, problem ZFS je ten, ze nema opravne nastroje a tak jsem jiz videl ztracena data a stacilo by to opravit, ale NEJDE ... a ro jak na freeBSD tak na solarisu ... kdyz jsem Oracle psal v diskuzi, ze nemit fsck.zfs je hloupost a kazdy FS se muze pokazit, tak to smazali
Dale ZFS neumi pridavat disky do Z-poolu, jen dalsi Z-pool, tedy pro me na nic, ja kupuji disky a prodavam je do sw_raidu 5 ... rekli, ze zadne profi reseni tuhle vlastnost nema, tak jsem jim rekl ze ji ma NetApp a ten umi rozsirit RaidGrupu o disk a pak si clovek muze pustit restripe dat, aby byly vytizeny vsechny disky rovnomerne, to mi taky smazali ... nebot jak vsichni vime, neni lepsi reseni nez NetApp, hledali jsme 2 roky a nic nefungovalo tak dobre.
PS: Netapp je NAS,RAID pole, bezi nad FreeBSD, coz je tajeno, ma Wafl_FS (coz je to co vykrada ZFS i BTRFS, bylo to dokazano) a umi mnoho protokolu a nad tim vsim umi delat lokalni snapshoty a prenaset je ne jiny netapp ... bezi na tom mnoho SAP reseni, nebo SQL (DB2/Oracle) a misto FC voli NFS, je to flexibilnejsi a rychlost je stejna, jen je treba zmenit NFS blok, na mnoho nahodnych operaci je lepsi jej mit mensi, dramaticky pak roste rychlost pro mnoho pristupu a klesa latence
-
@Izak
"problem ZFS je ten, ze nema opravne nastroje a tak jsem jiz videl ztracena data"
Tohle prakticky nikdy neni vina ZFS ale toho ze si uzivatel blbe navrhnul zpool storage.
Napr pokud si vyrobis zpool kterej se sklada ze dvou vdev, a do jedny vdev das 50disku a do druhy pouze 1 kus, staci aby ti ten single-disk-vdev kleknul a spolehlive prijdes komplet o celej pool.Ten priklad je ponekud Xtremni ale popisuje platnej princip, totiz "if any vdev in a zpool fails then all data in the zpool is unavailable.
Proto je nutny si predtim neco nastudovat a podle svych pozadavku na redundanci/speed/storage size si to cely navrhnout.Je to stejny jako posadit joudu kterej celej zivot drandil na kolobezce do F1 a pak si stezovat ze "ty Formule 1 jsou uplne na hovno"..................... protoze se ten jouda v prvni zatacce vysypal do prikopu.
"problem ZFS je ten, ze nema opravne nastroje a tak jsem jiz videl ztracena data a stacilo by to opravit"
O jakych nastrojich je rec??
Protoze cely ZFS je samo o sobe 1 velkej nastroj na opravu dat!Teda abysme si rozumeli-ja mluvim o OpenZFS coz je fork ZFS verze od Sun na kterym dela BSD komunita a kterej vzniknul predtim nez ZFS zhaftnul Oracle a zamknul ho.
"Dale ZFS neumi pridavat disky do Z-poolu, jen dalsi Z-pool.."
Nevim jak je to u Oracle ale OpenZFS tohle samozrejme umi, zpool se rozsiri pridanim dalsiho vdev.
=> you can add more vdevs to the zpool after it is created.
Viz tutorial o ZFS:
https://drive.google.com/file/d/0BzHapVfrocfwblFvMVdvQ2ZqTGM/view
https://forums.freenas.org/index.php?threads/slideshow-explaining-vdev-zpool-zil-and-l2arc-for-noobs.7775/Pokud te ZFS zajima vic, tady je posledni video kde vyvojar ZFS Allan Jude
( spoluautor
https://www.kobo.com/us/en/ebook/freebsd-mastery-advanced-zfs
a https://www.kobo.com/us/en/ebook/freebsd-mastery-storage-essentials )
vyvraci nektery FUD + informuje co se chysta novyho:
http://www.jupiterbroadcasting.com/116766/for-the-love-of-zfs-bsd-now-203/
Enjoy! -
Sten (neregistrovaný)
ZFS má problémy třeba u disků, které špatně implementují flush cache (potvrdí jej před zápisem). Výpadek proudu pak dokáže ZFS odrovnat. Přitom by to šlo vyřešit snadno, stačilo by odrolovat několik posledních transakcí do konzistentního stavu, ZFS všechna potřebná data má. Což by byla práce právě pro nějakou fsck-like utilitu spuštěnou po startu.
Předpokládám, že ten problém je, že nemůžete přidat další disk do vdevu, ne že nemůžete do poolu přidat další vdev. Třeba nejde mít 6diskový RAID-6 vdev a přidáním dvou disků z něj udělat 8diskový RAID-6 vdev. Btrfs i mdadm tohle umí.
-
anonym (neregistrovaný)
ZFS tohle samozrejme umi, kdyz ho slusne pozadas (zpool import -F|-m|-n).
Jestli tvuj pozadavek je FS ktery 100% funguje i kdyz hardware vyslovene lze (ignoruje cache flush, ignoruje zapisy, cte data z nahodnych mist, pise data na nahodna mista atd) tak chci videt co pouzivas. Moderni FS se snazi takovou situaci detekovat, aby si vedel kdy sahnout do zaloh.
Problem pridavani disku do existujiciho vdev je non-issue v ZFS target audience (enterprise). Problem je bohuzel hluboko ve vlastnostech on-disk formatu (a pozadavcich na stabilitu zapsanych dat/COW).
Nevim jak tohle btrfs dela, ale tipnul bych ze tam bude nejaky hacek (jako kdyz defragmentace rusi block-sharing snapshotu).kdyz uz o tom mluvis, zkousel si na btrfs RAID5/6 rebuild/resilver? IIUC je to porad cele rozsypane a nahodne ztraci data.
-
Sten (neregistrovaný)
Můj požadavek je nástroj, který to umí opravit. Ono se tohle může stát i na jinak spolehlivém HW, třeba protože umře baterka HW RAIDu. Nebo kvůli bugu v ZFS, třeba tenhle to dělal. zpool import -F jsem neznal, díky, bohužel vypadá, že na Linuxu není spolehlivý.
Btrfs to dělá tak, že provede rebalance. Žádný háček v tom není, Btrfs umí mít na jednou svazku různé RAID úrovně najednou (typicky se používá pomalý úsporný RAID pro data a mnohem rychlejší pro metadata), pak má během rebalance dvě sady (jednu původní RAID na 6 discích, druhou nový RAID na 8 discích) a data kopíruje z jedné do druhé. Block sharing se při tom zachová. Btrfs teoreticky umí i různé RAIDy pro různé subvolumy, ale chybí tam ioctl, aby to šlo nastavovat, a je otázka, jak se to vlastně má chovat, pokud by se mezi těmi subvolumy sdílely data, momentálně to spíš náhodně vybere jednu strategii.
Resilver byl opraven v listopadu. Ale pořád je tam write hole.
-
Adam KaliszStříbrný podporovatel
Na Linuxu zrovna vyšla verze 0.7, třeba to opravila? Jinak na EuroBSDCon v Paříži bude tutoriál o OpenZFS od Michaela W. Lucase. Jsem přihlášen :-)
-
@adam kalisz
"na EuroBSDCon v Paříži bude tutoriál o OpenZFS od Michaela W. Lucase"Tak doufam ze budes referovat!
Urcite by bylo zajimavy slyset jak pokrocili s tou dedup tabulkou s promenitelnou/nastavitelnou velikosti tak aby to neposilalo system do kolen pokazdy kdyz nahodou vyzere komplet celou RAM.Taky to zpracovavani a DRZENI KOMPRIMOVANYCH DAT v RAM a odesilani snapshotu sifrovanyho datasetu do cloudu aniz by prijemce musel znat klic muze bejt hodne zajimavy.....
-
Ivan (neregistrovaný)
Nez se prislo na to, ze se takhle chovaji nektere disky od WD, tak se verilo ze problem je v XFS. Behem rebootu disk potrvrdil zapis dat, i kdyz je mel pouze ve svoji cache. Po rebootu byl FS poskozeny. ext3 to ale dokazalo ustat, zatimco XFS ne. A proto se dlouho hledala chyba v tomhle FS.
Jedna vec je jak je FS navrzeny a jak se chova v idealnim pripade, druha vec je co skutecne dokaze ustat v realnych podminkach.
-
toni (neregistrovaný)
"problem ZFS je ten, ze nema opravne nastroje"
To není pravda, ZFS má tzv. scrub, který kontroluje a případně opravuje data na zpoolu. Navíc ZFS automaticky opravuje chyby, které zjistí při běžném IO."nemit fsck.zfs je hloupost"
Tohle je asi věc názoru - mě naopak přijde jako hloupost chtít mít nástroj jako fsck, který funguje jen na neaktivním (odmountovaném) soborovém systému a čekat hodiny nebo i dny než doběhne. Takže jsem rád za scrub, který běží na pozadí."kazdy FS se muze pokazit"
100% souhlas, tesat do kamene."tak to smazali"
zkoušel jste založit Bug nebo request?"ZFS neumi pridavat disky do Z-poolu, jen dalsi Z-pool"
Tohle není pravda, disky se do poolu samozřejmě přidávat dají. Je ale pravda, že v ZFS nelze přidávat disky do existujícího RAID-Z vdevu."bezi nad FreeBSD, coz je tajeno"
Jen pro zajímavost, kdo a jak to tají? Tohohle si přece musel všimnout každý, kdo někdy viděl NetApp alespoň bootovat. Navíc FreeBSD se pro podobné účely používá dost často (viz např. Isilon), takže se snad není za co stydět?"ma Wafl_FS (coz je to co vykrada ZFS i BTRFS, bylo to dokazano)"
Kdo a jak to dokazal? Pokud máte na mysli ten spor NetApp vs Sun, tak pokud si správně vzpomínám, NetApp chtěl (1) zabránit tomu, aby Sun nabízel storage řešení založená na ZFS (pracovní stanice a general purpose servery byly ok) a (2) aby Sun nezveřejňoval zdrojáky ZFS a (3) nepodporoval další šíření ZFS. Spor byl urovnán a přesné pozadí asi nikdo z nás nezná, ale vzhledem k tomu, že Sun vzápětí zveřejnil zdrojáky ZFS, aktivně podporoval ZFS implementaci v Mac OS X a FreeBSD a začal prodávat storage boxy založené na ZFS (Sun Storage 7000), nedá se podle mě mluvit o nějakém drtivém vítězství NetAppu. Spíš bych to viděl na klasický patentový trolling. -
Adam KaliszStříbrný podporovatel
Jinak ke Sun Storage je docela dobrý tento: http://dtrace.org/blogs/bmc/2008/11/10/fishworks-now-it-can-be-told/ a tento: http://dtrace.org/blogs/ahl/2012/02/12/hardware-engineer/ článek. Happy reading
-
To ze na controlleru bezi BSD tajeno neni. U starsiho Ontapu kde je jeste 7-Mode je to naprosto zrejme. Novejsi verze s Cluster modem to trosku zakryvaji a z administrace to moc videt neni, ale staci se prihlasit primo na service processor nebo si pripojit seriovou consoli a koukat jak to bootuje.
Lidi z Netappu Vam informaci o BSD normalne reknout, zadne tajemstvi to neni.
Jinak technicky je to opravdu velmi vyspele reseni, je ta jejich podpora .... ta je obcas k vzteku :-(
-
Adam KaliszStříbrný podporovatel
Kompletně jiné paradigma. Shrnu to asi tak, že používáte výkon stroje na to, abyste data ukládal efektivně a více spolehlivě. Proto btrfs a ZFS používají Copy on Write, Checksum a podobné vymoženosti. Díky tomu můžete _ověřit_, že data, která jste uložil, budou skutečně navrácena v nezměněné podobě. No a když už máte kontrolní součet každého bloku, můžete poměrně snadno deduplikovat.
Umí to víc věcí, třeba právě integrace s volume managementem může být velkou výhodou při správě serverů. Knihy Michaela W. Lucase jsou dobrý začátek, když Vás ZFS zajímá. O btrfs byly přednášky na LinuxDays atp.
-
Problemy se spatnym vykonem ZFS (resp. jeho volume managementem), matoucim nastavenim quot, neustale chybejici disk space kvuli snapshotum a boot environmentum resime v praci (tady mluvim o domovskym systemu ZFS Solarisu) a neschopnost BTRFS ustat vypadek proudu sem resil doma nekolikrat, takze az zas tak me to nezajma.
Mel sem skoleni na ZFS primo od Oraclu, takze marketing znam a vim i jak vykonove neefektivni b-tree system s checksumem je.
Slo mi o to co konkretne pouzitelnyho tyhle novy b-tree systemy nabizej skutecne uzitecnyho oproti starsim casem proverenym b-tree systemum jako jsou XFS a JFS. Jestli jen checksum (coz dela disk tak jako tak nezavisle na filesystemu), deduplikaci (ktera je realne vyuzitelna snad jen pro IPS kde funguje jako binarni version control) a volume management, (ktery ma oproti SVM/LVM vykonovej deficit), tak fakt nechapu to nadseni kolem... -
vb (neregistrovaný)
Btrfs se zaměřuje na aktuální problémy Linuxu. Jedním z nich je systemd, ten pod Solarisem není. Přečtěte si
https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.reference/cha.snapper.html a pochopíte.U běžné konfigurace (např. samostatná pracovní stanice) systemd funguje, protože ta konfigurace je otestovaná. Když ale používáte konfigurace méně běžné (třeba NFS, LDAP), tak se může stát, že po změně konfigurace a rebootu se systemd zakousne a do systému se nedá dostat. Ani přes konzoli, ani přes síť ... Pak můžete trávit desítky minut odstraňováním problému v rescue módu, a nebo (když máte snapshoty), prostě jen nabootujete systém před provedením změny. Problém pak zkoumáte na jiném (ne produkčním) stroji.
Nicméně souhlasím s tím, že snapshoty žerou hodně místa. Výše zmiňovaná dokumentace uvádí, že btrfs je nastaveno jako default pro partitions se 16 GB. Já mám 32 GB a je to málo. Na "běžný" provoz to stačí, ale upgrade se na tom bez ručního mazání snapshotů dělat nedá. Na větším serveru jsem radši vyhradil 100 GB.
Pro uživatelská data openSUSE doporučuje XFS. Tady Btrfs žádné významné výhody nemá.
-
Trident (neregistrovaný)
My mame lepsi a s init zpetne kompatibilni SMF. A kdyz nam to spadne na tlamu recovery je rychle. I kdyz to nemuseli implementovat jako xmlkovy prujem... ale to je kvuli engineered systemum.
Vyreste si laskave problemy tam kde je mate resit - u systemd a nekravte dale system vytvarenim nesmyslnych zavislosti na dalsich komponentech.
Zrovna kvuli mamlasum tohoto typu jsem svou domovskou platformu - Linux opustil. -
bfe (neregistrovaný)
Má zkušenost je, že používání systemd bez btrfs je čistý masochismus. Několikrát se mi stalo, že po updatu nebo rekonfiguraci se systemd někde zasekl a OS nenabootoval. V tom případě stačilo nabootovat ze staršího snapshotu. (V openSUSE je naštěstí vytváření snapshotů automatizované.) Představa, že bych měl používat systemd bez snapshotů mě děsí.
-
Abych rekl, tak me za posledni dobu zacina Red Hat celkem stvat. Zacalo to se systemd, to jsem jeste bral jejich penize, jejich vyvoj, jejich pruser. Co me ale rozhodne nastavlo bylo jejich hlasovani o schvaleni Java 9, kde na pripominky k Jigsaw meli pres 5 let a malem to s IBM cele pohrbili (timhle u me fakt Red Hat klesnul). Tohle s Btrfs je stejne jenom kvuli tomu, ze to neni od nich.
-
papadapa (neregistrovaný)
Reakce byvaleho Redhatiho vyvojare pro sirsi kontext:
https://news.ycombinator.com/item?id=14907771 -
BTRFS (neregistrovaný)
No ja jej pouzival a zase zahodil, bezel bezel a ackoliv mel stovky MB volnych na svoje metadata a mel jeste 6TB volneho mista, takze mohl expandovat, tak prestal fungovat a jel rychlosti diskety a to i cteni, nikde nebylo napsano, jak to zvetsit, jen ze by to mela opravit reorganizace dat, tak jsme to pustil a prd. ... az jsem zjistil nedokumentovany parametr pri mountu, ktery mi poslal vyvojar, no mel jsem tam asi hodne souboru, ale nic extra, evidentne ovsem vice, nez do te doby kdo testoval.
Od te doby utekly min 4 roky a BTRFS bude asi jinde, ale nedivim se RH ze jej zahodil, kolikrat jeste zmeni strukturu dat ? ... kazdy jej tam bude moct pouzivat na svoji pest a treba az bude oznacen za stable, zase se do RH vrati.
RH je profi reseni a ma nahradu, rika se ji NetApp ... je to sice externi, ale zato velmi spolehlive a podporovane uplne vsemi.
-
brk (neregistrovaný)
Mám pár let starou velmi podobou zkušenost. Zrovna by se mi ale fakt hodně hodily snapshoty, tak jsem si říkal, že zkusím jeden testovací disk na btrfs převést. Posledních pár řádku vypadá takhle:
btrfs-convert(btrfs_search_slot+0x2d7)[0x4140d7]
btrfs-convert(btrfs_csum_file_block+0x4b7)[0x426537]
btrfs-convert[0x40bed4]
btrfs-convert(main+0x1764)[0x40ae14]
/lib64/libc.so.6(__libc_start_main+0xf0)[0x7f0817cad640]
btrfs-convert(_start+0x29)[0x40bab9]
Neúspěšně ukončen (SIGABRT) (core dumped [obraz paměti uložen])Já si nepamatuji, že by mi za posledních 15 let takhle zhavarovala nějaká utilita pro práci s ext*, XFS, Reiser, ... . Asi se RH ani moc nedivím.
-
jh (neregistrovaný)
Btrfs je defaultní souborový systém pro partition s operačním systémem ve SLESu 12 a současném openSUSE. To samozřejmě nedokazuje, že je to stabilní souborový systém. Ale ostré nasazení na spoustě počítačů indikuje, že vlastnosti, které se tam používají, dostatečně stabilní jsou. Všechny vlastnosti btrfs stabilní ještě nejsou, víc info je na https://btrfs.wiki.kernel.org/index.php/Status .
-
-
Filip JirsákStříbrný podporovatelV tom případě nechápu dotaz. Proč byste přecházel z RedHatu na něco jiného, když můžete pokračovat na RedHatu?
-
Filip JirsákStříbrný podporovatel
Z čeho usuzujete, že je problém zrovna v té kombinaci Dockeru na ext4, že to není něčím jiným? Já bych si tipnul, že změna distribuce bude mnohem větší zásah, než změna btrfs na ext4 pod Dockerem. Navíc podle mne není důvod, proč dál nepoužívat RH – btrfs tam nebude oficiálně podporované, což ale neznamená, že nebude fungovat.
Jinak pokud chcete distribuci čistě jen na kontejnery, podívejte se na CoreOS. Vedle Dockeru podporuje i rkt, což kontejnerová technologie podobná Dockeru, ale víc se drží unixové filozofie, že každý nástroj dělá jednu věc a cíle se dosáhne jejich vhodnou kombinací.
-
v.sp (neregistrovaný)
A já mám zase přesně opačné zkušenosti:-) Když mi na btrfs došlo místo (kvůli snapshotům apod.), prakticky nešlo uvolnit místo - smazáním snapshotů použitelné místo nevzniklo a rebalance na plném file systemu nejde udělat.
Teď provozuju docker na ext4 - dokonce na Ubuntu (čistý debian nechtěl nabootovat z NVMe disku) a zatím naprosto ok.Samozřejmě, ta zkušenost s btrfs je už přes půl roku stará a docker je o opár verzí dál, a tehdá to bylo na virtuálu na notebooku a teď je to vyhrazené PC se spoustou místa na SSD, takže těžko přímo porovnávat. Ale jak říkáš - pokud to funguje, proč na to sahat.
-
AlyoSHA (neregistrovaný)
Hello.
Okolo dockera je (alebo bol) celkom hype. Pametam sa ked som sa o tom chcel nieco dozvediet, tak som natrafil na kopec "tutorialov" kde sa hypsta manici vytesovali ake je to uber a kool a jedine co s tym dokazali predviest bolo ze si stiahli image z dockerhubu a spustili ho. Ale ako sracka mi to nepripada. Prevadzkujem to zatial experimentalne a celkom vyhovuje. Ma to pod kapotou zhruba to co som od toho vyzadoval teda vytvorenie image, nejaky ten deployment, kontejnery samozrejme a nejaky ten dohlad. Zatial ale neriesim ziaden failover, swarm ani ziadnu velku orchestraciu. Ale mam v merku aj LXC a runc. Takze kde skoncim este uvidim. :-) -
. . (neregistrovaný)
souhlas s Ondrejem, docker kritizují lidé, kteří ho prostě nepoužívají, stejně tak tutoriály píší lidé, kteří nemají dostatečné znalosti a veřejné containery jsou sra*ky.
Docker spojil co tady bylo do fungujícího celku, v současnosti na něj přechází hodně firem kvůli úspoře nákladů, osobně provozuji clustery o celkově tisících serverech s dockereme či jinými containery. V čechách na tom běží celý seznam, celá řada levných hostingů, ani o tom nevíte.
-
Ondrej (neregistrovaný)
Presne tak.
Jedinej problem je presne ve spatnejch tutorialech a ve spatnejch verejnejch kontejnerech. Osobne pouzivam prakticky jen ty od _, cili ofiko kontejnery, ty od lidi jsou vetsinou naboptnale srajdy, cest vyjimkam, co maj nesmyslne XX vrstev a v zakladu nejlepe ubuntu, nebo centos. -
kdyz uz je rec o kontejnerech, tady se tvrdi ze cca 80% verejne dostupnejch je zabugovanejch, coz je duvodem proc tyhle typci udelali soft na jeho analyzu:
"Anchore provides users with insight and control over the contents of containers from the start of development all the way to production"
https://twit.tv/shows/floss-weekly/episodes/427?autostart=falsea druhy video s kontejner tematikou:
"Phil Dougherty is co-founder and CEO of ContainerShip, the easiest way to orchestrate containerized applications and microservices across multiple cloud providers. One interface to deploy and manage docker containers across any cloud, public or private."https://twit.tv/shows/floss-weekly/episodes/444?autostart=false
-
Martini (neregistrovaný)
A zase tie flame wars na ZFS, btrfs, dokonca WAFL od NetAppu, ktorý stojí raketu a je ešte viac proprietary ako bývalo ZFS alebo je v podaní Oracle. Ale o to nejde.
Určite nikomu nemohlo uniknúť, že RH prešiel u RHEL7 z ext4 na XFS. Možno blbé rozhodnutie, možno nie. Ale XFS je veterán z roku 1994, a kto sleduje aspoň phoronix.com alebo nebodaj kernel patche, tak si určite všimol, že XFS pomaly naberá kód, ktorý zabezpečí COW, snapshoty, post-write deduplikáciu, checksumy (metadata už checksummed sú), atd. Vôbec by som sa nečudoval, ak RH spolupracuje s SGI na vývoji a obohatení XFS do formy, ktorá bude konkurovať ZFS či Btrfs. A áno, XFS nie je a asi nebude mať volume management ako btrfs alebo ZFS, ale načo znova vymýšľať koleso, keď tu máme LVM2? Integrovaný RAID má už dávno, a XFS dokonca detekuje parametre LVM2 RAID a nastaví sa podľa neho pre lepší beh, a to už dávno. Držme si palce, pomaly ale rock-solid. -
Filip JirsákStříbrný podporovatel
Jak LVM2 RAID zajistí přečtení správných dat v případě,kdy každý disk vrací něco jiného? Jak zajistí kopírování pouze užitečného obsahu (nekopírování nepoužívaného místa) při rebalancování pole (třeba po náhradě disku)?
-
Kde jsou ty doby, kdy na SCSI discich bych sektor o neco vetsi nez 512 byte, aby tam slo ulozit aplikacni checksum.
Kolikrat delate rebalancovani pole a pridavani disku do raidu? Z poslednich zkusenosti kdyz jsem prechazel pres 16TB hranici tak to vyzadovalo dokonce prechod z 32b na 64b OS. Pokud chcete/musite casto pridavat disky, tak je lepsi mit mensi MD pole z nekolika disku (4,6,8) a pak pridat dalsi sadu a spojovat to az na urovni LVM pres linear append. Ale s touto organizaci musite planovat od pocatku.
Duvod proc upoustim od pridavani dalsich disku do MD je, ze je to takova krizovka jenom.. vykon FS jde do kytek kvuli tomu ze byl naformatovan s puvodni organizaci poctu stripes. Nekdy se tomu lze vyhnout, kdyz vim ze tam bude nakonec jiny pocet disku (doplnenych v ramci kratke doby na finalni stav), a v tom pripade formatuji uz s finalnim poctem stripes (a suboptimalni vykon to ma tedy do doby nez se to pole rebalancuje).
-
"...je lepsi mit mensi MD pole z nekolika disku (4,6,8)..."
Tyhle pocty se doporucujou i u ZFS poolu= vetsi pocet VDEVu s mensim poctem disku max 10 optimalne tak 6-8ks. Pokud mas 36TB pool alias 6vdev x 6disku po 1TB a chces zvetsit pool upgradujes 1 vdev.
Je to sice nevyhoda ZFS ze musis upgadovat "po skupinach" ale to je zas vyvazeny jinyma vlastnostma.Dat do 1 VDEVu mraky disku je magorina protoze kdyz odejde 1 je sance ze odejde vzapeti i druhej (obzvlast kdyz jsou ze stejny sarze) a ZFS umi max RaidZ3 alias max ztrata 3disku v 1 VDEV.
Kdyz se pak provadi resilvering za "padle kamarady" je tu znova realna sance ze zacnou chcipat dalsi disky...Meli sme tu sveho casu o tom pomerne rozsahlou debatu:
https://forum.root.cz/index.php?topic=12850.60 -
-
myslis tohle??
http://www.theregister.co.uk/2016/11/28/microsoft_update_servers_left_all_azure_rhel_instances_hackable/http://ianduffy.ie/blog/2016/11/26/azure-bug-bounty-pwning-red-hat-enterprise-linux/
...usmevne :o))) ale Lael by nam to vysvetlil - ze to neni bug ale featura :o))))
"vzdyt si vzpomente soudruzi, meli sme to v ty brozure......" :o)))) -
petr (neregistrovaný)
linux os na železe je parodie...
rhel se snaží udělat další widle, takže zaobírat se tím jaký fs bude podporován nebo ne, je nesmysl, protože ani widle ani linux na železo nepatří.
kdo nemá peníze nasadí wmvare, kdo peníze má a jde mu o 24/7 provoz a to doslova, nasadí aix a powervm, no a kdo ví co dělá a má k dispozici rozpočet nasadím zOS/vm a openstack :)
takže ať si pytlíkují třeba super-open-skoro-zsf, ale ve virtuálu a neserou se na hw, tam na to prostě namají, stejně jako MS !
-
. . (neregistrovaný)
provoz 24/7 lze zajistit i na padajících systémech typu linux, v praxi to můžeš vidět u některých našich operátorů. To nemyslím jako ironii, volnost ve výběru HW a vendorů je obrovský tahoun, stejně tak dostupné lidské zdroje.
Na aix u nás (v EU) není dostatek lidí pro support, i IBM není ochotná prodat hodně mašin.
aix využívá toho, že běží jen na svým HW a nemusí podporovat kdejakou plechovku.
-
petr (neregistrovaný)
to ano, komoditní hw, je dnes buzz word a všichni se snaží ušetřit, jenže to pak stejně končí kombinací hp, dell + centos, takže rhel z toho nemá nic, vyjma základny beta testerů a nasranejch adminů u koncáku, kteří nevědí co s tím,,
rhel jako hypervizor nemá ani na vmware natož pak na technologie od ibm, které jsou na úplně jiné planetě.
takže jestli pojedou na btrfs, nebo xfs je úplně jedno protože jejich os je tak jako widle jen app launcher at nemá na železe co dělat.
co se týče aixu, francie je blízko a brněnský ibm nabíra jako divej a risc cpu + vlastní architektura je obrovská výhoda tak jako u mac os x na desktopech
rhel měl šanci udržet a přebrat pozici tradičních unixů, ale sázkou na systemd a další, tyto pozice v enterprise vyklidil...
dnešní trh, jsou proprietární hypervizory a objektová úložiště na komoditním hw u vendorů typu amazon a google a proprietárním hw typu zOS+openstack a isilon na freebsd u koncáků....zbytek zdechne a nebo bude přežívat ve vm jako app launcher...
-
petr (neregistrovaný)
jistě, poslední slovo nemám já jako architect, ale stake-holder/s a ten se, to Vás mohu ujistit, neřídí komunitním nadšením pro systemd, btrfs atd, tj. prostředky investuje z rozmyslem :)
Ono vlastně ani není divu, za poslední dvě dekády, linux totálně prošutroval desktop, a tak jak měl našlapnuto okolo roku 2007 na serverech, také nedokázal zužitkovat....
-
"ať si pytlíkují třeba super-open-skoro-zsf, ale ve virtuálu a neserou se na hw..."
Pokud vim tak ZFS funguje nejlip prave kdyz muze sahat primo na HW, virtual se primo nedoporucuje (teda na FreeBSD) neznamena to ale ze by to bylo zakazany, ovsem pak nastavaji ruzna prekvapeni prave diky mezivrstve.
