Száncsengő KATT-KATT-KATT...

Elég spontán jött SOS kérés telefonon: Egy céges belső FTP-n szerettek volna átméretezni particiókat, lehetőleg gyorsan(még aznap), rengeteg szöszmötölés nélkül és persze olcsón.

Kicsit több mint 2 TB adatról van szó, vigyek egy nem túl drága HDD-t amin elfér. Másolás-particionálás-visszamásolás után anyagköltség + pénzmag + "Vidd el a HDD-t, mert nekünk erre kellett csak..." haveri alapon jöttem el.

Sajnos túl naiv voltam... Úgy gondoltam a kék WD-nél alább nem adom. Elsiklottam az információ felett, hogy manapság a kék WD az gyakorlatilag a régi zöld, ami gyakorlatilag a fej folyamatos parkoltatásával végzi nem túl áldásos munkáját saját élettartama ellen.

Mit sem sejtve, éjjel erre ébredtem: Katt-katt....katt-katt... Volt már zöld WD-m, ismertem a hangot.

A WDidle3 természetesen nem ismeri fel a WDC WD30EZRZ-00Z5HB0-t. Pár óra Google után "legfeljebb tégla lesz" felkiáltással eresztettem neki a WD red-hez való WD5741-et, ami az újabb RED-ek kattogását hivatott megoldani úgy, hogy az Idle3 timert 300 sec-re állítja.
Erre a lépésre nem biztos, hogy szükség van, de simán megoldotta a feladatot, hogy visszaállítsa 300-ra az időzítést. Én egy "checkpoint"-ként használtam ezt a toolt, ha a japán program végleg eltéglázná, ezzel talán vissza tudom állítani az adott regiszter értékét.

Szóval mivel egy árva mukkot nem beszélek japánul(sajnos), viszont a hozzászólásokban egy hozzászólónak sikerült a művelet, ezért gondoltam rápróbálok erre:
https://translate.google.hu/translate?sl=ja&tl=en&js=y&prev=_t&hl=hu&ie…

3rd party cucc, de nekem simán kikapcsolta a parkolást, mindenféle fájdalom nélkül. :) Ahogy Borat mondaná: Great Success! :D

MD5sum-ok:
WD5741.exe : 24fce54c89bcc9b9fabd63e16954bb32
WDIDLE3_for_Windows_1.2.zip : 9d1f8dab40903c6e4887d7054491b29f

Nem tudom a WD5741 bármi mást csinál-e, mert nem ehhez a típushoz készült, de a HDD köszöni szépen, jól van. A japán cucc meg végképp nem tudom mit varázsol, szóval ezt a műveletet(vagy akár csak az imitálását) azért senkinek nem ajánlanám. Mindenki saját felelősségére bűvészkedjen! :D

Update: rev.: 80.00A80

( ricsip v | 2017. 12. 30., szo – 12:30 )

Fel nem bírom fogni épp ésszel, hogy nem basztak még rá a WD-re egy 10-20 Mrd $-os class action suite-ot emiatt a fejparkoltatós programozottan szántszándékos termék-tönkretétel miatt?????? Ekkora büntetésbe talán remélhetőleg megrokkant volna az egész WD egyik pillanatról a másikra.
--

Kicsit hasonló az iPhone-ok lassítása is. Amíg van ami mögé lehet bújni, addig nincs para :D Ott is economy, itt is economy... A gazdaságot meg pörgetni kell. Bár nem értem miért gondolják, hogy ez így jó. Ha valami tönkremegy, akkor a felhasználó biztos nem vesz mégegyszer olyan márkát.

( persicsb | 2017. 12. 30., szo – 15:48 )

> 2017
> HDD
> partíció-méretezés
Nincs több kérdésem.

Ha valaki egy darab / partícióba lomol mindent, annak tényleg tök mindegy, de ahol picivel szofisztikáltabb a tárhely kiosztása, netán több diszket kell "befogni" adatok tárolására úgy, hogy szükség esetén a legnagyobb diszk méáreténél nagyobb terültet is lehessen egybefüggő tárterületként hasnzálni (satöbbi), ott bizony az LVM megkerülhetetlen. Egy szervber esetén pláne nem illendő az LVM-et elhagyni - és ez igaz akkor is, ha egy fizikai kötete van az embernek: ha nem tölti fel induláskor a VG-t LV-kkel 100%-ra az ember, akkor hagy magának mozgásteret a későbbiekben felmerülő helyhiány kezelésére.

2017-ben legfőképp server storage-ra nem használunk olyan storage-ot, ami partíciókban gondolkodik, még Windowson sem, nemhogy *NIX rendszereken. Erre való az LVM, a ZFS meg minden más, ami storage.
Na meg HDD - max. archiválásra, mert amúgy lassú. Az SSD teljesen megfizethető dolog.

Ok, értem én. Viszont sok beleszólásom nincs. Családi vállalkozás, az ottani IT-s kolléga külföldön van szabadságon. Maga a HW majdnem 6 éves. Jeleztem, hogy lassan ideje volna cserélni, mert fájni fog, ha az amúgy totál kommersz PC ledobja a láncot. Erre az volt a válasz, hogy "Minek?! Óránként készül biztonsági mentés minden változásról..." Szóval fura a hozzáállás... amire nem muszáj, nem költenek egy fillért se :D

Azaz van támogató emberkéjük, aki épp nem érhető el, pont akkor, amikor k. sürgős a bőven csereérett hardveren olyan mókolást csinálni, ami adatvesztéssel, de minimum hosszaz oboázással járhat.
Az "óránként mentenek minden változás" az elég tág fogalom, én minden esetre nem nyúltam volna bele más munkájába - tessen megvárni az egyszemélyes supportot, hogy ráérjen, addig meg lehet az eftépéről takarítani, oszt' jónapot. Ha elég egy one-man-show támogatás, akkor nincs olyan sürgős feladat, ami nem várhat addig, amíg előkerül az illető...

Az ilyen cégeknek addig "minek" a válasza a frissítésre, hardvercserére, amíg be nem üt a crach, és lehet "térdre imához" indulással mentésből ( ha van...) visszaállni.

Olyan mentést, ami egyedüli másolata lesz az adatoknak egy ideig, legalább olyan megbízható tárolóra illik rakni, amilyen az eredeti adatkupac alatt volt/van, illetve olyanra, amivel a "műtétet" végző emberke kellő mértékben tudja végezni a nehezebbik felét - jelen esetben én mindenképp raid tükör, vagy kettő külön mentés iránmyba gondolkodtam volna.

Sokaknak itt _szerencsére_ fogalmuk sincs arról, hogy a kis családi vállalkozásokban mi megy. Nemrég jöttem el egy olyan helyről, ahol a tulaj utazgat, nőzik, a gyereknek "mindenből a legszebbet, legjobbat", de ha egy 2.000 forintos kábelt kell venni, mintha a fogát húznák.

Kis csaladi valallkozasokban altalaban minimalis nyereseg van, amit visszaforgatnak vagy a vallakozasba vagy a csaladba, peldaul vesznek egy uj zuhanyrozsat mert a regit egyszeruen megette a rozsda meg a vizko duettje.

Note: Itt most nem olyan csaladi vallakozasokrol vagyon szo, mint a Meszaros vagy az Orban csalad vallalkozasa
--
Blog | @hron84

Szerintem ez így nem állja meg a helyét. Sok családi, mikrovállalkozás van ma Magyarországon, amelyek kitermelik a család megélhetését, de annyi profitot már nem, hogy ettől változzon az anyagi helyzetük. Tehát a roló lehúzása nem megoldás, mert abból éhenhalás lesz, viszont így nem is gazdagodnak. Csak teszik a dolgukat, amihez értenek.

Nekik kell a munkához számítógép, de nem tudják és nem is akarják a sokkal drágább fajlagos költségű, ráadásul szerintem rövidebb élettartamú SSD-t megfizetni. Mellesleg mi az a műszaki érv, amely az SSD mellett szól a HDD-vel szemben? Az, hogy a szomszéd Pistikének az van a gépében, s az milyen menő, nem érv. Mint ahogyan az okostelefon mellett sem látok érvet, ha a cél pusztán telefonálás és rövid szöveges üzenet átvitele. A butatelefon tovább bírja egy töltéssel és kisebb.

Saját gépemben van SSD az oprendszernek, HDD az adatoknak, ez egy jó kompromisszum a gyors elérés, az olcsó tárkapacitás és az SSD-k véges írhatósága között.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ha nincs pénzük normális storage-ra, ami a céges, a cég működéséhez nélkülözhetetlen adatokat tárolja, akkor béreljenek tárhelyet meg szolgáltatásokat. Olcsóbb.
Műszaki érvek: nincs benne mozgó alkatrész, így nem érzékeny a mozgatásra, illetve poros környezetben is használható probléma nélkül.
Ezen kívül mivel nem mágnesség alapú, nem érzékeny mágneses behatásokra.
Ezen kívül a sebessége sokkal jobb.
Ezen kívül a fogyasztása sokkal kisebb.
De nyugodtan használjatok csak HDD-t tovább, és figyeljetek a fejparkolásra.
Amúgy megsúgom, a HDD is véges sokszor írható.

Lehet, hogy olcsóbb, de a felhő az másnak a gépe. Az adat meg az adott cégé.

Nincs benne mozgó alkatrész, ez igaz, de ez notebook-nál előny csak. Ezért tettem a notebook-omba SSD-t, így az egész gépben nincs mozgó alkatrészt, bátran mozgathatom működés közben. Mellékhatásként gyors is, de nem ez volt a szempont. Egy szervert miért kellene működés közben mozgatni?

Nehezen tudok elképzelni olyan nem szándékolt mágneses behatást, amelyre a levegő mágneses ellenállása valamint a HDD házának mágneses vezetése ne lenne elég jó megoldás. Amúgy az SSD érzékeny a radioaktív sugárzásra. Az mennyivel jobb?

A sebesség tényleg jobb, csak kérdés, számít-e ez egy kis, néhány fős cég életében bármit is. 5 ms lesz az elérés, s nem 0.1 ms? Jó, és?

Fogyasztás sem rossz, de nem eszik nagyon sokat egy HDD. Illetve annyira nem eszik keveset egy SSD. Néztem, magam is meglepődtem, nagyobb arányt vártam.

Ami a fejparkolást illeti, nem figyelek rá, megoldja magától. Utoljára talán 3.1-es DOS alatt kellett parkolópályára küldenem a fejet egy paranccsal. A saját gépem HDD-jében a fej gyorsulását állítottam kisebbre, így csendesebb lett a HDD. A gépem 9.5 éves, sohasem volt a HDD-vel bajom - 500 GB-os WD -, pedig igen sokat jár.

Jó, szó szerint semmi sem tart örökké. Gondolom, a HDD csapágya is feladja egyszer. Viszont eléggé kellemetlen, hogy az SSD véges számú alkalommal írható, ráadásul, mivel analóg módon tárol egy FET két vagy három bitet, akkor is újra kell írni néha, ha amúgy nem írnánk kívülről.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

A sebesség hogyne számítana.
Mondok egy példát: HDD esetén az élettartama alatt sok-sok értékes munkaóra megy el azzal, hogy "várunk a betöltésre, várunk a másolásra", azaz az IOWAIT-nek van eléggé komolyan pénzben mérhető költsége ám. És ezt sokan elfelejtik. Igazából lehetne 15 évvel ezelőtti CPU-val meg HDD-vel is dolgozni, csak akkor egységnyi idő alatt jóval kevesebb adatot tudnál feldolgozni (mert a 15 évvel ezelőtti CPU meg HDD ugyanolyan jó, csak többet kell várni rá), azaz a munkád hatékonysága jelentősen csökkenne. És ez pénzben kifejezhető.
Az SSD-HDD árkülönbözetet nagyon hamar behozza az, hogy sokkal kevesebbet kell várni az IO-ra.
IT-soknál kifejezetten: várni kell, míg elindul a VM, elindul az IDE, befejeződik a compile stb. A CPU dolgozna, de vár a lassú HDD-re. SSD-n meg minden gyorsabb. Épp ezért értelmetlen az, hogy "az adatok a HDD-n, a szoftverek az SSD-n". Nem, az kell SSD-re, amivel gyakran dolgozol. És nem csak a programfile-ok ilyenek.
A HDD egy dologra jó: long-term storage, amihez nem kell sűrűn nyúlni.

A 2T feletti ssd ára azért nagyon sok embernél kib@szná a biztosítékot. Örülök, h számodra megfizethető, én nem adnék érte 200 ezret. Pláne, ha kitalálod, h az home felhasználás, és vegye meg az enterspájz kategóriát. És leginkább pláne, ha nincs is szükség a sebességére.

Mas arkategoriaban gondolkodtok. Egy IBM szintu cegnek a 2T SSD ara az kb apropenz, de egy csaladi vallakozasnal, ahol raadasul nem is feltetlen a szamitogep a penztermelo eszkoz, csak szukseges rossz, a leheto legkevesebbet probaljak rakolteni, pontosan azert, mert nem termel penzt. Raadasul doglott lora fenyes nyereg kategoria, amikor ott all egy netto otszazezer forintba kerulo gep, es max naponta ketszer van hozzaszolva egy 2MB-s Excel fajl elmentesevel (+1 sor), egyebkent csak eszi az aramot. Ez a valasz amugy a HDD elettartam panaszokra is feljebb, nem az IOWAIT fogja elenni a HDD uzemoraszamat, hanem az, hogy all a sarokban.

Ilyen helyre tenyleg olyan gepet kell rakni, amiert nem kar. Kell egy jo es megbizhato NAS, amire rendszeresen mentve vannak a kritikus adatok, egyebkent pedig 150-200 kHUF a max amit ra szabad kolteni, es meg igy is lehet, hogy evekig mukodokepes marad.

A SOHO kategoriaban nincs helye enterprise szintu megoldasoknak, mert egyreszt nincs kihasznalva, masreszt nem tudja az a piac megfizetni, aki megis, az inkabb a kivetel kategoria. Ha neked az osszes ismerosod ilyen, akkor jol valogattad meg az ismeroseidet.
--
Blog | @hron84

"Raadasul doglott lora fenyes nyereg kategoria, amikor ott all egy netto otszazezer forintba kerulo gep, es max naponta ketszer van hozzaszolva egy 2MB-s Excel fajl elmentesevel (+1 sor), egyebkent csak eszi az aramot. "
Pont erre valo a cloud storage. Ebben a use case-ben sokkal olcsobb.
Aki meg in-house storage-ot akar, mert rendkívul fontosak az adatai (plane hogy ne felhoben legyen), az pont ne az adatokon fillereskedjen. Ha meg nem fontosak az adatai, akkor meg cloud storage.

Számoljunk picit. 2TiB SSD-t kapsz bruttó 160-180E Ft-ért, legyen kettőnek az ára 350E Ft. Ezt tengelyes diszkből összerakni méretre ugyan 2x2TiB, de ha teljesítményt is szeretnél kapni, akkor minimum a 10k-n pörgő 600-as diszkeket számolod, amiből rögtön kell nyolc darab (raid 10). Ha a dobozt, meg az ebben a kategóriában jellemező SAS vezérlőt nem számolom, ez akkor is fél milla környékén áll meg. De ha 1TiB diszkekből veszek négyet, akkor is 80-90E Ft per darab... És a SAS adaptert nem úszod meg. Igen, a "felső" kategóriás diszkeket hasonlítottam össze, mert azokkal van pariban az ssd, nem a 20E Ft-os otthoni 2TiB tengelyes diszkekkel.

+1. És mindez a szerver válaszidejére is kimutatható - ahogy az is egyfajta "költség", ha a felhasználó a "lassú a szerver" miatt idegesebb, stresszesebb. Miközben csak annyi történik, hogy az olcsó diszk iops-ban béka se@@e szintet tud, amin ráadásul osztozik több felhasználó.

Bemegyek a munkahelyemre, bekapcsolom a gépem. Amíg boot-ol, leveszem a cipőm, kabátom, kimegyek a konyhába egy pohárért. Nem boot-ol ilyen sokáig, Windows 10-zel vert meg a sors, ez egy 1 TB-os, 2.5"-os, fene tudja milyen HDD-n van.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Egy csaladi vallalkozas vegyen maganak egy Google Apps csomagot sajat domainnel es kesz.
Vagy vegyen Office 365-ot. $12.5 havonta felhasználónként a Business Premium csomag.
A Google Apps $10 havonta felhasználónként business kategóriában. Gyengébb verziója $5 havonta felhasználónként.
Ha meg nagyon-nagyon mikrovállalkozás, akkor 1 account, és akár ingyenes GSuite vagy Office Online. És az meg ingyen van.

Kettőnk között vélhetően az a különbség, hogy a Google Street View-t te egy innovatív szolgáltatásként éled meg, én meg egy nemzetbiztonsági kockázatként. Azt is érteni vélem, hogy szerinted mindenki okos, akinek azonos a véleménye a tiéddel, a hülyék pedig arról ismerszenek meg, hogy mást gondolnak, mint amit te.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

emberunk ados meg egy dologgal: annak megvallasaval, hogy vajon meggyozodesbol ontja magabol ezt a csillio boszmeseget (amely esetben egy IQ20-as debil), vagy megfizetik erte (amely esetben meg egy velejeig korrupt ruszki berenc agitator)?

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...

Ezt a hozzászólásodat különösen finom akkor olvasni, amikor kiderült, hogy teljesen független gyártók független tervezésű, mi több, alapjaiban is eltérő architektúrájú processzoraiban ugyanolyan hardware bugokat találtak. De te még ezek után is tolod, hogy ruszki bérenc vagyok, a nyugati világban minden rendben van, nincs itt semmi látnivaló. Próbálnék hinni neked, de valahogy a tapasztalataim eléggé korlátozzák az őszinte hitem és rajongásom kifejlődését.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

A bug az elvekben van: a spekulatív végrehajtás side-channel támadásokra érzékeny. Bárki, aki valamilyen módon spekulatív végrehajtású architektúrát implementál, az érintett. Nem az implementációban van a hiba (az ARM, az Intel és az AMD, a Power8 stb. totál máshogy implementálta a spekulatív végrehajtást a hardverben), hanem a használt elv alkalmas arra, hogy kihasználják információszerzésre. Ezt kéne megérteni. Ha oroszok, kínaiak, japánok, amerikaiak, izraeliek, németek, magyarok, bolgárok implementáltak volna spekulatív végrehajtást használó CPU-t, az is érintett lenne.

De nyilván jobb összeesküvéselméletet látni ott, ahol nincs is, hiszen az sokkal megnyugtatóbb, mint megismerni magát a problémát, és mondjuk elolvasni a spectre.pdf-et. Kevesebb energiába telik, és gondolkodni sem kell hozzá.

Attól, hogy az elv hibás, még a bug létezik, s érdekes módon minden nagy processzor gyártó cégnél olyan kutyaütők dolgoznak, akik nem diszkutálták végig az elvet, hanem eszetlenül, izomból implementálták. Amit írsz, nem egyéb, mint maszatolás, kifogás keresése. A helyzet ugyanis továbbra is az, hogy különböző architektúrájú CPU-kban van meg a bug. Ez pont olyan, mintha egyszer valaki valahol leírná, hogy a 48 az egy prím szám, majd különféle algoritmusokat mindenféle vizsgálat nélkül ezen információra építve valósítanának meg.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Az elég nagy baj, hogy nincsenek saját eszközeink, s ezzel kiszolgáltatjuk magunkat az USA-nak, de nyilván sem a technológiánk, sem a hatékonyságunk nincs meg hozzá, de ha mégis meglenne, akkor véletlenül tűzvész pusztítana az üzemekben. Nem a Google az állam, szerintem nem ezt írtam, ha mégis, akkor pontatlan volt a megfogalmazás. Egyébként úgy gondolod, a Google egy magyar startup?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Viszont nem a húszzres olcsó diszkekkel van egy súlycsoportban, azt is tessen felfogni. Ezek az eszközök otthoni nas-ba elfogadhatók, otthoni pécébe is belesomod adatok tárolására, mert nem baj, ha bedöglik meg lassú, úgyis csak egy user használja helyben. Már néhány fős irodában is cinkes 7200-as kevés cache-sel megvert home diszkes szerveren szambázni.

(Ez inkább a korábbi hozzászólásodhoz, csak itt telt meg a pohár. :))
Azért lássuk be, hogy az esetek 99,9%-ában az LVM a hanyag/alulképzett rendszergazdi mankója!
Nem pedig az évszám függvénye.
A linux LVM helyett meg inkább a méregpohár. ;)
Az ftp meg még a Mikrotik eszközökön is divat, bár ez nem is érv akart lenni.
Szerintem a dolog a next-next helyett a tervezéssel kezdődik. Ebben az esetben ritkábban fordul elő a "hirtelen átrendezés" igénye. Néhány nem elhanyagolható esetben egyenesen hátrány az LVM alkalmazása. Persze ez nem csak az LVM, hanem a kommersz diszkek használatának a következménye.
Amit feljebb írtál, azzal teljes mértékben egyetértek: sose osztjuk ki a teljes diszket. Performance szempontjából meg végképp nem, mert a WD 12 sebességi zónát használ, csak ezt elfelejtik az orrodra kötni. Hiszen itt nincs strategy és lmigrate{pv|vg|lv} parancs. :(

Itt egy majdnem hat éves vason lévő rendszerről van szó, aminél a "tervezés", ha volt, legalább hat éve történt, és azért nem, hogy hat de néha 2-3 évre előre sem lehet látni, hogy mekkora tárolási igénye lesz valaminek. PLusz ha még látszott is hat éve, hogy moostanra kinövik az akkor belépített tárhelyet, egyáltalán nem biztos, hogy az lett volna hat éve a helyes döntés, hogy a mostani igénzeknek megfelelő, "egy számmal nagyobb" diszket vegyék meg, és az kerregjen hat évig úgy, hogy vagy életben lesz a diszk akkor, amikor a nagyobb méret választásának értelme lesz, vagy sem. Nem egy, sok éves szervert (akár kkv, akár nagyvállalati környezetben virtualizáltat) láttam már úgy, hogy sok éves működés alatt ahogy az igények nőttek, kapta az újabb diszkterületet. A fizikai gépbe toltak újabb diszket, a vm meg kapott plusz területet - miután az alatta lévő SAN-ba is rendszeresen került bővítés. Az, hogy ezt hogy kezeli a rendszer gazdája: új fájlrendszer, új mountpoint, aztán ha kell linkek sora ide-oda, vagy pvcreate/vgeztend/lvresize oszt' jónapot, az az ő dolga - valahogy nekem ez utóbbi jobban tetszik...
A Linux LVM nem méregpohár, cvsak az előbb említett alulképzett fejlődésben sok éve megállt Linux rendszergazdáknak az :-)
Ja, a migrálásra azért bőven ad lehetőséget a Linuxos lvm is, csak a "tervezés" az, amire ott is szükség van, ha épp átrendezésre/konszolidálásra kell sort keríteni - és meg kell érteni/el kell fogadni, hogy a logikája más, mint más oprendszerek logikai kötetkezelő megoldásainak :-P

Mehetni mehet, de ugye akkor egyedül a backupot tetted felhőbe (arról nem beszélve, hogy a 10Mbit/sec DSL letöltés, felfele legjobb esetben is csak a fele ;)).
De ha az egész IT-nak menni kellene a felhőbe, csak a könyvelőprogram készítője csak az adatbázis migrálásért kiszámolna annyit amennyiből helyben lehetne normalizálni az egészet. És kérdés, hogy ilyen infrastruktúrán, hogy teljesítene a felhő (szerintem nagyon nem jól ;)) Tehát a "fillérbaszóknál" a felhő sem megoldás. :)

Akadalyokat keres... jo vicc. Ha en most itthon szeretnek konyvelni, vagy barmivel foglalkozni, tudod mennyi feltoltesem van? 2 MBit/s es ez a topbest ami elerheto a kornyeken. Slussz. Ha te egy ilyen internet mellett uzemeltetsz nekem felho alapu infrastrukturat ugy, hogy ne verjem percenkent az asztalt amiatt, hogy fel orara kifagy az Excel menteskor, akkor ki fogom fizetni a beredet. Addig viszont probalj meg tajekozodni, hogy mi megy otthoni internet cimszo alatt a varosban, mert nem mindenutt erheto el a 100 MBites UPC vagy a gigabites Digi.
--
Blog | @hron84

Láttam - nem is keveset. Na ott kéne _értelmesen_ tervezni úgy, hogy rugalmasan lehessenbővülni, migrálódni akár diszkek átpakolásával a régi "dobozból" az újba. Ha egy cégnek nem kell redundáns tárolás, nem kell backup, akkor az adatai nem fontosak. Jó techniaki tudással és üzleti/szakmai vénával kell persze rendelkezni ahhoz, hogy egy nem szakmabeli cégvezetővel megértesd azt, hogy ha az adatai mindenestől elvesznek, akkor az neki mekkora, időben, reputációban, plusz munkában (és ezt mind forintosítva pénzben) jelentkező kiesést, veszteséget jelent. Nem úgy kell kezdeni, hogy "ennyit kell elkölteni azért, hogy..."
Ha valakinek adrenalinszintet tol feljebb az, hogy lvm van, az így járt (tanulni, tanulni, tanulni...), picivel kell több parancsot ismerni, cserébe rugalmasabban működik a dolog.

ha egy sérült lemezről kell (ugye backup híján) adatokat visszahozni.

az egyes szavakat ertem, de a mondat nem all ossze: akarmilyen storage-rol is beszelunk (das, nas, san, ...), az redundans diszkekbol all. Ha egy diszk meghibasodik, akkor arrol kapsz ertesitest, masnap te (vagy a support) kihuzod a rosszat, betolod helyere a jot, a kontroller ezt eszreveszi, beveszi a tombbe az uj diszket, es megy tovabb az elet. Szoval nem ertem, honnan kellene visszahozni az adatokat, mert azok el sem 'mentek'.

A 'backup hijan' meg no komment...

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...

SMB-ről beszélünk, ahol az S inkább jelenti a Sóhert mint a Storageot (amit egy kisvállalkozásnál baromi ritkán látnak ;)). A 'backup híján' lehet no komment de sajna így van. Mondjuk ezeknél általában IT-s sincs aki esetleg tudna valamit az értesítéssel kezdeni ha egyáltalán lenne. (meghalt az egyetlen merevlemez a fájlszerverben :))

Ez jó! Lehet csak nekem vannak ilyen rossz tapasztalataim. :-)
A legjobb az volt aki azután se tett semmit, hogy beszedtek egy cryptolockert ami eltitkosított mindent, azon kívül, hogy kifizette a zsarolókat. Az ember pedig azt gondolná, ha megszívják abból legalább tanulnak.

Ezért nem árt, ha hozzáértő tervezi. Ha nem, akkor sorolhatod az érveidet, és mindig igazad lesz. Csak ez nem sokat segít a tervezés hiányán.
Elég gyér volt a linux szerver üzemeltetési tapasztalatom. A megrendelés 100 rendszer backupról szólt - nyáron lesz 10 éve. Ja, és 20eFt is számít! Első szempont egy 8xsata alaplap, aztán 4x1TB diszk, raid1. Volt 2db, összesen 1GB, sebesség szempontjából kritikus fs. (Nem nagyon lehetett kisebbet csinálni.) Aztán jöttek a bővítések: +2x1TB, majd 1TB->2TB csere. Addig magyaráztam, amíg a rendszergazdival már csak közvetítők útján érintkeztem. :) Az utolsó csere a modern linux kívánalmainak megfelelően alakult: LVM és migrálás sorosan. (Megártott a sok fideszes szakirodalom. :) Bocs.) Aztán amikor a performancia kevesebb mint felére növekedett, akkor újrázni kellett. :-D
A rendszer teljesítette a speckót: 119 rendszert és >20M backupot kezel (nemrég, nagytakarítás előtt még még 150 rendszer és 35M backup volt)
A közel 10 év alatt háromszor szerveztük át a diszkeket némi trend vizsgálat után. Ha nem vagy lusta, akkor a legtöbb esetben kivitelezhető.

Ez a példa megfelel annak, amit leírtál. Az "előrelátás költsége" minimális. Az LVM alkalmazása meg katasztrofális következményekkel járt. No, nem azért, mert ennyire rossz lenne. Inkább azért, mert az egyébként profi üzemeltető (aki egyébként linux kernelbe is írt valami diszkkel kapcsolatos fontos dolgot!) nem tudta hogyan működnek a diszkek. Meg tán olvasni se nagyon tudott, mert a működéshez szükséges feltételeket többször megkapta írásban is. ;)
Az LVM helyett partíció (és linkek) több üzemeltető szerint azért győztek, mert egy diszk kihullásakor pontosan tudjuk a kockázatot. Ha egy fakezű játszadozik az LVM-mel, akkor meg nem. A fenti példa is ezt a félelmet igazolja. Hangsúlyozom, ezek az üzemeltetők nem kispályások, csak még nem merült fel ilyen igény. Egyébként is kétlem, hogy még egy hasonló méretű rendszerük lenne.
Más oprendszeren (köszi, hogy megőrizted a titkunkat! :)))) VAN olyan lehetőség, ami linuxon nem is lesz. Nem a logikája más, hanem egyes dolgok nem léteznek. Ezáltal a nem létező dolgokról leírás sincs, használni sem lehet. Marad a kézi módszer, amit az ilyen öreg hülyéken kívül más nem ismer és nem használ.

Fakezű egyednek bármit adsz a kezébe, képes katasztrófát csinálni. Azt mondani, hogy nem kispályás az, aki sokdiszkes felállásnál ignorálja az lvm-et... Nos, ez szerintem elég meggondolatlan, mi több, hibás kijelentés.
Az meg, hogy igény sem merült fel erre, az az "egyedi megoldást más nem tudja biztonságosan életben tartani" szinonímájának tűnik. 100+ vm, gépenként több, független adatbázis+kapcsolódó ez-az, partnerek összeolvadása (két adatbázisból lett egy (meg még kettő, de ez mindegy), rendszer komplett cseréje "A"-ról "B"-re és hasonló üzleti igények miatt esélytelen lett volna adott környezetet lvm nélkül megvalósítani. Ja, és mindezt úgy, hogy a rendszer alatti storage (ahol milliós pénzeket jelent a bővítés) az igényekkel együtt nőtt évről évre.
Az, hogy másütt van olyan lehetőség, ami Linuxon nincs, az pont a különbségeket erősíti - vuiszont ezzel az erővel mondhatnám azt is, hogy Windows-on van egy rakat olyan dolog, ami se itt, se ott nincs. Ettől egyik sem jobb a másiknál általánosságban, csak bizonyos funkciókat tekintve több illetve kevesebb lehetőséget ad, kevesebb, illetve más tudásból kell főzni.
Az LVM mindkét helyen jó, de mindkettőt úgy kell megtanulni, hogy önmagában. Nem a másikhoz képest, mert akkor olyasmit fog benne keresni az ember, ami nincs, vagy épp fontos dolgokat fog félreértelmezni.

Benézted a konstellációt, de az én hibám.
A nem kispályás==rendszergazdi aki LVM-et akar, de elcseszi.
Aki ignorálja az LVM-et==én, aki a rendszert tervezte és méretezte.
Az "egyedi megoldást más nem tudja biztonságosan életben tartani" az meg egy nagyon bonyolult kérdés! Ha pontosan leírom mit kell csinálni, akkor
a) Nem tudod elolvasni -> olvasó tanfolyam
b) Nem tudod megcsinálni -> linux tanfolyam
c) Ha megcsinálod úgy, ahogy jónak hiszed, vagy ahogy szoktad, csak a rendszer lesz szar==fakezű

...csak bizonyos funkciókat tekintve több illetve kevesebb lehetőséget ad, kevesebb, illetve más tudásból kell főzni
Ezt jól mondtad. Feltételezem, ha Te lettél volna a rendszergazdi helyében, akkor felfogtad volna a megoldás célját, és a rendszerrel konform tudásoddal elvégzed a feladatot. Nem olyan bonyolult feladatkáoszról van szó, mint amit írtál.

Itt van az a tudás, amit "más rendszeren" szereztem meg. Ennek ellenére linux alatt is forognak a diszkek, sőt egész hasonlóan működnek. ;) A feladat megoldható akkor is, ha más az LVM. Ebben a konkrét esetben a feladat megoldása után az LVM csak egy felesleges réteg lesz. (Ne kezdjél esesdézni! Az 1GB kritikus területen a 100GB Intel SSD 3-5 hónap alatt fingana ki.)

Az LVM helyett partíció (és linkek) több üzemeltető szerint azért győztek, mert egy diszk kihullásakor pontosan tudjuk a kockázatot. Ha egy fakezű játszadozik az LVM-mel, akkor meg nem.

ezt nem ertem: milyen 'tobb uzemelteto' szerint elfogadhato az, hogy ha pl. a /data/data1 -> sdc, /data/data2 -> sdd, ... sema szerinti linkekkel kell jatszani, ahelyett, hogy a /data lenne mindig bovitve az igenyek szerint? Biztos a legtobb alkalmazas meg szereti, ha csillio particio ala kell dolgozzon...

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...

A kérdésed nem válasz az idézett megállapításra. ;)
Ha LVM alapon felveszed a munkaterületeket, akkor kezdetben mondjuk 3 diszkpárból csak az első lesz tele. Annak a lassú részei lassítják a rendszert, míg a maradék két diszkpár üres marad.
A bővítgetések során egy munkaterület óhatatlanul 3 diszkpárra fog kerülni, holott egyre is elférne. Helyette az egyes jól megbecsülhető méretű munkaterület(ek) kerülnek mindig egy diszkpárra, méghozzá olyan zónába*, amely az optimális sebességet biztosítja.

Pontosan azért, hogy a diszkek terhelése kézbentartható legyen, a /data (az olyan, mint a C::)) helyett különböző szempontok szerint szét kell választani az egyes munkaterületeket. Az igények felmérhetők. Van olyan munkaterület, amely közel állandó méretű, és olyan ami lasan, de biztosan növekvő. Az átméretezés jó esetben egybeeshet a tervezett cserékkel.

A link kezelése nem egy nagy durranás. Mivel a rendszer automata, ezért főként játszani nem kell vele. :) Diszk csere esetén a következő időszakra méretezett ~/data1 -> fog mutatni az igények szerint méretezett fs-re. (mount point-ra)

* Lásd: Zone bit recording
A 0,5..1TB WD diszkeket 12 zónára osztják, míg a régi scsi diszkeknél csak 2 zóna van.
Az előbbinél külső/belső zónák sebessége megközelítőleg 2:1.

( p2pking | 2017. 12. 31., v – 14:16 )

Ilyen esetekre szoktam azt mondani, hogy bizonyos szint felett nem gondolkozunk bizonyos szint alatt.

Teljesen ismeretlen valtozok amik optimalis eesetben sosem voltak ismertek, vagy reg elfelejtodtek, jelennek meg. Favagoknak is kell hagyni morzsat, nem mindenki ulhet a habos sutemeny tetejen :D

http://karikasostor.hu - Az autentikus zajforrás.

( McPascal | 2018. 01. 01., h – 15:59 )

Igazából a post lényege nem a "puritánul" kivitelezett, de a célnak megfelelő vas volt.
Hanem az, hogy hogyan lehet újabb HDD-ket használhatóvá, tartóssá tenni a fejparkolás kikapcsolásával.
BTW Boldog Új Évet Kívánok! :)

Légyszives olvasd át a postot. A HDD ideiglenesen kellett eleve, illetve feleslegesen hoztad be a home use nem home use kérdést, mert így félig-meddig ellentmondasz a commentednek.
Itt bele kellett férni egy reális keretbe ennek a rövid műveletnek. Persze lehet játszadozni a nullákkal oda-vissza, meg overkill arannyal ezüstözött izékről árajánlatot adni. Maximum azt mondják, hogy oké, majd más megcsinálja.
Én egy friss biztonsági mentéssel rendelkező HDD oda-vissza másolásában és particionálásában nem láttam ekkora égbekiáltó kockázatot így. Jöhet a kő :D

Ritka, amikor nem értek egyet veled, de most muszáj tiltakoznom: a postoló Magyarországon dolgozik, magyar kisvállalat számára kellett megoldania valamit, magyar pénzbeli és egyéb erőforrásokkal - itt még mindig nagyon nem járható út több tera SSD nem csak, hogy otthon nem, de SMB-nél sem, egyszerűen nem fér bele a keretbe így szóba sem jön. Otthoni környezetben 512 gigás SSD is ritka, nemhoyz a nagyobb, ezt azért próbáljuk meg figyelembe venni. Hazai kisvállalkozásnál, ha szerver és storage --> HDD. Sok év, mire az SSD-nek ilyen méretekben megfizethető lesz az ára, különösen a mai árak mellett, amikor egekben a tárolóárak, legyen az RAM, vagy bármi egyéb.

fent mar sokan kifejtettek mennyi idot lehet sporolni SSD-vel akar egy kisvallalkozasnal is, igy ez megterul. masolasnal is (2TB-ot masolni rendes HDDn vs SSD-n, oradijban), napi munkafolyamatokban is, etc.

ha az a KKV nem tud kigazdalkodni SSD-t a gepekbe akkor pedig nem eri meg egy masodpercnyi idot sem beleolni, hiszen 200k nem a vilag vege.

Nem is a zsebben turkálás lep meg egyébként, hanem a valóságtól való elrugaszkodottság. A postban ugyan egy árva szó nincs arról, hogy szerver storage-nak kellett volna a HDD, és a postnak sem ez volt a témája, mégis az elő-storyra van mindenki ráfüggve. Egy családi vállalkozásban 200k nagyjából egy irodai dolgozó(pl.:asszisztens) fizetése(jobb esetben).
Adsz egy ilyen árajánlatot egy ilyen effektíve 1 napos munkára, és garantálom, hogy nem fognak visszahívni.