A ReiserFS után a JFS is mehet ki a kernelből?

Fájlrendszer, NAS, storage

Christoph Hellwig írta:

Hi all, A while ago we've deprecated reiserfs and scheduled it for removal. Looking into the hairy metapage code in JFS I wonder if we should do the same. While JFS isn't anywhere as complicated as reiserfs, it's also way less used and never made it to be the default file system in any major distribution. It's also looking pretty horrible in xfstests, and with all the ongoing folio work and hopeful eventual phaseout of buffer head based I/O path it's going to be a bit of a drag. (Which also can be said for many other file system, most of them being a bit simpler, though).

Igen
63% (220 szavazat)
Nem
8% (28 szavazat)
Nem tudom
29% (101 szavazat)
Összes szavazat: 349

( trey | 2023. 01. 18., sze – 09:16 )

Életemben nem tároltam egy bájtot se rajta. Mehet a kukába.

trey @ gépház

( asm v | 2023. 01. 18., sze – 09:26 )

Ez ugyanaz a JFS, mint amit az AIX hasznal alapbol vagy az mar JFS2 es nem kompatibilis ezzel?

Ez meg is lepett, hogy fejlesztik még az AIX-et. Innen vizsgálva ez egy nagyon jelentős érv, hogy a Linux kernelből ne vegyék akkor ki a támogatását. Ezt az apróságot elfelejtették írni a külföldi oldalakon is, hogy ez egy aktívan fejlesztett valami, lenne mögé fejlesztő is. Akkor addig kell a vasat ütni, amíg meleg. Legalábbis nagy baromság lenne addig eltemetni, amíg még él.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

 Érdekes, ezt hol is írja?

A linkelt dokumentum 2003-ban a JFS for Linux használatát taglalja. Linuxon, ahol nincs default ACL.

AIX-os JFS2-t lehet Linux alatt mountolni

Attól függ, hogy mit értünk ez alatt. A JFS mint, vfs akár Windows alatt is mehet, de attól még nem hívnám AIX filesystemnek. Az AIX volume kezelése egy hangyányit eltér bármi mástól, ezért az AIX volume-on készült JFS elérése nem igazán opció. Persz akárki megírhatja, ha nekilát...

 Érdekes, ezt hol is írja?

Ezt sem véletlenül kérdeztem. Az a bizonyos interoperability mit is jelent?

Ha AIX-ről állsz át linuxra, akkor olyan meglepetések érhetnek (érhettek), amivel én is szembesültem AIX->SCO "hordozásnál".  Ott ugyanis nincs ACL, mert sokkal gagyibb rendszer. A dokumentum azt írja le, hogy hogyan költözz át linuxról linux JFS-re + ACL. A másik átjárás az, amikor AIX-re telepítesz linux programokat, amik persze arra a rendszerre vannak fordítva. Az IBM AIX oldalról legalább 25 éve küzd azzal a problémával, hogy a linuxosok linux programot akarnak futtatni. (Pedig a szar rendszeren még a vindóz se fut. :-D Na, kivétel az NT!)

Amit ott olvashatsz, az egy DOS partícókkal felszerelt linux, semmi más. Akkortájt nem volt ez nagy durranás, készítettem én is pécére, JFS-re linux szervert. (OpenSuse, 2002)

A volume kezelést nem néztem meg

Hát én se. ;) Történetesen 19 évig üzemeltettem és programoztam AIX-en - ez a dokumentum kb. a "félidőben" keletkezett. A linuxot a 0.x verziótól ismerem, de keveset dolgoztam rajta, illetve eleinte munkaállomásként használtam AIX-hez, vagy AIX-re fejlesztettem, míg nem volt saját gépem. Ha a linux kezelné az AIX diszkeket, akkor már AIX lenne. (Szinte asimovi robotdefiníció. :-D) Azért talán van két lehetőség, amikor kizárólag a fs "kerül át" a linuxhoz: Ha a linux virualizált egy LPAR hoston  vagy iscsi-n keresztül. Egyik eset sem kezeli a fizikai diszket.

Persze nem vagyok mindentudó és tévedhetetlen sem. Ha mégis létezik olyan fícsör, amivel bármelyik rendszeren készült jfs kezelhető a másikon, arra kíváncsi lennék.

Azt írják, akik próbálták, hogy ha az AIX-on partíción van a JFS, akkor menni fog. Az LVM viszont nem kompatibilis a Linuxossal. Szóval akkor a filesystem (állítólag) támogatott, csak nem sokra mész vele.

(Amúgy én is odáig láttam nagyon régen AIX-ot, hogy ismerősök raktak rá GCC-t meg még egy-két GNU programot. Ugyanis az iskolánk kapott egy AIX-os RS6000-t a sulinet programban, de semmi nem volt rajta, csak az alap AIX, gondolom, az IBM azt remélte, hogy majd az iskolák vesznek. Aztán raktak rá GCC-t, fordítottak browsert, és egyre használhatóbb lett. De már akkor is úgy éreztem, hogy annyival nem lehet jobb, hogy megérje azt a sok pénzt és macerát.)

Azt írják, akik próbálták, hogy ha az AIX-on partíción van a JFS, akkor menni fog. Az LVM viszont nem kompatibilis a Linuxossal.

Ez egy képzavar. (A továbbiak < AIX 7-re igaz.)

Az AIX diszk subsystem felépítése:

  • A pv (phisical volume), ami legfeljebb 1016 partícióra osztható. (Partíció: a legkisebb egység, amit a rendszer kezel.)
  • Egy vagy több pv -> vg (volume group).
  • A vg-n belül a kellő számú partícióból készül az lv (logical volume), ami már több célra használható.
  • Az lv kialakítasakor meg lehet határozni a stratégiát, elhelyezést. tükrözést (1, 2 vagy 3 - 5L-től + hot spare). Pl. a tükrözés partíciónként történik.
  • A JFS az lv-re kerül.

Fontos, hogy az AIX-en az LVM nem csak opció, mint a linuxon. A diszk alrendszert úgy 50 paraméterrel szoktam hangolni, amelyek jó része nincs is linuxon. Ezek a lehetőségek olyan hatékonyak, hogy 100+ órás feldolgozást 2 óra alá sikerült gyorsítani. Igaz, több és újabb processzorok is kerültek a képbe, de a sok lépésből álló feldolgozás 26 diszket használt - szóval az sem volt teljesen mindegy. Persze semmi, amit itt leírtam. Ha olvasgatnál róla, akkor itt kezdjed!

egy AIX-os RS6000-t

Az RS/6000 csak 2000 októberéig volt, azaz nem mai csirke. ;)  Az "alap AIX" kb. mindenhez elég, legfeljebb gzip, ssh (ha még nincs) és xlc kell hozzá - már, ha dolgozni akarsz. Tudtad, hogy többféle *NIX  és mainframe utility is van rajta? Persze az igazi szakemberek rögtön felrakják a bash-t, a date parancsot (mert az AIX-é szar). ;)  Egy szerveren meg az a legleslegeslegfontosabb, hogy browser fusson rajta! :-DDD Szerintem kevered a lapostelefonnal. ;)

De már akkor is úgy éreztem, hogy annyival nem lehet jobb, hogy megérje azt a sok pénzt és macerát.

Csak nem számoltál utána. Egy "entry level" szerver kb. ugyanannyiba kerül, mint a hasonló képességű intel alapú szerver.  A hardver általában gyorsabb és kiegyensúlyozottabb. (Az egyes komponensek sebessége passzol egymáshoz.) A "sok macerea" egy linux vagy Windows esetében nyilvánvalóan kevesebb. (nem) Mondhatni, különösen nálunk a 10M linux és Windows szakértő országában, nem túl népszerű. Kicsit nyugatabbra már népszerűbb, csak nem a "netezős pc" kategóriában. ;) Általában bankok és állami intézmények használják.

Amit mondasz a volume-ról, az mind okés, de azt nem befolyásolja, hogy a filesystem ugyanaz-e. Ha cat-tal kiírom egy fileba, azt átmásolom egy PC-re, és azt loop módban fel tudom csatolni Linux alatt, akkor a filerendszer ugyanaz. Ennyit állítanak, kipróbálni nem tudom, mert az accountom az AIX-ra már rég lejárt (amikor leérettségiztem), és valószínűleg már a gép is reciklizálódott azóta, a házából gémkapocs lett, az elektronikájából veszélyes hulladék.

Az RS/6000 csak 2000 októberéig volt, azaz nem mai csirke. ;)

Nem bizony, 2000 előtt volt bőven. Szerintem munkaállomásnak szánt gép lehetett, egyszerű, asztali toronyház, a fő előnye a vele egyszerre érkezett valamilyen pentiumos desktop PC-kel szemben a szép nagy monitor volt.  Hogy mi volt a céljuk vele, azt nem tudom. Az iskola úgy két tucat windowsos desktop PC-t (fele IBM, fele Siemens), egy izmosabb PC-t (Siemens, azon később Linux volt) és ezt a dögöt kapta, A GNU cuccok közül elsősorban a GCC hiányzott, mivel szinte semmi szoftvert nem adtak hozzá. Be lehetett kapcsolni, feljött a CDE, és kész. Ahhoz, hogy szerver legyen, mondjuk kellett volna rá valami szerver szoftver, pl. egy fileserver, amit a windows pc-k használni tudtak volna. Vagy ha azért volt, hogy Unix-ot is lássanak a diákok, akkor egy C compiler. (Később, amikor már volt rajta gcc, akkor unix tanulásra lehett rajta accountot kérni, és mellesleg volt rajta Apache.) Amire ott használni lehetett, arra egy Linuxos PC-hez képest egy drága rossz megoldás volt, mert fel kellett rá küzdeni a C fordítót, aztán forrásból az Apache-ot, miközben az akkori Debianon ez csomagból ment. Konfigurálni kellett mindent, mert a shell beállítások (input, command line, karakterkiosztás), az X beállítások, mind szarabbak voltak defaultban mint a Debianban. Ezek a hátrányok mind megmaradnának egy kisebb céges környezetben. Egy bankban, ahol nem egy van, és valószínűleg valaki beállítva hozza, más a helyzet.

No, ezt kipróbálom, ha eljutok odáig, hogy bekapcsoljam a gépemet. Azt még ki kell találni, hogy a külön loglv hogyan fog átkerülni.

Ezek szerint nem kaptatok install anyagot és dokumentációt. Ha AIX 3 volt, abban még volt C fordító, ha 4-es, ahhoz meg Linux toolbox. Pedig ez a rendszer annyival jobb, mint a linux, hogy van hozzá man - példákkal, info - komplett tematikus könyvekkel és példákkal. A későbbi szerverek már nem is támogatták a grafikus adaptereket.

Szóval értem, ilyen találkozás alapján az AIX egy használhatatlan drága doboz. :(

NevemTeve 2005.06.15

Itt meg éppen egy 2003-as redbookról beszélgetünk.

Linuxon, ahol nincs default ACL.

Az AIX-en a bos része. (Base Operating System) Sőt, a JFS is és nincs is más.

Ezzel szemben linuxon jó ideig egyáltalán nem volt.

Megdöbbennél, ha látnád a 15 éve AIX->linux "hordozott" scriptemet, amiben vagy amihez néhány dolgot '93-94-ben írtam. Méghozzá eleinte linuxon, amíg bírtam, aztán vettem egy Atlas 604-et. (Nem NT-vel. ;))

> Az AIX volume kezelése egy hangyányit eltér bármi mástól,

Erről csak annyit, hogy az általad leírt LVM leírás szinte szóról szóra alkalmazható, a HP-UX-ban meglevő LVM nevű kötetkezelőre - amely valamikor a 9-es HP-UX-ban jelent meg; vagy éppen ugyanezen az elven működött a Digital (DEC) / Compaq ( HP )-féle Digital UNIX, DEC OSF/1 , Digital Tru64 UNIX-féle LSM (Logical Storage Manager) is. (Amelyet később kiszorított a VxVM (Veritas Extended Volume Manager) illetve az AdvFS - amely sokkal korábban hozta a kötetkezelő+FS-kezelő egybeépítve elvet, mint a SUN-csoda ZFS - meg az Orakkel-Btrfs) (*)

Fentiek persze valóban eltérnek egymástól - egy hangyányit. (Olyanokban, hogy míg az AIX LVM-ben a PV-k PP-kből (Physical Partition-nak nevezett azonos méretű egységekből) állnak, addig HP-n ezt PE-nek (Physical Extent-nek) hívják :-) - És hogy mennyire semmi közük nincs egymáshoz, azt mi sem bizonyítja jobban, mint hogy eléggé sokáig (HP-UX 11iv2 -ig ha jól rémlik) egy PV - mit ad isten - szintén 1016 PE-ből állhatott - ahogy az AIX PV-kről írtad a PP-k darabszámát :-) . De pl. az egész kötetkezelősdihez tartozó parancskészlet az már nagyon nagy mértékben különbözött e három rendszerben.

Persze lehet igazad, ha mondjuk a "bármi más" amitől eltér az AIX-féle kötetkezelés, az mondjuk a Windows-féle, vagy a Veritas-féle. (**) Amúgy az AIX elég sok mindent másként csinált, mint a többi hagyományos UNIX-gyártó. (Klasszikus példa, hogy a David korn-féle ,1987-es IOCCC- díjnyertes One-liner anno valamilyen 4.x-es AIX-en a gyári fordítóval le se fordult :-) Érdeklődőknek a megfejtés itt és itt. Utóbbi leírás "mysterious" része áttételesen azt is megmagyarázza, hogy mi volt a baj AIX-en. )

(*) Mondjuk ha valaki ismeri legalább nagy vonalakban a UNIX-ok fejlődéstörténetét, és tudja, hogy az Open Software Foundation (nem keverendő össze a Free Software Foundationnal) - alapítói között ilyen feledhető cégek szerepeltek, mint DEC, HP, IBM; és azt is tudja, hogy ott mindenki dobott be a közösbe valami technológiai nyalánkságot, (amit aztán a DEC-en kívül senki másnál meg nem alkotott OSF/1-be lehetett volna betenni szoftverice) - szóval ezek miatt annyira nem meglepő ez a marha nagy kötetkezelői hasonlóság.

(**) A VxVM-nél (Veritas) komoly eltérés, hogy nem azonos méretű PP-k / PE-k vannak, hanem kb tetszőleges méretű SD-k (subdisk), illetve a gyakorlatilag a tükrözéshez kitalált plex bevezetése is az eltérések számát gyarapítja.

Ui: És persze a linuxos LVM is eléggé hasonlít fentiekre - amúgy dokumentáltan azért, mert a HP-UX-beli LVM-hez hasonló elvi megvalósítást akartak a fejlesztők csinálni. Struktúra szintű kompatibilitás nem volt cél, de a korai időszakbeli parancskészlet egy az egyben a HP-UX-os neveket használta. (Mondjuk ma már vannak "modernebb" parancsok.)

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Olyan Dézsa Wu (tudod: a kínai mosodás) érzésem van, mint amikor 89 éves anyukám meséli, hogy elment az orvoshoz ... és negyed óra múlva felébredek, mikoris visszafelé úton már a harmadik barátnőjével találkozott, de hogy mit mondott a doktor úr még nem derült ki. Ilyenkor szoktam elég tiszteletlenül -  de végülis az én anyám - megkérdezni: És milyen színű zokni volt rajta?

Így aztán megtudtuk, hogy minden rendszer diszkkezelése öléggé hasonlít egymáshoz, hiszen egyik sem hívja a diszk - bármekkora is legyen is darabkáját Félliteres Szódás Málnaszörpnek. Valamint minden (hagyományos) diszk rendszer IS pörög.

A há-pux külön említést érdemel: Hallottam, hogy a HP diszkkezelése olyan szar volt, hogy javításképp vásárolt egy 3rd party megoldást.

(Egyébként rossz helyre írtál.)

És tényleg sokat segít a problémák megoldásában, ha valaki tudja mit is takar az AIX betűszó. :-D

Itt meg csak arról beszélgettünk, hogy egy AIX alatti diszket pécé-linuxba dugva 2003-ban látszik-e a JFS?

A korrekt válasz jó 6 órával korábban megérkezett.

Látom, hosszan csak írni szeretsz, olvasni nem. Akkor röviden:

- arra válaszoltam, ahol azt írtad, hogy az AIX kötetkezelője másféleképp kezeli a diszkeket, mint mások

- erre írtam, hogy nem, ugyanis HP-UX-on és korai Tru64-en pontosan ugyanaz a szoftver  fut(ott), a linuxos LVM meg annak újraimplementálása.

Ennyi.

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

( rpsoft v | 2023. 01. 18., sze – 09:29 )

Azt hinném, hogy elég niche cucc: egyrészt azoknak lehet hasznos, akiknek valami IBM-cuccot kell működtetni, vagy onnan átvinni dolgokat Linuxra. A másik, hogy tud case-insensitive mountot, ami szintén lehet valakinél legacy cucc. Ha kicsi, és nem nagy macera életben tartani, akkor nem azt kellene nézni, hogy hányan használják, más FS-ekkel összevetve, hanem hogy hányan használják úgy, hogy arra a célra nem jó egy másik.

Ami nem kezdőknek szól és ennyire niche, azt szerintem ki lehet (sőt, megkockáztatom kell) venni a kernelből. Mert ettől még modulként fordítható és ez a célközönségnek nem hinném, hogy probléma. Meg persze készíthető csomag is belőle (akár forrás alapú, pl. akmod-* csomagok) vagy precompiled bináris is.

Az ilyen userek száma valószinüleg elenyésző. Akinek mégis kelleni fog, az sincs lábon lőve

- használ olyan distrot, amiben még benne van

- használ bármilyen distrot olyan long support kernellel, amiben még benne van

- használ bármilyen distrot és olyan kernelt fordit, amiben benne van, akár mert régi, akár mert visszapatchelte magának

 

Az esetleges eltávolitás azért történik, hogy a karbantartó ne szöszöljön olyasmivel, amit szökőévente egyszer használ 1 valaki.

Természetesen ez a kivezetés csak a kerneldrivert érinti. Userspace szoftverrel továbbra is felcsatolható lesz, legfeljebb bootolni nem lehet róla (vagyis lehet még jó sok évig, egy régebbi, de még támogatott LTS kernellel). Én sose használtam, nem ismerek olyat, aki használná, de tőlem elférne, ha megtartanák, állítólag a kódbázisa nem valami nagy. Ha kiveszik, akkor sem fog hiányozni. Kicsit olyasmi, mint a floppy driver esete volt, az se kért sokat enni, kb. 5k soros a driver a kernelben, amúgy is feature complete, sok fejleszteni és karban tartani való nincs ezeken. Tényleg eltörpülnek a modern GPU driverekhez képest, ami kb. több millió sorosak.

Reisert se használtam, de kicsit elhamarkodottnak tartom, hogy kiveszik. Főleg, hogy van fejlesztő, aki karban tartsa, és csak polkorrektkedésből vezetik ki, Hans Reiser rossz neve miatt. Nem kéne, hogy a személyes múltja érintse a szakmai eredményének a megítélését. Azt is elismerem, hogy nem valami sűrűn használt, de ha eddig elfért a kernelben, akkor miért ne. Így is van még benne egy csomó alig használt, régi fájlrendszer, meg 30+ éves ISA és PCI kártyás hardverek támogatása, amit kb. senki se használ már. Ha azok elférnek, akkor ezek is.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

A ReiserFS akkoriban már készen volt, a kernel része volt és nagy disztribútorok alapértelmezett fájlrendszerként szállították. Így bukásról nem beszélhetünk.

A Reiser4 az, amiről beszélsz. A mai napig nem került be a kernelbe és már valószínűleg nem is fog.

Hans Reiser was convicted of murder on April 28, 2008, leaving the future of Reiser4 uncertain.

trey @ gépház

Tényleg, a Reiser4 várt beolvasztásra. Köszönöm.
ReiserFS volt nekünk is akkoriban, már nem is emlékszem milyen disztró alatt.

Azért ez mégiscsak gáz imho, hogy azért lett omitted, mert Reiser megölte a feleségét. Nem éppen egy technikai érv. Legalább reinkarnálhatták volna.

Ha azok elférnek, akkor ezek is

Ha jól értem pont azért akarják kidobni, mert a kernelen belül is deprecated API-kat használ és nincs aki átírja újra.

Userspace szoftverrel továbbra is felcsatolható lesz

Biztos vagy ebben? Én nem találok Fuse-os implementációt hozzá. Van egy recovery tool, amivel dumpolni lehet a fileokat belőle (ha valaki belefut egy régi gépről ilyenbe és adatot kell menteni róla), de ezzel mountolni nem lehet. A retro-fuse-ban sincs támogatás rá, de mondjuk nekik legalább profilba vág, el tudom képzelni, hogy miután a kernelből kidobják, esetleg ebbe a projektbe felveszik.

Régóta vágyok én, az androidok mezonkincsére már!

( _ventura_ v | 2023. 01. 18., sze – 09:35 )

Csak 1 maradhat ext4 :P

Fedora 38, Thinkpad x280

( XMI | 2023. 01. 18., sze – 10:44 )

Régen 486-oson használtam, gyenge gépen ez volt a leggyorsabb journaling fájlrendszer.

Viszont sok kis file esetén borzasztóan darálta a HDD-t, kb semmi write buffering nem volt, minden elemi művelet után azonnal seekelt a journalbe íráshoz. Erősebb gépen, már nagyon lassú volt az ext2/3 később 4-hez képest.

Régóta vágyok én, az androidok mezonkincsére már!

Én is kísérleteztem vele, kerestem journaling rendszereket, az ext3 valamiért sose tetszett, a reiserrel nekem voltak problémáim, úgyhogy kipróbáltam a jfs-t is, de teljesítményben gyenge volt. Mostanában vegyes a rendszer, a boot ext4, a többi xfs, illetve egy partíción btrfs van.

Bizony, így jársz, ha egy Ferrari motort szerelsz a Trabantba. :-D El se tudsz indulni, mert csak kipörög a kerék. Utána meg elrepül a motor, mert leszakította magát a felfüggesztésről.

Ha a loglv strategy = outer middle lett vón, akkor hangolhatnánk tovább. Ja, hogy ebben a cuccban mindhárom fogalom ismeretlen a linuxban?

Egyszer egy mbox backupot kellett visszatöltenem, csak a kolléga nem hagyott elég helyet az apró ssd-n. Felpróbáltam az összes linux fs-t, és hangoltam is, hogy minél több apróság felférjen, de nem fért. Ekkor csináltam jfs-t, és visszatöltöttem. Ennyi. Hasonló tulajdonságokkal bír az ext4 is (az apró fájlt az inode-ban tárolja), - azaz 2 helyett csak 1 seek kell, - de ennek ellenére nem tudtam úgy hangolni, hogy elférjen a mentés.

Őszinte legyek, nem teljesen értem a hasonlatodat. Mi itt a Ferrari és mi a Trabant? A 486-os gép? a HDD? a JFS? Vagy az újabb gép (kb P3 lehettett), amin a JFS már nem ment olyan jól? Vagy ez egy Linux vs AIX flame akar lenni? :)

Egyébként emlékeim szerint (nincs most éppen előttem), linuxos LVM-el is meg tudod oldani, hogy a physical volume-on belül egy bizonyos helyre tegye az extent-eket. Lehet, hogy fapadabb módon, mint az AIX-ban a loglv strategy, de eléred ugyanazt vele. Csak amióta a HDD-t kb backup/archívum szintre száműztem, az SSD-nek meg mindegy, már nem vacakolok ilyen short stroking és hasonló trükkökkel.

Régóta vágyok én, az androidok mezonkincsére már!

(Vajon miért mondják, hogy rossz hasonlataim vannak? :-))

A JFS nagyágyú, de ha kiegyensúlyozatlan hardverre rakod, akkor ilyen meglepetés érhet. Különösen a hardver pontos ismerete és hangolás nélkül. Hogy flame vagy sem, nem tudom. Ha kirakós játékot szeretnél, hát válaszd a linuxot! Nekem úgy tűnt, hogy az operációs rendszerhez két körben optimalizált cpu és az ezzel harmonizáló diszk és memória általában verhetetlen. Az is egy kis poén volt, amikor az Oracle az IBM CPU-ra megszorozta a licencdíjat kettővel, mert ugyanahoz a teljesítményhez feleannyi is elég volt. ;) Sajnos se 486, se P3 tapasztalatom nincs. Egy esetben morgott a megrendelő, amikor ugyanaz a rendszer SCO, P2 750MHz-hez képest az AIX, PowerPc604-100 MHz-en 3x gyorsabban futott. Belegondolni is rossz, ha intenzív diszk használattal is párosult volna.

Az utóbbi gép egy olyan volt, amin még a Windows NT + Oracle is "szédületesen gyors volt" - legalábbis így hallottam.

linuxos LVM-el is meg tudod oldani, hogy a physical volume-on belül egy bizonyos helyre tegye az extent-eket

Én nem találtam, de a nálam rengetegszer okosabb kolléga sem. Pedig elég fapadosnak tűnik.  A képen látható két paranccsal listázható, hogy a stratégiának mennyire felel meg az logical volume elhelyezkedése, melyik sávban hány eleme található és az egyes másolatok (tükrök) logikai -> fizikai elhelyezkedése. Az utóbbi a MAPFILE tartalma, amely alapján akár el is helyezhető az előre tervezett helyre az ojjektum.

A JFS durva write seekelései ellen én egyfajta hardvert tudok elképzelni: battery-backed raid vezérlőt. Ezen a short stroke-olás nem segít.

A linuxos LVM-nél az lvcreate-nél (+pvmove és talán még 1-2 parancsnál) utolsó pozicionális paraméterként meg tudod adni fizikai volume-ot is, hogy mire allokáljon (ha nem akarod, hogy magától válasszon), és annak van egy olyan szintaxisa, hogy physical-extent-eket tól-ig tartományokban ki tudod jelölni. Illetve ha csak egyiket adod meg, akkor elejétől kezdi, ha csak a másikat akkor a végétől. A man oldalról:

a PV positional arg generally accepts a suffix indicating a range (or multiple ranges) of physical extents (PEs). 
When the first PE is omitted, it defaults to the start of the device, and when the last PE is omitted it defaults to end.  
Start and end range (inclusive): PV[:PE-PE]...  
Start and length range (counting from 0): PV[:PE+PE]...

Van ezenkívül még egy --alloc paraméter is, amivel lehet ilyen contiguous | cling | cling_by_tags | normal | anywhere | inherit policy-ket megadni.

El tudod érni vele ugyanazt, amit az AIX-os LVM policy-vel, de lábbalhajtós. Őszintén szólva meg kellett néznem a man oldalt, mert annyira régen fordult elő, hogy ilyen szinten kellett belenyúlnom, hogy csak kb arra emlékeztem, hogy lehetséges. Pedig régebben csináltam VMware infra alá linuxos iSCSI szervereket, de kifejezetten ritka volt, hogy akárcsak pvmove-ot kelljen csinálni. Sosem éreztem hiányát ezeknek a policyknek.

Ami viszont teljesen off: nekem meg sajnos olyan tapasztalatom van, hogy egy 3.8GHz-es Power6-os blade (JS12) milyen brutálisan vérzett el egy 2 GHz-es kb Nehalem-szintű Xeonos blade-del (HS22) szemben, java-s alkalmazás alatt. Kb 2x, de lehet, hogy 3x volt a Xeon gyorsabb. Nyilván az IBM saját java-ja nagyon szarul volt optimalizálva power architektúrára. De hát pont ez lett volna a lényege az IBM-es - a te szavaiddal élve harmonizált - ökoszisztémának, ahol a harver, az OS és az alkalmazás runtime is ugyanattól a vendortól jön és összecsiszolt egységet alkot. :)

Régóta vágyok én, az androidok mezonkincsére már!

A JFS durva write seekelései...

Szerintem nem lehet ennyire katasztrofális a dolog. Lassanként 30 éve írok olyan backup rendszereket, amelyekben scriptből lockolok. Az első verzió még awk-ban készült 1993-ban. ;)

  • A file lockolásához létre kell hozini egy exkluzív lockfile-t.
  • A paraméterfájlt beolvasni és írni, módosítani vagy törölni a megadott paramétereket.
  • A módosított fáljt kiírni.
  • A lockfile-t törölni.
  • A konkurrens processz közben vár a lockfile eltűnéséig.
  • Mellette hasonló megoldással íródik kétféle (tranzakció) log is.

Ez a korai verzió roppant módon terheli a diszket. Természetesen azóta több ráncfelvarráson esett át, mert olyan rendszer is készült, amely ~150 munkaterületen, 22 szerverről,  1..17 fájltípust ment 5 perces periódusidővel. A nettó tárhely 30 TB és 95 M processz fut naponta. Itt nem lévén jfs, helyette ext4 az áldozat - ami majdnem olyan jó, mint a jfs. Értelmes sebességre hangolva kötelező a szünetmentes!
Ilyen tranzakció mennyiség mellett (meg a backup szerverhez) nem opció az ssd. Számitásaim szerint ebben 3 havonta lehetne cserélni - egyszerűen nem erre készült. Bár egy ifjú titán azt is kitalálta, hogy backupoljuk ezt a backup szervert a felhőbe.

Tudomásul kell venni, hogy a biztonság a sebesség rovására megy! Egy RDBMS esetén, AIX-en a tükrözés mellé érdemes beállítani a diszkcsatoló működést (akkor tér vissza a write, ha az összes csatoló végzett), és a Mirror Write Consistency-t (a lp tükrök szinkronját is naplózza a 0. track-en). Az ilyen beállítás eredménye a 8x lassabb működés.

Barátunk az ellllemes cache, bár rémlik, hogy Oracle esetén ki kell kapcsolni, mert az ilyet szereti maga intézni. ;)

Némi körökkel, de csak igen lassan jutunk el a "durva seekelésekig". ;) Az AIX alapértelmezett sorrend (a teljesség igénye nélkül), a diszk szélétől befelé: /,  /usr, jfslog, /data, /var, stb. Az ilyen sorrend lehetővé teszi, hogy a diszk elevátorozás közben oda-vissza lepottyantsa a bejegyzéseket a jfslogba. Viszont a seek csak az egyik lassító tényező. Egyszer régen kis update-eket játszottunk át egyk helyről a másikra. Aztán néhány napra megállt a küldő rendszer, majd pótolta az elmaradást. Az AIX még csak megbírkózott a >50000 küldeménnyel 1 dirben, majd utána a nyomorultak be akarták tölteni excel táblába. :-D Hasonló (a fenti rendszerhez kapcsolódó) eset, mikoris a kolléga feltalálta a kontent manágert! Az egyszerűség kedvéért NxNxNxNxN struktúra alá helyezte a tárolt fájlokat, mert úgy könnyebb keresni és a directory terhelés is kisebb. A végén a napi termést külön tárolták és éjszaka pakolták bele a nagy tárba. Így gyorsabb lett a rendszer. (nem) Végeztem méréseket különböző Windows verziókon és mindegyiken hasonló eredményre jutottam: A MS által bevallott hiba miatt komoly sebességcsökkenés és permanens cache degradáció következett be. A teszt környezetben többszöri boot után lehetett csak a fát végigolvasni. Éles üzemben mérem a lekérdezési időt. Ha túl nagy, akkor azonnal tizenhatodolom a feladatot, hogy dolgozni is tudjanak a szerveren. Érdekes, de 12 év alatt még nem tették fel a kérdést: A 120 szerverről származó adatokat hogyan kezelem? :-DDD És nem csak tárolom, hanem elő is veszem 0 idő alatt. Ugyanitt brutális mennyiségű log is keletkezik. A periódusidő alatt a max, 1 sortól a határ a csillagos ég. (Mekkora a log sor maximális mérete? ... Ja, elfelejtettük korlátozni! - Majd később kaptam egy MS specifikációt: A string hosszát a diszk mérete határolja. / Mennyi log keletkezik egy adott idő alatt? ... Ja, azt az új opciót elfelejtettük kikapcsolni! (A szerver felborult...)) A logok gyűjtése min. 1:600000 dinamikus sebességgel megy.

Ha úgy tűnik, hogy a jfs túl sokat seekel, akkor hangolni kell. Ha ez nem elegendő, akkor nem alkalmas a feladatra. Valószínűleg más fs sem lesz lényegesen gyorsabb (hasonló biztonság mellett), mert végülis a diszk a szűk keresztmetszet. Az diszk alrendszer egy adatbáziskezelő rendszer. Mindössze át kell szervezni a feladatot, hogy illeszkedjen hozzá! Ha ki tudod választani az fs-t a feladathoz, akkor nem is komoly a feladat. ;) Az összes többi esetben gondolkozni kell!

A linuxos LVM egészen jól néz ki. Kérdés, hogy 12 éve is ugyanezt tudra-e? Ha odaérek ki fogom próbálni. Ha több soros is lehet akkor teljesen hasonlít az AIX MAPFILE megoldásához. Itt egy hármas tükrözésű DNS spirál (és nem beszélünk arról, hogy mi értelme;)), az lslv -m kimenete. Itt az is világosan látszik, hogy a tükör nem az fs-re, hanem az LP-re értelmezett.*

LP	PP1	PV1		PP2	PV2	PP3	PV3
0001	0030	hdisk0		0030	hdisk1	0030	hdisk2
0002	0031	hdisk1		0031	hdisk2	0031	hdisk0
0003	0032	hdisk2		0032	hdisk0	0032	hdisk1
0004	0033	hdisk0		0033	hdisk1	0033	hdisk2
0005	0034	hdisk1		0034	hdisk2	0034	hdisk0
...

Mi ennek az értelme? Először a megfelelő sebességű zónára kerüljön a kritikus lv és pontosan arra a diszkre, amelyikre szeretném. Ilyen kritikus rész a fenti paraméter + lock + log terület, ahol 2 fs pontosan 1 LP-n helyezkedik el, amivel minimalizálja a seek mennyiségét. Az egyes zónák garantált sebességét a gyártó megadja - mivel itt csak scsi diszk elképzelhető.* A másik szempont a meghibásodás. Egy diszk meghibásodásakor szeretem tudni, hogy pontosan mi van rajta. (És ezzel abszolút nem vagyok egyedül.) Segít eldönteni a kockázat felmérését és a javítás módját.

Nem én üzemeltetem ezt a rendszert, ezért a legutóbbi diszk hibánál valóságos kis projekt indult a "mi hol van" meghatározására. :-D Korábban megvizsgáltuk az adatnövekedés trendjét és 2-3 évre kiszámoltuk az új konfigurációt. Utána meg úgyis diszkeket kell cserélni, általában nagyobbra. AIX-en pontosan ezért talán kétszer használtam a migrateXX parancsot, mert minden előre ki volt számolva.

*Itt mindjárt két olyan tulajdonság szerepel, ami miatt nem az egyszerű pc konfigurációra való a JFS.

A java és az IBM helyzetérŐl ;) csak annyit, hogy a 19 éves pályafutásom alatt nem volt olyan gép, amire felraktam volna. :-D (Egy esetben kellett valakinek, de az kapott egy pécét, hogy ne szennyezze a környezetet.)

Ilyenkor egy bölcs IBM-es kolléga mondását szoktam idézni, miután áradoztunk egyet a POWER nagyszerűségéről: Az IBM még nem gyártott olyan processzort, amin kielégítő sebességgel futna a java. :-DDD

Ennek ellenére nem túl hihető, hogy egy Xeon megvert egy Power6-ot. Valószínűleg nem volt más sem optimalizálva. Mondom, amikor itt írtam, hogy egy 100+ órás futásidőt átreszeltem 2 órára. Az elsőt az IBM szállította. ;) Hidd el, nincs az a gyors CPU vagy ssd, amire egy profi szoftveres ne tudna tetszőlegesen lassan futó programot írni!

Őszintén, miről akarsz meggyőzni? :)

Kb ha minden máshogy lenne felsetupolva, akkor más lenne az eredmény? Ebben nem kételkedem.

Az én tapasztalatom annyi volt, hogy PC-n, mindenféle underlying mágia nélkül, a JFS akkor volt a leggyorsabb az elérhető filerendszerek közül, ha a CPU volt a szűk keresztmetszet. Ha már a CPU volt erős és a HDD "átlagos", akkor az ext* filerendszerek voltak jobbak. Ennyi és nem több.

Lehet workaroundolni ezeket a limitációkat? Bizonyára igen.

Én úgy vagyok vele, hogyha egy filerendszer alá már annyi tuning kell (dedikált journal log device, stratégiailag kijelölt helyre az eszközön belül stb.), mint mondjuk egy Ceph vagy egy ZFS alá, akkor nyújtson is annyi plusz szolgáltatást.

"A java és az IBM helyzetérŐl ;) csak annyit, hogy a 19 éves pályafutásom alatt nem volt olyan gép, amire felraktam volna." - Akkor boldog ember vagy, IBM cuccokkal foglalkozol és Tivoli termékeket nem kellett soha telepítened. Amikor nekem még közöm volt ilyesmihez, szinte mindig az IBM saját java-ja volt a supportált JVM.
"Ennek ellenére nem túl hihető, hogy egy Xeon megvert egy Power6-ot." - néztem én is egy nagyot. Viszont az én nevem nem Teve, úgyhogy nem igazán volt kapacitásom megpróbálni ráhegeszteni más JVM-et AIX-re, hogy kiderüljön, hogy tényleg az volt-e probléma. :)

Régóta vágyok én, az androidok mezonkincsére már!

Én?! Semmiről.

Nálam ez életforma. :-D

És most nem megsértődni!!! Ez olyan egyszerű vindózjúzeres hozzáállás. ;) Még a unix előtti rendszerek is arról szóltak, hogy az oprendszert és a hardvert össze kell lőni. A unix meg különösen alkalmas rá. Hogy melyik fs a gyorsabb az függhet attól is, hogy a disztrót készítő / tesztelő csávónak milyen gyors hardvere volt.

A CPU erős meg a hardver átlagos stb. az szép, de mi volt a feladat a villany fogyasztásán kívül?? Tudom, is az átlagos volt. ;) És ha a feladat ilyen vagy olyan és megfordul a sorrend?

Mellékesen olyan rendszereket írtam, amelyeknek 24 óra a ciklusideje. Mennyi a jó érték, mondjuk 23:59? Nem, az üzemeltetési körülményeket ismerve < 3 óra. A feladat adott, a talpam alatt ott fütyül a bolti áron 90 M árú két szerver. Szerinted vetessek nagyobb gépet, mert miután kivettem az AIX lemezt nem csinált semmit?

Abszolút nem mellékesen, éjjel nappal szeretnéd lesni, hogy mikor fut már le, vagy kiszámolod, beállítod és utána ki se jössz a kocsmából. :-)

Szóval egy gép adott feladathoz igazítás nem workaround, hanem a feladadat megoldása. Elvégre nem én húztam madzagon a gépet, nem én számoltam a CPU helyett, hanem csak az elvégzendő a feladathoz igazítottam. Nem is trükköztem, mert a specifikáció szerint elegendő voltt a gép sebessége.

Az "annyi tuning" csak a munkám része volt, de ez nem zárja ki azt, hogy sokan nem is tudták mit csinálok, nem értettek hozzá vagy nem érdekelte őket.

A fent emlegetett backup rendszer sem hobbiprojekt, hanem a cégekkel szerződésbe van foglalva a maximálisan 10 perc adatvesztés.

Mit látod, nem a Tivoli volt a főcsapás iránya.

A java kapcsán elmodtam a véleményemet. Ismerek olyat is, aki ért hozzá. ő biztosan röhögne egyet, elfordítana egy tekerentyűt és minden hasítana. És nem csak IBM platformon. Mellesleg hekker volt az egyetemi évei alatt - ebből élt. A véleményét viszont eleget halgattam, amikor külsősökkel kellett dolgoznia. Valószínüleg nem csak a tuninghoz, hanem a java tisztességes használatához is érteni kell. És talán nem is a JVM volt a probléma. De ez ügyben igazán nem tudok komoly véleményt mondani.

de mi volt a feladat a villany fogyasztásán kívül?? Tudom, is az átlagos volt. ;) És ha a feladat ilyen vagy olyan és megfordul a sorrend?

Réges régen egy távoli galaxisban, kb a telefonos internet vége és az ADSL korszak eleje környékén, még ráértem játszogatni dolgokkal és volt egy - már akkor is régi - 486-os gép itthon. Ez volt az otthoni router, letöltőszerver, NAS, minden. Ezen tanultam meg egy csomó minden alap dolgot linuxból. Akkoriban ráértem benchmarkolni filerendszereket és a jfs jött ki legjobbnak. Ha már villany fogyasztás, igen a gépnek ez lett a veszte, pár év után le lett cserélve egy WRT54G-re (és így jöhetett az openwrt :) ).

Ebben az időszakban kb P3-as lehetett a desktop gépem, és mivel ráértem kísérletezni disztribúciókkal is, pl Gentoo-t is próbáltam. A korábbi tapasztalat alapján gondoltam, biztos a JFS lesz a leggyorsabb a sok buildelés alá. Hát nagyon nem volt az, megdöbbentem rajta, hogy ext3 (talán akkoriban az volt a latest) mennyivel gyorsabb és csendesebb a gép vele.

Az AIX sokkal később került képbe. Eleinte még motivált is kíváncsiság, de viszonylag rövid idő alatt megutáltam. Úgyszintén a Tivoli cuccokat. Annyira mindenesetre megtanított, hogy IBM terméknél _nem tuningolunk_, _nem hekkelünk_, hanem pontosan mindent úgy csinálunk ahogy a doksiba le van írva. Minden parancsot, minden konfigfileba szerkesztést dokumentálunk, minden változtatás előtt snapshotolunk. És ha így sem sikerül még telepíteni sem (nem egyszer megtörtént - és nem saját hibából), akkor állunk neki nyomozni, meg belenyúlni dolgokba (normális esetben supportot tárcsázni, csak academic subscription-höz nem járt support, úgyhogy teljesen magamra voltam utalva).

Régóta vágyok én, az androidok mezonkincsére már!

NagyonOff: ez például Tivoli és Java egyszerre, fogalmam sincs, hogy milyen jócselekedetet hajt végre, nem is nagyon érdekel [de a futásideje elég impozáns, majdnem hét év]:

$ bs2stat -w 7471238
%PID:      7471238    PPID:  7012592    NOW: 2023-01-23.14:58:26
%USERID:   root       GROUP: system     ELAPSED:   2232-01:36:17
%STATION:  -          PRI:   60 20      CPU-USED:       19:29:22
%SIZE(KB): 100104     %MEM:  5.0        %CPU:  0.0
%STATE:    A Active                     WCHAN: *
%CWD:      /var/opt/tivoli/ep/runtime/core/
%CMD:      /var/opt/tivoli/ep/_jvm/jre/bin/java -Xmx384m -Xminf0.01 -Xmaxf0.4

Egy lényeges különbség van az evolúciónkban. ;)

Ha munkavégzés akkor assembler ('83-tól), mert hardvert fejlesztettem. Ehhez először a Videoton ún. "* promptos" rendszerét (8080 3MHz), majd DOS+I80 (Intel Isis-II emulátor, V20 CPU) párhuzamosan Enterprise 128-at - nálam 768 :-) - használtam. Utána DOS + Turbo Pascal (persze assembler is), majd SCO. Utána jött az AIX ('92-2012), amihez a linux csak sokképernyős konzol volt.  Közben egy közepes irodai rendszert is raktam össze linuxon 2002-ben, a még ma is működő backup rendszert 2008-ban. Később visszamentem az elhagyott hardveres pályára - most is éppen egy motordiagnosztikai műszert tákolok, talán ma kerül gyártásba. Windowst először 2000 után láttam. Nagy segítségemre volt az a szemléletmód, hogy ez csak egy selejtes AIX. :-D Mindenesetre, a fiam 2 számmal olcsóbb gépei soha nem voltak lassabbak a haverokénál! Első pont: Windows (szerver, de ez mindegy) hangolásának a tökéletes leirása természetesen az IBM kiadásában olvasható. :-)

A '95-ben vásárolt munkagépet (PPC 604 100MHz) 2004-ben egy p615 követte (POWER 4+ 1GHz). Mellé egy VIA C3 alapú linux teszt és stb. szerver + sok putty ablak. A linux előszor (főként a flopis korszakban) slackware, opensue, jelenleg CentOS -> Rocky. (Az utóbbi kettőhöz van profi telefonos segítség.) A "desktop" Windows XP/SP2, majd Windows 10 Enterprise N LTSC. Mindkettő erősen kiherélve az nlite és ntlite segítségével. Szóval egy feketeöves vindózos rengeteg dolgot el se tud indítani rajta. :-D

Az "IBM termékekről" annyit érdemes tudni, hogy rengeteg vásárolt van  köztük, tán a Tivoli is ilyen (vagy csak a Lotus?). Ezeket általában a saját képükre formálják és kiváló dokumentációval látják el. A "nem tuningolunk" nem igaz, ha a dokumentáció egyébként lehetővé teszi - csak érteni kell azt, amihez nyúlsz.  Az IBM stratégiája mindig az volt, hogy ad egy működéshez elegendő template-szerű valamit, amiből az user szabadon kialakíthatja a számára megfelelő működést. (És ezt nem én találtam ki!) A "hekkelés" (eltekintve az agy nélküli belepiszkálástól) - az előbbiek alapján - működhet. Készítettem pár olyan megoldást, ahol a nyomatékosan előírt dolgokon változtattam. Az AIX tényleg optimális rendszer bármire, hangolni is lehet. Ennek ellenére van olyan konstelláció, amivel az alkotók sem  találkoztak. De sikeres csak akkor leszel, ha kellő mértékben átlátod a rendszert. Ám legyen büdös öndícséret, én mindig sikeres voltam. (Akkor még...;)) Sőt, az IBM a jó megoldásokat beépítheti a saját rendszerébe.

Három "fiatalversenyzős" sztori:

Öreg ibmes kiírja a firmware upgrade flopit és a f.v. kezébe nyomja: Ezt kiviszed, bucko kezébe nyomod. Aztán qrvára figyelsz!

Support hívás, f.v. veszi: Egy pillanat! - (félre) Bucko telefonál, egész napra meglesz a munkánk. (Mondom: f.v., tévedett! Az egész csapatnak 2 hétre megteremtettem a munkalehetőséget. ;))

Support hívás, f.v. veszi, detektálja, hogy én hívom: Várjál, adok egy öreget. - Nem kell! Még te is érteni fogod: Az operációs rendszerrel nem kompatibilis szoftvert szállítottatok. (Az egyik öreg letöltötte nekem a szlovén fejlesztők által fél órára ftp szerverre kihelyezett, még meg sem jelent verziót. Még meg sem jelent, de már eladták! :-D)

A poénkodást értelmezve: Ha már felemeltem a telefont, akkor a supportnak sem volt könnyű. Vagyis a megoldhatatlanon kívül sikerült mindent önerőböl megoldani. Ehhez csak a dokumentáció alapos ismerete, türelem és némi idő kell. Az utóbbi persze kulcskérdés lehet.

A hibás telepítő hibája sajnos egy elég szokványos jelenség. Erre szoktam mondani, ha a te gépeden (bármi is) megy, az mackósajtban.. Nekem az éles rendszeren _működnie kell_!

Én most ide nem írnám le a teljes szakmai pályafutásomat, mert már így is borzasztóan off. Nekem PC XT volt az eleje, óvodás koromban, általános iskolás első-második környékén gwbasic-ben már próbáltam írkálni dolgokat, bár utólag belegondolva valószínűleg nem sokat érthettem belőle, hogy mi miért történik. Iskolában számtech szakkörön volt TV Computer (ha már a Videoton vonal emlegetve van), meg C64. Linuxozás kb 98-99 környékén kezdődött nekem. 2002-2003-tól kezdve Linux Desktop éve van nálam. :D Nem vagyok már én sem fiatal.

Én azt látom, hogy két fő járható út van egy enterprise termék előtt:
1. kész lehegesztett dobozos termék, ami felrakod és működik, ahogy a gyártó elképzelte
2. legókészlet, amiből saját magad építesz dolgokat magadnak

Helyesen úgy képzelném, hogy legjobb, ha maga a termék üzemeltetése az 1.-es kategória lenne, utána felhasználói szinten nyilvánuljon meg a 2. kategória. Így lehet keverni a kettőt, máshogy nem.

Ha már a termék üzemeltetése is a 2. kategóriába esik, akkor rendelkezésedre áll ezer meg ezer free/opensource projekt (amihez milliószor több tapasztalatot és segítséget találsz a neten), amiből lehet legózni. Én úgy gondolom, hogy az added value az kéne legyen, hogy a terméket működésre bírni ne igényeljen pilótavizsgát. Azért fizetsz ki egy raklap pénzt licenszdíjra.

Az én meglátásom szerint az IBM sok termékével a két szék közé leesett a padlóla. De dulván. A Tivoli-család (önmagában is több tucat összevásárolt cégből összehozott erősen heterogén termékcsalád) egyértelműen ez a kategória. Nehéz telepíteni, nehéz üzemeltetni. A Lotus Domino (ahogy mi hívtuk: Lotus Domina) dettó ugyanez.

Én még sosem futottam bele olyan hibába, amire a doksi szerint a troubleshooting guide-ban ne az lett volna a resolution, hogy "Contact IBM Support". Supportware. Persze meg tudod oldani... ha már az strace/ltrace/ld piszkálások után a java decompiler-t is előveszed és megpróbálod megérteni, hogy mi a fene megy félre. Aztán az a vége, mint amikor Kocsis Zsolt (az IBM Tivoli üzletág magyarországi igazgatója volt anno), hív fel minket, hogy ugorjunk már át az infoparkba hozzájuk és mutassuk be nekik. Mert ők még nem látták ezt a terméket működni.

Későbbi melóhelyen ültem a support túlvégén is (mondjuk architect voltam, de a tech supportosak nagyon közel ültek hozzám, és pontosan tudták, hogy tőlem kell kérdezgetni :) ). Borzasztóan tudtam örülni neki, mikor hosszas huzavona után derült ki, hogy az ügyfél - dokumentáció szerint nem támogatott módon - belepiszkált a termékbe, ezt nyilván "elfelejtette" megemlíteni, hadd küzdjön a supportosunk vele, hogy rájöjjön magától. Az esetek jelentős részében amúgy volt kivezetett és dokumentált konfig opció arra, amit az ügyfél saját feje után belebarmolt - ez a jobbik eset. A rosszabbik, ha valami tényleg erősen unsupported dolgot akart csinálni és - mivel sokat fizet - oldjuk már meg neki, lehetőleg a vállalt defect resolution time-okon belül. Ja és persze hiába magyarázod az ügyfélnek, hogy ha most meghekkeljük, hogy valahogy menjen, azt sem a backup/restore, sem a HA failover sem a live/nem live upgrade folyamat nem fogja lekezelni és akár adatvesztéssel is járhat. "Az nem baj". Persze, most nem. Mikor eljön az ideje, akkor meg őrjöngve nyitja a critical ticketet, arra amire figyelmeztettük korábban. Sok esetben ez de facto "bújtatott feature request" volt, némelyikhez kellett volna fél év fejlesztés, ha a product management egyáltalán rábólint. Így próbálták kizsarolni, hogy csináljunk meg valamit nekik, amire nemet mondtunk - vagy csak későbbre volt ígérve a roadmapen.

Régóta vágyok én, az androidok mezonkincsére már!

Nem a szakmai pályafutás miatt írtam, csak az eltérő nézőpont miértjére próbáltam rávilágítani.

Az off ellenére ott sompolyog a JFS is; miért, hol és hogyan érdemes vagy kell használni.

Csak töprengek, mi az "enterprise termék", no meg a " kész lehegesztett dobozos termék, ami felrakod és működik, ahogy a gyártó elképzelte"? Ha felparaméterezek egy diszket, hogy az adott feladathoz optimálisan működjön az miért lenne legózás? Ha ötszázan használják a szervert, de csak én értek a diszkhez, akkor bizony én vagyok a pilóta. És ez így van rendjén, az utas ne vezesse a gépet! ;)

Úgy látom éles ellentét van a nézőpontjaink között, de majd jól elmagyarázom. :-D

Az 1. pontodnak megfelel a Windows. Ha azt enterprise környezetben használod, - mondjuk 10 doboznyit, - de nem a MS szállítja a szervert és a hálózatot, akkor ... legózol és / vagy free/opensource projekt? Vagy rendszerintegrátort (pardőőz achitektet) játszol? A világ nem olyan egyszerű, amit a két pontoddal le lehet írni.

Az sem mellékes, hogy a szemétdomb melyik sarkában játszol kiskakast. ;) Az én nézőpontom azért más, mert egy adott helyen (elméletileg), nem mindig egy időben, de gyakran átfedésekkel:

  • üzemeltettem
  • rendszerszállító voltam, ezen belül
    • a fő rendszerszállító alvállalkozójaként
    • strómanon keresztül (saját néven nem tehettem)
    • saját néven
    • saját néven, mint IBM alvállalkozó (társvállalkozó) (és regisztrált IBM beszállító)
  • rendszerintegrátor is voltam, mert a 1+6 rendszernek együtt kellett üzemelnie

Nos, akkor az 1,5 milliárdos rendszer ('95) az dobozos enterprise rendszer vagy lego? Az ilyen úgy épül fel, hogy több dobozos termék (vagy olyan féle, mert termék és van dokumentációja) + felhasználói igény + egyedi modulok integrációjával alakul ki az a termék, amire a szállító szerződött és a megrendelő fizet érte.

Az általam szállítótt 6 mellék- vagy alrendszer + a fő rendszer hangolása és automatizálása között létezett komplett rendszer is. Az ilyennek a következő a felépítése: dobozos szoftver (AIX) + dobozos szerverek ;) (POWER) + opensource (amiről később leszoktam) + saját szoftver + rendszerintegráció. Szállítás esetén az adott gépek adott feladatokhoz szükséges kialakítását elvégeztem. Az így elkészült rendszereket üzemeltetésre átadtam. Így aztán az általad emlegetett utólagos piszkálásra nem kerülhetett sor az üzemeltetők részéről. A dokumentáció is leszögezte, hogy a nevesített paraméterek beállításán kívül máshoz nyúlni nem szabad, mert ezek automata rendszerek.

Gondolom, az eltérő nézőpont forrása ezek után érthető.

Hálistennek a rendszereim bonyolutabbak voltak, mintsem belepiszkáltak volna. Egy esetben fordult elő, hogy valamit szerettek volna megcsináln. Jól van, beugrok és egy óra alatt kész. Ingyé'! Nem kellett nekik, mert ifjú titán megalkotta. Aztán elkezdtek cseszegetni, mert hibás a formátum. Ekkor egy kicsit mérges lettem és elmagyaráztam. Rossz időpontban, rossz helyről veszitek ki az adatokat, ezért nem stimmel. Ráadásul egy olyan ponton, ahol egy belső formátumot használok. (Közöd?!) A megfelelő működést úgy tudtam elérni, hogy ismertem a megrendelő szerződéseit is - nem csak az átadott specifikációkat - ezért nem lehetett belekötni a hibátlan működésbe. Ez ám a fekete doboz! Bemegy a specifikáció szerint és ki is jön. Ha vitatkozni akarsz akkor először tanulnod kell! :-D

Mi a "kész lehegesztett dobozos termék, ami felrakod és működik, ahogy a gyártó elképzelte"? Manapság úgy szokás mondani, hogy "Appliance". Kb mint a VMware cuccai, ESXi, vCenter, vCloud Director, NSX stb. Imageből indítod, felparaméterezed, megy. Nincs shell access-ed (csak "tech support" számára), vagy alapból valami restricted shell van. Persze alá lehet nyúlni, ha nagyon akarsz (sokan teszik, mikor unsupported desktop gépre telepítik), meg lehet teljesen elborult konfigokat csinálni. (Egyik kollégám Openstack-et telepített nested virtualizálva VMware infra főle - a hálózati debuggolást, ami az openvswitch és a vmware vswitch összeakadásából jött... mondjuk úgy hogy átértékeltem kb mindent amit a hálózatokról addig tudtam.)

A Windows ebből a szempontból bonyolultabb eset. Desktopon sok-sok ember elvan vele úgy ahogy a hardver gyártójától kapta. Vagy ahogy Next-Next-Finish módon felrakta magának. Különféle tweakelő toolokkal nem nyúlkálnak bele.  Jönnek rá a frissítések (ha akarod, ha nem). Az 1. pontot teljesíti. Persze lehet mélyebben belepiszkálni, meg "egzotikus" (alapból nem támogatott), vagy "bleeding edge" hardverekre felrakni, drivereket buzerálni, ez nagyjából a Véér István szint. Ha tényleg enterprise környezetben akarod, akkor jön az Active Directory meg Group Policy, Failover Clustering, Powershell, Windbg stb. stb. amihez tényleg egy külön szakma érteni. Tudod az 1.-es és 2.-es szinten is űzni.

Visszakanyarodok a JFS-hez. Mi a gondom vele: ugyanarra a feladatra van nála jobb alternatíva (nyilván, a JFS ~30 éves, nem lepődök meg rajta), és nem kell storage expertnek lenned, hogy optimálisan használd. AIX-on nem tudom van-e alternatíva, ott lehet, hogy ez a legjobb.

Volt dolgom olyan rendszerrel, ami valamelyest hasonlítható ahhoz, amiket leírtál. Ott Ceph volt a storage megoldás és ahhoz bizony tényleg nagyon komoly hozzáértés kell már a hardver megválasztásától és méretezésétől kezdődően. (El is volt baszva, annak rendje és módja szerint, hiába szóltunk, többszáz node-os Openstack clustereket szálított ki a cégünk azzal a referencia-konfiggal. Aztán jöttek vissza az ügyfelek a panaszokkal, hogy néha akár 30 másodperces IO latency is előfordul és a cloudon futó összes cluster egyszerre szétesik tőle. Én írkáltam PPT-ben a megoldási javaslatokat a managementnek - pedig nagyon nem az én dolgom lett volna.)

Csak ugye egy Ceph-es elosztott storage rendszer és egy lokális hagyományos fájlrendszer (mint a JFS), azért más-más komplexitású szolgáltatás. Én legalábbis nem örülnék neki, ha olyan lokális filerendszert kéne használnom, amihez olyan szintű hozzáértés kell, mint egy Ceph-hez.

Régóta vágyok én, az androidok mezonkincsére már!

Ilyen múlttal (SCO, AIX, 2002-től Linux, 95-től PPC, Power4, 2000-ig nem is láttál Windowst) el nem bírom képzelni, hogy miért ragaszkodsz mai napig deszktop vonalon a Windowshoz.

DOS + Turbo Pascal-t, meg DOS + Turbo Assemblert (meg MASM-et) én is nyomattam, de így visszanézve időpocsékolás volt. Linuxot csak 2012-2014 környékén kezdtem használni desktopra, előtte csak néha piszkáltam virtuális gépben, webszerveren, műholdvevőn, routeren, és csak x86-ot használtam. Már vagy 6 éve bottal sem piszkálnék meg desktop Windowst, egyszerűen nem csak ócska, meg időpocsékolás, de jövője sincs, egyértlemű, hogy áll bele a földbe. Gaming gépemen még van Win10, de tényleg 5 percet sajnálok vele foglalkozni, annyira értelmetlen használni akármire.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Pedig leírtam párszor, de most másik metszetet képzek:

Általában cmdline "felületen" dolgozom. Talán kivétel néha a képszerkesztés nyomtatott áramkör ellenőrzésekor vagy az áramkörök megrajzolása.

További kivételek, amik ugyanúgy mennek: vlc, firefox, ide (MPLAB, MPLAB X) - az előbbi nem is megy linuxon - és  a gputils.

A vindózon sok putty ablak nyitható. (*nix)

A linux alatt soha nem fog menni a foobar2000 és a DAC. (Ötleteket nem kérek, mert egy éve 2 hónapon keresztül azt játszottam: Márpedig most linux desktop lesz.)

Képes vagyok arra, hogy kellő mértékben kiheréljem és átalakítsam a Windowst, amitől stabilabb és használhatóbb lesz. Egyedü a file managerrel nem vagyok megelégedve, de abból semilyen rendszerre sincs igazi.

Ha script vagy C, akkor linux, freebsd vagy cygwin.

Szóval tizensokéve belakott infrastruktúrán dolgozom, minek váltanék? A munka tárgya gyakran "a gépen kívül van", minek szivassam magam?

DOS + Turbo Pascal-t, meg DOS + Turbo Assemblert (meg MASM-et) én is nyomattam, de így visszanézve időpocsékolás volt.

Lassanként 40 éve programozok assemblerben - és éppen most is. A DOS meg jó előkészítés volt a scripteléshez. A *nix munkáim 90%-a script, és ugyanazzal a technológiával dolgozom, mint assemblerben. ;)

Gaming gépemen még van Win10, de tényleg 5 percet sajnálok vele foglalkozni, annyira értelmetlen használni akármire.

Nekem még gaming gépem sincs. :-D A Windowst "használni valamire"??? Fut rajta a vim, a gputils, a firefox, stb., de "használni" nem szoktam. ;)