-
GAMEPOD.hu
Mára a ProHardver!/IT.News Fórum is nagylétszámú Linuxban jártas taggal büszkélkedhet. Nehéz szinteket felállítani egy olyan rendszer ismeretében, ami annyira sokrétű, hogy teljesen szinte lehetetlen megismerni minden egyes részét. Azt azonban mindenki tudja, hogy kezdő-e vagy sem. Elsősorban nekik szólnak az alábbiak, de érdemes mindenkinek elolvasnia, mint útjelző táblát.
Új hozzászólás Aktív témák
-
Azon töprengek, hogy elvben melyik filerendszer lenne ideális a következő két esetben:
Alacsony teljesítményű ARM SoC-on (WDR4300 router OpenWRT-vel) USB2-vel lógó 5400RPM <=500Gb HDD-re rögzítünk 24/7 egy max 8 Mbit/s (hogy mennyi lesz a variable bitrate mód átlaga, vagy hogy milyen fix bitrate-et választok majd, azt még ki kell tesztelnem, de a specifikáció szerint a 8Mbit/s a plafon és olyan 4-re tippelek, mint ideális fix/átlag, ahonnan már csak pazarlás fentebb menni).
Egy erősebb AMR SoC-on (valamilyen low/mid-range consumer NAS) vagy mini PC-n (inkább erre hajlok, hogy egy Intel Atom D2x00 gépecske, ez esetben egy Gentoo-t húznék rá) szükség szerint akár 7200RPM >=2Tb SATA HDD-re ugyan ilyen adatfolyam, csak párhuzamosan 4-8 szálat (első körben 4 kamera lesz, de már 8 portos PoE switch-el készülök a bővíthetőségre).
A második esetben szerintem tudok majd futtatni opensource programot, amivel talán lehet egyéni beállítások szerint is cache-eltetni / ütemeztetni a stream-ek lemezre írását (használjon bőségesen akár 1-2Gb RAM-ot és írjon szinte szekvenciálisan), de ez akkor derül ki, ha megérkeztek a kamerák és le tudom tesztelni. A kisebb gépen szerintem csak az jön szóba (és a tartalék terv a nagyobbhoz is), hogy a kamera rögzít egy SMB, NFS vagy FTP tárhelyre (még nem tudom, hogy melyiket, de elvileg legalább egyet támogat ezek közül a kis Linux-os firmware-ük), de talán sikerül az OpenWRT-t is rávenni, hogy az olvassa a stream-et és ütemezze a lemezre írást hálózati megosztás vagy FPTserverhost-olás nélkül.
Az elsőnél tehát lényegében szekvenciális írás lenne kis CPU-val (relatívan sok RAM-al, általában ~90Mb is szabad), a másiknál viszont ügyesen kéne kezelni azt, hogy egyszerre több párhuzamos adatfolyamunk van, de CPU erővel, RAM-al sokkal kegyesebben lehet bánni (akár két x86 mag és 2-4Gb RAM).
Jól gondolom, hogy a kis gépre talán egy VFAT, a nagyra esetleg a BRTFS lehet a nyerő? Előbbi, mert kő egyszerű, utóbbi, mert próbál nagy "csomagokban" írni a lemezre olyankor is, ha több file-ba dolgozik (bár ezt csak "SSD barát" funkcióként olvastam, nem tudom, hogy HDD-nél is így jár-e el)?
[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
Keresgéltem a témában google-el, de hihetetlen módon nem találtam választ (nehéz elképzelni, hogy még senki nem forszírozta ezt):
--- Lehet valahogy manuálisan megadott értékre limitálni a page cache méretét, beleértve akár a nullát, vagy kikapcsolni az egész cache-elést? ---
Azért lenne érdekes, mert a Virtualbox képes dinamikusan lefoglalni a memóriát a host-on, ahogy nő a guest memóriafoglalása, viszont amit egyszer lefoglal, azt már nem szabadítja fel később, mikor (és persze ha) a guest OS-en belül szabaddá válik.
Tehát, ha magasra húzom a Virtualbox-ban a memórialimitet, akkor előbb-utóbb óhatatlanul lefoglalja majd azt a mennyiséget a host-tól, mert a guest-en belüle a page cache alapvetően nőttön nő, míg betelik a memória. Ugyanakkor alulra kicentizni is nehéz a korlátot, ha nem csak egyetlen nagyon specifikus dologra használom a guest OS-t.
Azon túl pedig, a host-nál is van page cache, tehát így is, úgy is tele lesz tömve a fizikai memória, csak míg a host-nál lévő page cache-ből minden (a host és minden esetleges guest) profitálhat, addig a guest-en belüli cache-ből csak a guest...
Vagyis, ha nem lenne, vagy csak minimális méretre lenne korlátozva a guest-nél a page cache, akkor sem kéne sokkal lassabbnak lennie semminek, a memóriahasználat viszont jellemzően alacsonyabb, ugyanakkor rugalmasabb lenne (nagyon magas korlátot lehetne neki adni, amit csak szélsőséges esetben és szükség esetén foglalna le, nem szinte bizonyosan viszonylag hamar pusztán csak cache-enk).
...
A sync mount option az nem elég, az csak az írási cache-t mellőzi, olvasáskor ugyanúgy feléli az összes szabad (virtuális) RAM-ot a cache. A Direct_IO bukkan még fel a keresőkben, de azt csak egy erre felkészített program kérheti egy-egy file-ra vonatkozóan, filerendszer szinten vagy specifikus szoftver támogatás nélkül nem használható (és mellesleg ha egy-egy adott programmal használható, a többi továbbra is "szemetelhet").
A host felőli cache-elés letiltható a virtuális lemezképfile-ra nézve, mert az egy adott file és a Virtualbox, mint program támogatja a Direct_IO-t, vagyis pontosabban az ilyen jellegű dolgokat, mert ez most konkrétan Windows host lenne (de itt és Linux host-on működne a dolog a file-ra nézve).
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
válasz
#40553216
#22077
üzenetére
A drop_caches, mint chron job? For és While loop-olt bash script-ként is belebotlottam már az ötletbe, de ez legfeljebb is egy csúnya workaround (az elegáns workaround-okat jobb szeretem a bonyolult korrekt megoldásoktól, de szerintem ez ronda), amit viszonylag nehéz jól méretezni (egy 150 Mb/s lemez/kötet sebességet alapul véve legalább 1s-enként le kell futtatni, de a <<1s talán jelentékeny CPU terhelést és/vagy IO lassulást is okozhat).
A másik, hogy nálam egy drop_cache után a memória 10%-a page cache, 1%-a buffer marad (egy magasabb értékről erre dobja vissza, akkor is ha előtte sync-elek). Ezek a számok gondolom nem véletlenül adódnak, főleg hogy most nem is kerek értékek (most épp 1300 Mb-ot adtam a VM-nek, és ezek így rendre 130 és 1.3 Mb méretűek). A 10% az alapértelmezett lazy_write határértékre emlékeztet, de azt hittem, hogy az az írási buffer felső határa, nem pedig a page cache része.
Van a kommentek közt egy link glibc wrapper-hez, ami minden file-elérési műveletet direct_io-ra cserél. Ezt majd talán kipróbálom. De a 10+1%-ot szerintem ez sem tünteti el, ami ilyenkor feleslegessé válik. Bár egy sync mount opció talán igen.
[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
Nem fordul le nálam ez a kód, bár miután ránéztem a dátumra, már sejtettem, hogy nem fog nyerni, azóta biztos alaposan átírták már a glibc-t és a directio kernel kódot.
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
válasz
bambano
#22080
üzenetére
Jól kezdődik: The rawio is a deprecated interface since Linux kernel 2.6.3.
![;]](//cdn.rios.hu/dl/s/v1.gif)
De ettől függetlenül sem arra való / jó arra, amit én szerettem volna.Bind-eltem egy block device-t raw device-nak, de ahogy sejtettem, erről nem lehet hagyományos filerendszert mount-olni. Ez csak arra jó, ha valaki a saját programjával szeretne nyersen adatokat tárolni filerendszer nélkül, avagy valamilyen saját egyedi filrendszerrel, amit a saját programja kezel, nem a Linux kernel/OS.
Talán az a legegyszerűbb megoldás, ha veszek még 8Gb RAM-ot, és akkor teljesen irreleváns lesz, hogy kvázi elfecsérlek-e belőle 1-2Gb-nyit vagy sem.
De azért fura, hogy ennyire merev a rendszer, és hogy senki olyannak nem jutott még ez eszébe virtualizáció kapcsán, akinek megvan a tudása/ideje/jogosultsága, hogy bevarázsoljon egy mount opciót, aminek hatására minden műveletet directio-ként kezelődik.Azért kösz a tippeket.
[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
#22085
janos666
nagyúr
lionhearted
#22083
válasz
lionhearted
#22083
üzenetére
Azt már korábban leírtam, hogy a host cache-t nagyon egyszerű megkerülni (egy pipa a Virtualbox beállításaiban), és akkor "direct" nyitja meg a képfile-t. Tudatosan arra voltam kíváncsi, hogy a guest-en belüli cache miként tiltható. Le is írtam, hogy miért -> ne hízzon meg a dinamikusan növekvő, de csak teljes újraindításkor "zsugorodó" memóriafoglalás mérete a host-on (a guest számára).
Ugyanakkor az is jó érv, hogy ha a host cache-el olvasást is, akkor hosszas szekvenciális olvasáskor egyszerűen "átmossa" a guest cache-t, estlegesen hasznos dolgokat kidobva, a host számára haszontalanokat betömve. De ez a rész továbbra is teljesen dinamikus, bármikor felszabadítható a host olvasási cache, a huest-en belül viszont hiába szabadul fel, a host azt már "soha" nem kapja vissza, esetleg mindenestől guest leállításkor. De az "átmosás" hatásába korábban tényleg nem gondoltam bele.
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
Próba-szerencse alapú hibakeresés céljából próbáltam letiltani az összes lehetséges file/folder locking mechanizmust Samba 4.3.4-ben azzal, hogy bepakoltam ezeket az smb.conf-ba (némelyiknél már ez volt az alapértelmezés a manual szerint, de kigyűjtöttem belőle mindent, ami szóba jöhet):
kernel share modes = no
#locking = no
strict locking = no
oplocks = no
kernel oplocks = no
fake oplocks = no
blocking locks = no
level2 oplocks = no
durable handles = no
posix locking = noA locking-ot azért tettem kommentbe, mert a manual alapján a no azt eredményezi, hogy bár semmit nem lock-ol a Samba szerver, de a klienseknek azt hazudja, hogy mindent lock-olt (ami látszólag ugyan az, mint a fake oplock, csak nem a lock-olás oppurtunistic változatával). De már próbáltam ezt yes-re is állítani, az eredmény akkor is hasonló.
A testparm szerint minden OK, de aztán:
F17a_NAS ~ # smbstatus
Samba version 4.3.4
PID Username Group Machine Protocol Version
------------------------------------------------------------------------------
12759 root root 192.168.1.111 (ipv4:192.168.1.111:55744) Unknown (0x0311)
Service pid machine Connected at
-------------------------------------------------------
data 12759 192.168.1.111 Thu Feb 11 20:00:24 2016
Locked files:
Pid Uid DenyMode Access R/W Oplock SharePath Name Time
--------------------------------------------------------------------------------------------------
12759 0 DENY_NONE 0x100081 RDONLY NONE /data . Thu Feb 11 20:01:24 2016
12759 0 DENY_NONE 0x100081 RDONLY NONE /data . Thu Feb 11 20:01:49 2016
12759 0 DENY_NONE 0x100081 RDONLY NONE /data surveillance/B1 Thu Feb 11 20:01:24 2016
12759 0 DENY_NONE 0x100081 RDONLY NONE /data surveillance Thu Feb 11 20:01:24 2016
12759 0 DENY_NONE 0x100081 RDONLY NONE /data movies Thu Feb 11 20:01:49 2016Vagy a fenti smbstatus ellenére lehetséges, hogy sikerült letiltanom a lock-olást, és itt csak azt látom, hogy mit kért a kliens, sem pedig azt, hogy valójában mit tett a szerver?
Vagyis lényében a "fake" mód van érvényben és nem tudom elérni, hogy nemet merjen mondani a Samba a Windows-nak egy lock request-re? Ezt nem hajlandó elfogadni a Windows, vagy mi...?Abból a szempontból lenne érdekes a dolog, hogy vannak olyan file-ok ezen a tárhelyen, amiket gyakorlatilag 24/7 ír folyamatosan egy folyamat a Linux-os gépen, amin a Samba is fut (pontosabban nem mindig ugyan azt a file-t írja, hanem óránként újat kezd és egy cronjob törli időnként a régebbieket, de létrehozástól lezárásig apránként növekszik egy-egy file --- valós időben stream-el videótartalom megy bele), közben pedig egy Win10-es gép is használja ezt a tárhelyet és néha egész konkrétan ezeket, az épp gyarapodó file-okat is megnyitom vele.
Az a fura, hogy azt tapasztaltam hosszabb időn át, hogy akkor kezd problémázni a kérdéses file-okat kezelő program, amikor be van kapcsolva a Windows-os gép. Például este 17-től másnap 10-ig folyamatosan sorakoznak fel azonos méretű, pontosan 1 óra anyagot tartalmazó file-ok, de 10-től, amikor aznap felébredtem és rutinból bekapcsoltam a gépet, onnantól 20-30 percenként megszakad és újraindul, rövidebbek a file-ok és így ki is maradozik pár perc (de ilyenkor általában még semmit nem csinálok vele, a kijelzőt még be sem kapcsolom határozatlan ideig, nem hogy a hálózati meghajtót tallózgatnám, főleg nem ezeket a file-okat piszkálom...). Viszont ha szándékosan megnyitom a félkész file-okat és direkt nyitva hagyom a Windows-on a mappatallózót, hogy frissítgesse a fileméretet, attól még nem lesz feltétlenül zavaros a működés, van hogy ilyenkor is egész nap zavartalanul működik, hiába babrálom kézzel is szándékosan.
Szóval nem egyértelmű az összefüggés, de mégis gyanús, hogy talán a Windows lock-ol egyet, mikor felcsatolja a hálózati meghajtót és emiatt a Linux-os program néha (még ha nem is kiszámítható módon) félbehagyja a fileműveleteit. Szóval csak teória, de szerettem volna tesztelni azzal, hogy mindenféle lock-olást letiltok. Illetve ha kiderülne, hogy tényleg van köze a lock-okhoz, akkor is próbálnék később olyan beállítást keresni, ami jól működik, de nem tiltja teljesen a lock-ot...
[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
válasz
janos666
#23561
üzenetére
Ah, google-el keresgélve rájöttem, hogy a DENY_NONE azt jelenti, hogy semmit sem tagad meg, csak megtévesztett az, hogy két oszloppal arrébb RDONLY szerepel, így azt hittem, hogy írásvédett (ReadDONLY) a file/mappa, ami lock-olt (de nem).
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
Ha ZFS vagy Btrfs intézi a paritást/redundanciát, akkor biztos eljátszhatod, amit szeretnél, hogy kicseréled őket nagyobbra (akár lépésenként többet is egyszerre, ha olyan), és a végére megnő a tárhely a filerendszerben is (és végig online lehet az egész). Btrfs-nél még a profilok (RAID szintek) közt is lépkedhetsz (végig online). Partíciókra pedig egyiknél sincs szükség, ha úgyis csak egyet csinálnál (pontosabban a ZFS alapfelállásban szeret dobni maga alá egy nagy GPT partíciót, hogy tehessen neked mellé egy extra kis boot partíciót, hátha kell még, de ez megkerülhető, és anélkül is lehet róla még boot-olni is trükkösen).
(A profilváltás lehetővé teszi, hogy HDD cserekor átmenetileg több, ne kevesebb redundanciád legyen, pl. RAID 5-ről átmész 6-ra, majd vissza 5-re, nem pedig 0-ra, majd vissza 5-re.)
Hagyományos RAID mellett (akár soft, akár hard) ez a konkrét RAID megoldáson múlik, hogy engedi-e megnövelni a fentről látható kötet méretét, miután már minden lemezt kicseréltél egyesével (kicserélni nyilván ki tudod ugyan azzal a művelettel, mint ha hibás lemezt selejteznél), de ritka, a filerendszert pedig ilyenkor mindenképp külön lépésben kell ráereszteni az extra helyre, ha ez lehetséges (a legtöbbnél működik, de szerintem nem mindnél, az öregekkel, vagy egzotikusakkal lehet gond). A szimpla kernel driver szintű szoftver RAID-re azt tippelném, hogy nem (de azért olvass utána)
Az LVM-et nem igazán ismerem, de tippre tudnia kéne ezt a játékot (kötet látható méretének növelése hardware bővítés után), mert egy viszonylag rugalmas kötet kezelő (szerintem részben pont erre van kitalálva).
* mivel megemlítettem, rögtön írom azt is, hogy nehogy kipróbáld Btrfs-el a RAID-5/6-ot (csak ha kíváncsi vagy, hogy meddig bírja összeomlásig, illetve hogy esetleg hamarabb javítják-e az ismert hibáit, mint ez bekövetkezne), csak 0,1,10 mehet, de ZFS-el mehet az 5=Z (6=Z2,... Z3) is, ha azt szeretnél. Szerintem önmagában véve, úgymond "magára hagyva" jobb a ZFS, viszont kevésbé rugalmas, ami később hátrány lehet (nincs se defrag, se profil váltási lehetőség, csak annyi HDD-d és redundanciád lehet, amennyivel indulsz), a Btrfs hátránya (idővel rohamosabban lassulhat) pedig behozható "mikromenedzseléssel" (időközönként rutinszerű defrag és metadata balance felváltva). Szóval szerintem ennyi most a vízválasztó (ha RAID-5/6 kell, akkor a ZFS, ha RAID-1/0/10, akkor Btrfs lehet jobb).
Én jobban szeretem az "okos filerendszert", mint a szoftver vagy hardware RAID-et (az jellemzően merevebb, és igazából kevéssé megbízható konzisztenciát tekintve, mert nincs egy helyen kezelve a redundancia és checksum, illetve leginkább nincs is checksum, ami nélkül nem mindig elég maga a redundancia). A RAID inkább megbízható lemezekhez jó, ahol egy HDD vagy megy, vagy azonnal olyan módon vall be minden a hibát, ahogy a RAID vezérlő számít rá, de a consumer HDD sokszor nem ilyen (esetleg a NAS-ba szánt verziók) és a konzisztencián túl potenciális hasznos extráik is vannak (amit nem kötelező használni, de még jól jöhet, mint pl. a snapshot készítés), de nem feltétlenül bonyolultabb (az LVM sem triviális, itt pedig gyakorlatilag integrálva van egy LVM a filerendszerbe, vagyis egy helyről éred el a funkciókat és kevesebb lépésből) és ráadásképp maga a hagyományos filrendszer rész is "robosztusabb", mint a legtöbb (bár már EXT4-nél is van opcionálisan metadata log checksum és az XFS-be is átpakoltak pár ilyen új funkciót).
[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
Arra én is azt mondtam lentebb, hogy RAID-5/6 módban semmiképp ne használd, mert ismerten hibásan működik jelenleg. Vagy amúgy is más RAID profilt szeretnél (pl 1 vagy 10)?
A lélegzés is egy hibaforrás. Ha veszel levegőt, akkor mozog tőle az egész tested, így könnyen elrontod a precíziós mozdulatokat, de ha sokáig nem veszel, akkor előbb-utóbb elszédülsz, és akkor biztos félremegy a kezed is. Csak a viccben működik az, hogy "stresszhelyzetben az emberi test képes előállítani az összes oxigént, amire szüksége van".
Semmi sem tökéletes, így szerintem azt érdemes keresni, hogy elvben mivel küszöbölöd ki a legtöbb lehetséges hibát (így kevesebb dologra kell figyelni az emberi oldalról, ahol a feledékenység és rossz párhuzamosítás miatt nehezebb több kicsi, mint kevesebb nagyobb dologra figyelni), miközben könnyen és egyértelműen/megbízhatóan felismerhetővé teszed a lehető legtöbbet a fennmaradó hibalehetőségből.
A Btrfs és ZFS ezt tudják garantálni (vagy minden adat ismerten hibátlan, vagy ismerten és ismert mértékben hibás) olcsó consumer vinnyogókkal is (amiknek nem RAID-re van tervezve a vezérlője/firmware-e), míg a hagyományos RAID nem (legalább is nem mindig, nem egyértelműen, főleg nem random hardware-en és/vagy software-el, esetleg még emberi hibafaktorral).Szerintem jobb, hogy elszáll a teljes filerendszer, mint ha látszólag ott marad minden sértetlenül, de nincs módod rá, hogy felismerd, ha tetszőleges mértékben hibás, aztán esetleg halmozódik is a hiba. A sima RAID adott esetben akár szó szerint tönkreteheti a részben még hibátlan adatokat is, ha hibázik/hazudik a HDD vezérlője, miközben sokáig semmi nem tudja, illetve nem is próbálja ezt felismerni és tájékoztatni téged róla.
Az "okos" filerendszernél inkább az a veszély, ha összezuhan magába, de akkor legalább tisztán, egyértelműen teszi, így nem fogod tönkremorzsolt, hibás adatokkal felülírni a régi, jó biztonsági másolatokat, amiért fogalmad sincs még arról, hogy már tönkrevágtad az eredetit (ha már szar az, ami a lemezeken van, akkor nem adja neked őket oda úgy, mint ha hibátlanok lennének).[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
válasz
bambano
#24643
üzenetére
Szerintem ez az érvelés egy szentimentális elvvel bírálja felül azt az objektív elvet, hogy tényleges előny származhat abból (jobb teljesítmény és/vagy erősebb konzisztencia garanciák válhatnak lehetővé, akár egyszerre), hogy ha egységesen kezelsz egy komplex problémahalmazt (mint a Btrfs és ZFS féle RAID módok, mikor nem teszel közéjük és a tárterület közé semmit, aminek képes és hasznos lehet, ha kiváltja a funkcióját maga a filerendszer driver), mintsem szétszeleteled a potenciálisan egymástól függő (egyedül nem teljesen, vagy csak sokkal nehezebben, kisebb mértékben/bizonyossággal feltárható/megérthető) problémákat külön rétegekre, amik alapfelállásban szándékosan nem is tudnak, és nem is akarnak kommunikálni egymással, hanem mindegyik csak a maga kis dolgát akarja végezni, és nem aggódni olyasmik miatt, hogy lehetett-e volna többet tenni, okosabban eljárni bizonyos esetekben, mert ő csak a saját kis világán belül akar megfelelni a saját kis szabályainak.
Erre szemléletes lehet egy bürokrácia, ahol több, független, egymással közvetlenül egyedi esetekről nem kommunikáló hatóságnak kell valamit jóváhagynia, és van egy szituáció, mikor a saját szabályaik szerint mind tökéletesen végzik a dolgukat, és a szerencsétlen ember is szabályosan próbál eljárni, de a gyakorlatban mégis akadnak dolgok, amiket lehetetlennek tűnik keresztülvinni, mert A hivatalból elküldik a B-be, B-ből C-be, de C-ből vissza A-ba, viszont az A megint nem áll vele szóba, míg a B-től nincs pecsét, úgyhogy mehetne a végtelenségig megint körbe C-be, és így tovább, míg elfogy a türelem, és/vagy feladja az egészet, vagy esetleg megpróbálja megkerülni a szabályokat.
A gépeknél nem fog megkönyörülni egy ügyintéző még kenőpénzért sem, hacsak nem kezdik el "hackelni" a rendszert, és kiegészíteni mindenféle speciális kommunikációval az összes réteget, hogy a végén egy még inkább összetákolt lecsó legyen, mint az ilyen "okos" filerendszerek, ahol ez legalább eredeti design elem, nem extra rálapátolás valamire, amit nem erre terveztek.
Szerintem sokkal előbbre járna már a Btrfs fejlesztés, ha legtöbben így gondolkodnának, bár én úgy sejtem legtöbbeknél nem elvek (főleg nem átgondolt elvek, de még csak nem is szentimentális elvek), hanem sokkal egyszerűbb bináris berögződés a hagyományos rétegzés preferálása (valamikor valahol bevésődött neki, hogy szoftver RAID = szar, hardware RAID = istenség, és nem hajlandó újragondolni, bárhogy és bármivel érvelnek neki, hiába intelligens és tanult ember, ez neki vallós jellegű dolog...).
Ugyan így, szerintem a Btrfs RAID-5/6 mód is csak azért olyan, amilyen, mert úgy áll hozzá a legtöbb fejlesztő, hogy "egyébként is jobb a 0+1, tehát akkor is azt kéne használni, ha tökéletesen hibátlan lenne az 5/6 mód, így nincs utóbbit értelme fejleszteni".
(#24645) emvy
Nekem előbb az jutott volna eszembe hasonló példának, hogy biztos használ iniram-fs/disk előtöltést oda is, ahol teljesen felesleges, mert fix a konfiguráció, így nyugodtan mehetne egy testre szabott monolit kernel, amit nem melegen legóz össze egy előtöltő (ami extra idő boot-oláskor, forgatáskor, konfiguráláskor, illetve extra hibaforrás, mert még egy dolog, amire a tökéletlen emberi rutinnal figyelni kell). De ja, a systemd követel ilyet, szóval ha az megvan, akkor ez is.
[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
válasz
bambano
#24647
üzenetére
Őőő... Azt hiszem olyan, mint a Facebook, meg a Twitter. De nem hiszek benne. Ma már mindenki WiFi Hotspot-ot használ, mert az nagyon gyors!
(Mivel gondolom nem tartod fejben, idefűzöm, hogy ezen a fórumon számomra top~10 információ és véleményforrás is vagy [a kettő egyszerre külön kiemelkedő], akinek nem győzöm megköszönni a segítségét. De ettől még azért megfogom próbálni kifejteni a tiédtől eltérő véleményeim...)
Azt elfogadnám, ha olyasmikkel érvelsz, hogy a konkrét két project, amiket itt szóba hoztam, azok kicsit megfeneklettnek tűnnek most ilyen-olyan okokból és szempontokból (amik többnyire bagatell hülyeségek nyomós következményekké eszkalálódva), de szerintem abszolút logikus, objektív, és következetes, amit az alapkoncepciójuk lefektet erről, hogy miért jobb, ha a filerendszer cheksum-olásra támaszkodva, integráltan kezeli a redundanciát/paritást ahelyett, hogy szétszabdalva hagyják (de ugyan így, hogy dataset/subvol legyen partíciók helyett, stb). Szóval ennek az ellenkezőjéről szentimentális, szokáselvekre épülő érvből kiindulva engem nem fogsz meggyőzni (a "máshol is úgy van", "azt úgy szoktuk" és hasonlók nekem sohasem tetszettek).
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
válasz
bambano
#24649
üzenetére
Minden lehetséges modellnek megvan a maga előnye és hátránya, így attól is függ a megítélése, hogy milyen környezetbe szeretnéd illeszteni.
Én a Btrfs-t otthoni, esetleg kisvállalati környezetbe tartom jó ötletnek, nem hatalmas szerverparkokba (pl. azt sem értem, hogy a Facebook-ot miért érdekli, hacsak nem hobbija ott egy főnöknek), Oda, ahol egy maréknyi (durván 2-8) lemezzel kéne csinálni valami "okosat", megpróbálni kihozni belőlük a maximális teljesítményt az üzemeltetés/felügyelet, de főképp költségek minimalizálásával. Oda, ahová az igények és lehetőségek miatt nem célszerű, vagy lehetetlen is megvenni egy értelmes hardware-es RAID vezérlőt és megbízható lemezeket, de akár azt a szakértelmet és munkát, hogy valaki átlássa és felügyelje majd az egymásra rétegzett rendszert, mint az LVM + soft. RAID + xxx-FS.
Egy Btrfs RAID az egy sornyi parancs, egy LVM + soft. RAID + ???-FS minimum három (ha partíciót is teszel a volume-ra, már négy, bár azt hiszem az ETX4 sem kötelez erre, elfogad lemezt/volume-ot is, csak gondolom te akkor is teszel, ha felesleges, mert csak egy nagy lesz belőle, "csak mert, azt úgy szokták, ergó úgy kell" alapon
), és ezzel együtt nő többszörösére az átnézendő manual-ok száma, illetve ennyivel több csomagra kell vigyázni rendszerfrissítéskor (kompatibilis marad-e akár a formátum, de főleg a konkrét konfigurációs paraméterek) és tovább bonyolódhat olyasmikkel, hogy esetleg initramfs is kell, amit külön kell ehhez konfigurálni, stb (egy Btrfs simán megy initramfs nélkül még system root-nak is, RAID vagy sem).De ha már Windows, vagy "szép új nagy világ", most ott is divat lett "közeledni a vas felé", pl. a DX12-vel, és ha kicsit kitekintünk, akkor általánosságban mindenhol erre számítok amiatt, hogy nem lesz már mindig törvényszerűen "Moore and more" a nyers teljesítmény, ezért kénytelenek lesznek minden lehetséges módon optimalizálni, ha fejleszteni szeretnének, aminek elkerülhetetlen része lesz az is, hogy minél mélyebbre próbálnak nyúlni, illetve minél több réteget kidobni vagy legalább egybegyúrni az ilyen rétegzett modellekből, hogy csökkenjen az overhead és ki lehessen préselni az utolsó kis extrákat is okos trükkökkel, amiket szeletelve nem lehetett.
Windows-on a Storage Spaces féle pool + ReFS ilyen szempontból nagyon hasonlók, mint a ZFS féle zpool + zfs, csak előbbinél ezt kezelik irodalmilag extra funkcionalitásként, míg utóbbinál a zfs-t tekintik referenciának, és azt extrának, hogy akár olyan filerendszert is tehetsz egy zvol tetejére, amivel megkurtítod a lehetőséges előnyök egy részét (elsősorban további filerendszer nélküli tárhelykénti használatra szánták a zvol-t, mint pl. swap, csak saját "hülyeségből" lehet rá tenni bármi más filerendszert is, így nyilván lesz is, aki tesz
).De pl. a Storage Spaces féle RAID-5 mód amúgy is iszonyat lassú (szándékosan read-modify-write hatalmas szeletekkel, illetve szerintem nem olvas előre a paritást átugorva, így a szimpla olvasás sem túl gyors), a ReFS mókát (intelligens hibafelismerés és lehetséges javítás) pedig csak a RAID-1/10 mód támogatja (RAID-5 nem), ráadásul ez egy zárt rendszerben létezik (Windows), nem a Linux nyílt világában, ahol egymásra épülő dolgoknál triviális minden problémát kölcsönösen a szomszédra kenni, aztán a lehető leghülyébb megoldást kialkudni (mert mindkét oldalnak meglesz a saját "csak mert, azt úgy kell" elve, amit nem bírál felül, ha ezek ütköznek egy közös cél előtt).
A ReFS sem két év alatt lett (lesz !?!) kész (főleg ha a Lonhorn-tól számoljuk), illetve személy szerint még sokkal több volt vele a rossz tapasztalatom, mint Btrfs-el. Utóbbival még csak "experimental" jellegű funkciókkal, pl. a RAID-5 kapcsán volt gondom, míg nekem a ReFS-ről alakult ki a "File Shredder" benyomásom (akárhányszor kipróbáltam tesztképp, záros határidőn belül elszállt --- bár már ~3 éve volt az utolsó próba, azóta nőtt a Windows és ReFS verziószáma is, egyszer majd talán kipróbálom újra).
Szimpla egy lemezes, vagy RAID-1 profilú, semmilyen speciális vadonatúj funkciót nem erőltető felállásban még nem szállt el nálam Btrfs, bár csak durván 3 éve próbáltam ki először, nem 5-7 éve. SSD-n szerintem kimondottan jól érzi vele magát egy Linux rendszer, de HDD-ken is csak defrag és metadata blokk újrafésülés (balance) kell, hogy ne "rohadjon be" (amúgy kétségtelen, hogy anélkül be tud, akár percekig tart majd mount-olni. és várni míg listáz egy mappát...), de ez szerintem is inkább a disztrók feladata lenne, hogy ezeket automatizálják, nem magáé a filerendszeré, hogy a háttérben futtassa.
[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
válasz
Gorneck
#24662
üzenetére
Windows-on ezt szoktam használni, ami ingyenes: Odin
Hálózati szerverről boot-olsz abba a WinPE-be, hogy nem alternatíva a Live linux pl. USB-ről?
Még annyi tipp, hogy ha esetleg nagyobb HDD-re költözik, akkor javítani kell majd a GPT-t, mert szabályosan a lemez végén kell lennie a backup GPT-nek (lehet hogy a firmware és OS sem problémázik miatta, de előfordulhat, hogy nem sikerült boot-olni róla, míg helyreteszed) és Windows-al nem tudom hogy kell.[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
válasz
Gorneck
#24670
üzenetére
Mi a gond példaképp ilyesmive:
- telepíted és konfigurálod a kívánt Linux OS-t egy ilyen gépen
- (opcionális) teleírod nullákkal a filerendszer üres területeit (vagy SSD-n fstrim)
- lemented egy tömörített képfile-ba a lemez minden szektorát
- rárakod a tömörített képfile-t egy Linux telepítő/Live USB pendrive-ra
- minden gépen gépen boot-olsz pendrive-ról és DD-vel felírod a képfile-t
(csinálhatsz egy init scrip-et, hogy ez automata legyen, szóval csak be kell dogni a pendrive-ot és boot-olni róla, aztán kikapcsolni a gépet és kihúzni, ha végzett, illetve kiválthatod a pendrive-ot hálózati boot-al, stb...)Én most azt vettem ki, mint ha azt szeretnéd, hogy az átmeneti tesztelésre használt Windows-od automatikusan húzza fel maga alatt a lemezre a Linux-ot egy képfile-ból, miközben nyomtalanul eltünteti saját magát.
[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
válasz
Gorneck
#24670
üzenetére
Ja, ezt el is felejtettem: ahhoz, hogy legközelebb EFI módban boot-oljon a gép az új Linux OS-el, hozzá kell ezt adnod az alaplapi firmware bootmanager-ének a listájához (és célszerűen törölni a Windows-ét, aztán ha kell, akkor előresorolni a Linux-ot). Szóval könnyen hasonlóan, vagy bonyolultabb is lesz klónozni, mint a lenti válasz javaslata: unattended install.
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
válasz
#68216320
#24748
üzenetére
Igazából egyetlen egy tetszőleges méretű GPT partíció is elég egy HDD-vel, ha vállalkozó szellemű vagy, és beraksz egy egyedi filerendszer driver-t az UEFI firmware-be (az alaplapon), hogy közvetlenül boot-olhass a firmware-el bármiről (NTFS, ETX4, Btrfs, ZFS, XFS, tényleg bármi): [link]
Ha ez nem opció, akkor EFI boot-hoz alapesetben FAT filerendszerre lesz szükséged egy EFI boot partíción (100Mb bőven elég neki, 8 is megtenné...).
Ha hagyományos BIOS módban szeretnél boot-olni, akkor vagy MBR partícióra lesz szükség (bármire és bármennyire, csak legyen elég nagy az offset az első [és akár egyetlen] partíció előtt, hogy beférjen oda a GRUB, de az alapértelmezett 1Mb általában elég is, akár sokkal kevesebb is megteszi konfigurációtól függően), vagy GPT-n kell egy BIOS boot partíció (ami nem keverendő össze az EFI boot partícióval), aminek általában elég néhány Mb (GPT-nél ez veszi át az MBR+"hézag" szerepét a GPT trükkös visszafelé-kompatibilitása révén), de nem tudom, hogy utóbbi a gyakorlatban mennyire válik be (talán alaplapfüggő), de szükség lehet többre, ezért szoktak inkább kegyesen odadobni 100-at (mint az EFI boot partíciónak is).
[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
Ha particiók nélkül lett létrehozva 5 HDD-n egy Btrfs RAID-5 filerendszer, azt lehetséges valami értelmes módon cache-elni Bcache-el (vagy hasonlóval)?
Vagy legfeljebb csak úgy lehetne, hogy egyesével kirántok egy-egy HDD-t a filerendszerből, (mint ha lecserélném őket pl. meghibásodás okán), teszek rájuk partíciókat, és mindig újraépítgetem a RAID-5 kialakítást?
Ezzel a legnagyobb baj az lenne, hogy iszonyat lassú a scrub és convert RAID-5/6 módokban (olyan ~25Mb/s a ~160Mb/s helyett, amit egy-egy lemez tudna, szóval még "kínozza" is a lemezeket, ezért nem is szoktam on-demand scrub-olni sem az 5x4Tb-t).Valahol olvastam, hogy lehetséges partícionálatlan lemezt Bcache-elni, de ott csak annyit írtak, hogy "but it's out of the scope of this...", máshol pedig olyan leírásokat dob a google, ahol kapásból adatvesztős még a particiónált állapot is.
[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
Már sok éve viszonylag szépen teszi a dolgát ez a kiépítés. Egyszer volt csak gond, de az is hardware eredetű okból (egy fizikailag hibás SATA kábel és az UEFI Setup-ban engedélyezett SATA HotPlug együttese okán, mikor többször is eltűnt, majd újra megjelent egy HDD, és visszakerült a filerendszerbe "lemaradva", de nem degradáltként) és még úgy is le lehetett menteni dolgokat rescue-val (de új filerendszert kellett létrehozni, nem volt menthető a régi, a hibátlan HDD+kábel csokor oldalon is sérült a szakadást követő írásoktól a filerendszer). De azóta (1-2 éve?) azt hiszem már erre is fel lett készítve (ma már nem omlana össze ettől sem teljesen, mint régen).
Alapvetően hozza a RAID-0 sebességét, és van némi redundancia, ami szerintem számomra optimális. És 5 HDD fér a gépbe, mert a 6. a rendszer SSD (és nincs se több SATA port, se üres PCI-E slot a hálókártyák miatt).
Noha végül is alternatíva lehetne, hogy a PCI-E M.2 SSD-t, amit az aprón találtam véletlenül (16Gb-os Optane drive, amire mindig kíváncsi voltam, hogy mit tud, és most futottam bele olcsón) használom az OS-nek (de nem tudom, hogy hozzá tudnám-e adni, mint EFI boot entry, mert elég háklis erre az alaplap így, hogy custom mod-olt firmware van rajta, ami közvetlenül Btrfs-ről tud boot-olni!), és akkor vadászhatnék még egy 6. HDD-t (beeszkábálva az ODD foglalatba), de szerintem nem nagyon lenne gyorsabb, mert elsősorban szekvenciális műveletekre használom (de nem kizárólag, és a nagy file-okkal végzett művelet is generál random jellegű írást/olvasást*).
Egész pontosan a System és a Metadata az RAID-1, csak a Data a RAID-5 profil (a Reserve az Single).
*Lehet, hogy az új kernelben van valami regresszió, de lehet, hogy azért lassult most meg, mert csak ~10%-át hagyom szabadon (kicsit elfajult a gyűjtögetési mániám).
De ma töröltem ~120Gb-nyi adatot, többségében 200-300 Mb-os file-ok formájában, és legalább 20 percre irdatlanul belassult. Néztem nmon-ban, és rengeteget olvasott még (a sebesség és kihasználtság értékből ítélve inkább random jelleggel), miután véget ért az eleve lassú törlés (~20 file/sec), aztán kezdett még írni (gondolom rengeteg metadata blokkon rágta át magát és frissítette őket). Ilyekor a szekvenciális olvasás is nagyon lassú.Minden este fut rajta egy on-demand defrag és filterezett balance, és mégis ilyen most.
BFQ-mq az ütemező.
[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
válasz
janos666
#31405
üzenetére
Pontosítok: nem ~20 perc, hanem sokkal több, mert közben lőttem egy snapshot-ot (nincs felhalmozva több, csak a rott és egyetlen snapshot van, amit backup-ra használok) és elkezdtem másolni egy SSD-re, és még most is ~5 Mb/s az rsync sebessége (főként nagy file-okkal megy a transfer). Szóval valami nagyon nem kerek.
Most 5.12.0-gentoo kernel fut (a CPU-t nem zabálja fel, de ~25 Mb/s senességgel olvas az összes 7200RPM HDD-ről). Ez mi...?
[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
Ez azóta is így megy. Az sdg egy SSD USB 3.0 csatlakozóval (régen egy HDD volt, de az szektorhibákat kezdett dobálni, és hirtelen ez volt kéznél lecserélni), szóval nem az limitál. [kép]
Az még rendben lenne, hogy az írás lassú, mert ~90%-ig tele van, de az olvasásá úgy, hogy minden este lefut egy defrag és balance is...?U.i.: Most már én is tudnék RAID-5-ről boot-olni, ha frissíteném a mod-olt MB firmware-t újabb Btrfs driver-el.
De nincs kedvem. 
("Ami működik, azt ne nagyon piszkáld". A compile task-ok miatt szerintem jobb Gentoo alá az SSD...)[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
válasz
janos666
#31408
üzenetére
Á! Valamiért elindult egy scrub minden Btrfs filerendszeren május 4.-én, és a HDD-s RAID-5 olyan lassan dolgozik ezen, hogy még ma is csak 84% körül jár. Ettől lassú. Pedig tudtommal nincs rendszeresen automatizálva. Talán crash-elt egyet a gép (kernel panic?), magától reboot-olt, aztán elindította a scrub-ot.
Szóval rejtély megoldva, de most már azért érdekelne, hogy lehet-e teljes block device-t Bcache-elni adatvesztés és teljes adat körbemozgatós zsonglőrködés nélkül.TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
Erre van valakinek tippjre, hogy hova veszik el összes szabad terület BRTFS-e?
Többször is próbáltm már törölni több 100 Gb-ot, de hamarosan felemészti valami, ami nem látható a Win10 számára a felcsatolt hálózati meghajtón lévő file-ok méretének számlálásával. TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
#32093
janos666
nagyúr
lionhearted
#32092
válasz
lionhearted
#32092
üzenetére
Tudtommal nincs.
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
válasz
sh4d0w
#32094
üzenetére
Nem, mert ez egy általam konfigolt Gentoo, és a rendszer egy külön SSD-ről fut, nem erről a HDD tömbről.
A rendszer single/single filerendszerén nem szivárog el a szabad hely, de a HDD-s RAID5 tömbön kitartóan.
Snapshot csak backup kezdetekor kèszül, a végén pedig törlődik, és ellenőriztem, hogy törlődött.
Defrag fut rajta minden este, de nincs deduplikáció, vagy snapshot, amit "kibontson" (ez a backup után fut, és most sincs ottragadba a "back" nevű mappa, ami a snapshot lenne).[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
válasz
janos666
#32095
üzenetére
Az a fura, hogy ha törlök valamit, akkor felszabadul a hely, csak aztán egy napon belül eltűnik, és megint dugig van a filerendszer (pedig menne rà rendszeres íràs). Azt is ellenőriztem, hogy a rendszeresen felírt új file-ok közül a 10 napnál régebbiek rendeltetésszerűen törlődnek.
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
#32098
janos666
nagyúr
lionhearted
#32097
válasz
lionhearted
#32097
üzenetére
Adminként listázva terminálból sem látok olyan mappát, amit a Win11 ne látna SMB-n át. (legalább is a gyökérben, de nem fésültem át minden almappát, csak a gyökeret, mert a snapshot is ott lennne).
Kicsit félek attól, hogy feltörték a gépet és rejtett mappákban gyermekpornót vagy ilyesmit host-olnak róla.
De remélem csak valami BTRFS RAID-5 bug lesz. Bár már hetek óta ilyen. Nem nagyon volt vele időm foglalkozni, alig voltam mostanában itthon. Csak azt csekkoltam, hogy a térfigyelő kamera felvételekből tényleg törli, ami 10 napnál régebbi, néha felszabadítottam némi tárhelyet régi archive file-ok, vagy a notebook-om régebbi backup-jának a törlésével, de mikor legközelebb ránézek, akkor újra ~1Mb szabad helyem van a data-n.
Tegnap este lefutattam egy teljes rendszerfrisstést (emerge) és újraboot-oltam a frisebb kernellel, de nem változott semmi.[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
-
válasz
janos666
#32091
üzenetére
Na, most elkezdtem futtatni egy btrfs check-et, és eddig ezt írja:
[1/7] checking root itemsFixed 0 roots.[2/7] checking extentssuper bytes used 16000955990016 mismatches actual used 16000955604992super bytes used 16000956219392 mismatches actual used 16000956108800
Szóval úgy tűnik, hogy ez egy filerendszer hiba. Remélem ki tudja ezt javítani a --repair mód.TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
válasz
janos666
#32138
üzenetére
Ez lett a
btrfs check --repair /dev/sdb
eredménye:[1/7] checking root itemsFixed 0 roots.[2/7] checking extentssuper bytes used 16000956403712 mismatches actual used 16000956375040super bytes used 16000956391424 mismatches actual used 16000956383232super bytes used 16000956379136 mismatches actual used 16000956375040super bytes used 16000956395520 mismatches actual used 16000956358656super bytes used 16000956383232 mismatches actual used 16000956379136super bytes used 16000956387328 mismatches actual used 16000956354560super bytes used 16000956391424 mismatches actual used 16000956379136super bytes used 16000956383232 mismatches actual used 16000956366848super bytes used 16000956383232 mismatches actual used 16000956358656No device size related problem found[3/7] checking free space tree[4/7] checking fs roots[5/7] checking only csums items (without verifying data)[6/7] checking root refs[7/7] checking quota groups skipped (not enabled on this FS)found 160009563705344 bytes used, no error foundtotal csum bytes: 156070312080total tree bytes: 193564135424total fs tree bytes: 1302937600total extent tree bytes: 4369117184btree space waste bytes: 24091259766file data blocks allocated: 164919251968000referenced 113044292075520
Tehát hibákat talált, amiket nem javított ki. Mit lehetne még kezdeni ezzel az FS-el azon túl, hogy lementek mindent és újrakreálom? TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
válasz
janos666
#32147
üzenetére
A check --repair után újra mount-oltam, és még mindig bug-os a helyfoglaltság. Elindítottam egy scrub-ot, ami 86%-nál jár, és még nem talált hibát.
Attól tartok, hogy erre tényleg nem lesz más gyógymód, mint szerezni egy hatalmas kapacitású HDD-t, mindent átmásolni, aztán újrakreálni a filrendszert és visszamásolni az adatokat. TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
#32151
janos666
nagyúr
MasterMark
#32150
válasz
MasterMark
#32150
üzenetére
Szerintem akkor ütött be a baki, mikor szórakozott a UPS (égett az akkucsere lámpa, és áramszünetkor - ami itt vidéken elég gyakori - nem kapcsolt át akkura, de érdekes módon egyik napról a másikra - még mielőtt rendeltem volna új akkut - kialudt az akkucsere lámpa, és működik is).
#32149bambano - Ez egy kb. 5 éves filrendszer (ugyan azokkal a HDD-kkel), és látszólag 0 adatvesztés történt (ráadásul minden kerülőút nélkül olvashatók róla a meglévő adatok, nem kell semmi recovery tool a mentéshez), csak a szabad terület kezelésével kezdett problémázni. Ennyi szerintem belefér, hogy ennyi idő után egy áramszünet keresztbe tudott neki tenni ennyit.TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
Az ma' vo't valamikor régen (5+ éve), és nem tetszett (nem tudom, hogy most mi a helyzet, de akkoriban még nem volt defrag, és lassan sz@rrátöredezett minden file, durván belassult az átlagos sebesség).
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
#32161
janos666
nagyúr
MasterMark
#32160
válasz
MasterMark
#32160
üzenetére
Nem tudom, de a single/single/single profilos SATA SSD-t nekem gyorsan srub-olja a gép, csak a RAID5/RAID5/RAID5 profilos HDD-ken lassú, de még azon is ~2.5x gyorsabb, mint nálad (lemezenként nézve, a tömbre nézve ez még összeadódik).
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
-
Véletlenül észrevettem, hogy egy ideje már van KSMB (kernel mód SMB szerver).
- Amin elsőre megakadt a szemem, hogy ez támogatja az RDMA-t (lassan 10 éve nézegetem, hogy áll vele a Samba, mert a hálókártyáim azóta támogatnák).
- Ami ránézésre negatívum, hogy nem látom miként lehetne beállítani alias-okat (Samba-ban az smbusers file), pl. hogy a Linux oldali janos felhasználó az a janos@hotmail.com Windows fiókkal tudjon operálni (ha a Linux-os fiókkal lépek be Windows-ból, akkor a Windows Administrator/TrustedInstaller/stb nem fér hozzá a hálózati meghajtóhoz, így pl. nem lehet olyan telepítőket futtatni róla, amiket adminként kell futtatni Windows-on. Bár erre lehet, hogy van valami más megoldás is...).
Illetve az, hogy alig találok róla bármit a neten (pl. disztrók oldalán wiki cikkek, stb).Egyelőre összefésültem a régi smb.conf file-t a ksmbd.conf.example-el (lényegében csak kitöröltem 5-6 sort, amit nem ismer a KSMB és átírtam 2-3 sort, amit csak másképp hív, mert alapvetően hasonlók). Ebben egyelőre csak a Linux user nevek vannak, hogy ki mihez fér hozzá (guest access nincs).
Aztán kipróbáltam, és a ksmbd.adduser elfogad email címeket, mint username. De egyelőre hozzáadtam egy Linux felhasználónevet is (tesztelésre a root-ot, mert az tuti hozzáfér bármihoz akkor is, ha a Linux oldalon xattr-be eltárolt ACL nem lesz kompatibilis Samba-ról KSMB-re váltva, mivel azok a Linux user never alatt futnak).Mikor elindítom a ksmbd.mount-ot verbose módban, akkor ezt dobálja:
[ksmbd-worker/4409]: ERROR: treecon: User is not on valid users list
akkor is, mikor automatikusan a Windows fiókkal próbál hozzáférni, és akkor is, ha feldobja a Windows a login ablakot és beírom, hogy root és password1234
(Illetve kipróbáltam a janos névvel is, hátha a root-ot direkt tiltja, de azzal sem lép be.)Mi lehet ezekre a megoldás, vagy hol találhatok rá?
[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
válasz
janos666
#33476
üzenetére
Érdekes. Belebotlottam az Owlfiles-ba, amivel 445-től eltérő porttal tudom tesztelgetni a KSMB-t (a Samba maradhat mellette 445-ön, amit a Windows File Explorer is elér).
Két SMB share van:
A: /mnt/data - amihez csak a root és még valaki fér hozzá. Ez írható is.
B: /mnt/data/akármi - ehhez hozzáférnek többen, viszont csak olvasható
Az Owlfiles Windows-ról root-ként bejelentkezve eléri B share-t (meg tudom nyitni a file-okat), de az A-t nem (nem dob hibát, de totál üresnek látja).
Egyikhez share-hez sincs semmi speciális beállítás. Ami eltér az a path, az írhatóság, a user list, de mindkettőnél szerepel a root és azon kívül mindkettőnél még más név is.
A két elérési út ugyan az a filerendszer (a B egy al-mappa, nem másik fs/volume).
Samba-val ez működik, ahogy várom (elérem Win-ről mindkettőt). KSMB-vel nem.
Na ez mitől lehet...?
Szerk: átállítottam az A-t is csak olvashatóra, és így sem tudom Win-ről böngészni.[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
Van valakinek ötlete, hogy miért nem tudom kiválasztani az u-blox serial GNSS támogatást? (Z-t nyomva látom, de nem tudom bejelölni a menuconfig-ban.)
Azért nézem, mert már rendeltem egy konkrétan pont ilyen GNSS modult (U-blox LEA-5T)..config - Linux/x86 6.5.7-gentoo Kernel Configuration> Device Drivers > GNSS receiver support qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqlqqqqqqqqqqqqqqqqqqqqqqqqq GNSS receiver support qqqqqqqqqqqqqqqqqqqqqqqqqkx Arrow keys navigate the menu. <Enter> selects submenus ---> (or empty xx submenus ----). Highlighted letters are hotkeys. Pressing <Y> xx includes, <N> excludes, <M> modularizes features. Press <Esc><Esc> to xx exit, <?> for Help, </> for Search. Legend: [*] built-in [ ] xx lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk xx x --- GNSS receiver support x xx x - - Mediatek GNSS receiver support x xx x - - SiRFstar GNSS receiver support x xx x - - u-blox GNSS receiver support x xx x [ ] USB GNSS receiver support (NEW) x x
(Alapvetően nem pozícionálásra, hanem idő-szinkronizálásra tervezem használni, csak úgy puszta hobbiból, mert pár ezer forint a kínai verziója, és kicsit furán működik az NTP.).config - Linux/x86 6.5.7-gentoo Kernel Configuration> Device Drivers > GNSS receiver support qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqlqqqqqqqqqqqqqqqqqqqqq u-blox GNSS receiver support qqqqqqqqqqqqqqqqqqqqqqkx CONFIG_GNSS_UBX_SERIAL: xx xx Say Y here if you have a u-blox GNSS receiver which uses a serial xx interface. xx xx To compile this driver as a module, choose M here: the module will xx be called gnss-ubx. xx xx If unsure, say N. xx xx Symbol: GNSS_UBX_SERIAL [=n] xx Type : tristate xx Defined at drivers/gnss/Kconfig:44 xx Prompt: u-blox GNSS receiver support xx Depends on: GNSS [=y] && SERIAL_DEV_BUS [=n] xx Location: xx -> Device Drivers xx -> GNSS receiver support (GNSS [=y]) xx -> u-blox GNSS receiver support (GNSS_UBX_SERIAL [=n]) xx Selects: GNSS_SERIAL [=n] xInnen továbblépve kéne a:
x CONFIG_SERIAL_DEV_BUS: xx xx Core support for devices connected via a serial port. xx xx Note that you typically also want to enable TTY port controller support. xx xx Symbol: SERIAL_DEV_BUS [=n] xx Type : tristate xx Defined at drivers/tty/serdev/Kconfig:5 xx Prompt: Serial device bus xx Location: xx -> Device Drivers xx -> Character devices xx -> Serial device bus (SERIAL_DEV_BUS [=n]) x
Viszont ezt sem tudom bejelőlni, és innen nincs tovább, hogy miért...[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
válasz
janos666
#33526
üzenetére
Ahh. Semmi. Sikerült megoldani (elnéztem, hogy egy al-menüvel fentebb kellett kijelölni a SERIAL_DEV_BUS-t, alatta csak újra megjelenik, de sohasem jelölhető ki).
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
Kipróbáltam mindkettőt, és a Btrfs mellett tettem le a voksom.
A ZFS-nek van 2, számomra viszonylag nagy limitációja (hasonló gyökérből fakadnak):
- nincs defrag (pedig ha kvázi-állandóan írsz rá, akkor de, igen, töredezik... lalalalááá...)
- nem lehet RAID profilt váltani, beleértve, hogy nem tudsz pl. 3-ról 5 lemezre bővíteni.
Ami ZFS-ben jobb, az a saját scheduler és cache management, beleértve a most már tudtommal akár perzisztens (reboot-ot túlélő) L2 cache (de ahhoz külön vdev kell, tehát pl. egy dedikált SSD). Illetve ott elvileg nem fordulhat elő, hogy áramszünet/pánik miatt félbemarad egy olvas-módosít-ír ciklus, de ez úgy tudom, hogy csak szinkron írás módban igaz, és ha nem adsz hozzá külön vdev-et (sőt, ezt javasolt 2 lemezre tükrözni, mert átmenetileg csak ezen él egy példányban az inten log, vagyis ami majd írva leszen a tömbre - ennek megfelelően olyan SSD-t javasolnak, amin van áramtartalék kondenzátor), akkor az lassú művelet (ezért kapásból át is lehet irányítani a szinkront aszinkronná, ha nincs hozzá külön vdev-ed, és jobban érdekel a sebesség, mint adatbiztonság).
Szeirntem Btrfs-ben is tök egyszerű lenne kiküszöböni, ha manuálisan állítható lenne a stripe size (de valamiért még mindig nem az), és beállítanál pl. 5x 512n HDD-kkel 4k szektor és 4k leaf size-t (akkor eleve sohasem lenne részleges felülírás).
A Btrfs-nél 10+ éve "majd egyszer" mindkettő. A kézi stripe size és a vdev-szerűség is. A "write-hole" dolgot meg akarták egyszer oldani Btrfs-ben a Microsoft Storage Spaces-hez hasonló módszerrel, csak rájöttek, hogy az lassú (viszont SS-el el lehet játszani a stripe size / sector size trükköt, és akkor gyors, Btrfs-el nem engedik), ha nincs külön vdev (és azt sem akaródznak bevezetni).[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
-
válasz
5leteseN
#33586
üzenetére
Akkor volt talán némi értelme, mikor lassú HDD-ről futott a rendszer.
Vagy még akkor lehet, ha egy tömörített file-ból boot-olsz (pl. pici és lassú NAND flash, agyontömörített tartalommal, de viszonylag sok RAM egy embedded kütyün).
Egy másik: /etc/sysctl.conf fie-ba: vm.vfs_cache_pressure = 1 (vagy 0, ha sok a RAM), és akkor mindig pagecache-ben marad a filesystem metadata (így hamar rátalál az adatra lemezen).[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
válasz
5leteseN
#33589
üzenetére
Vannak már USB4 / ThunderBolt4 <-> M.2 NVMe SSD házak is, de nem kell olyan messzire menni, USB 3.x is elég lesz. Tehetsz bele pl. Optane P1600X-et. Le merem fogadni, hogy ezerszer gyorsabb lesz a boot, mint ha meg kéne várnod a RAMdisk-be másolást (illetve leállításkor a visszaírást), futtatás közben pedig nem hiszem, hogy észre tudnád venni a különbséget (talán kimérni is nehéz lenne még hagyományos SATA AHCI SSD-vel is).
De nem muszály Optane-nal építeni (csak azért javasoltam ezt, mert jobb random műveletekben, mint a NAND és szinte elnyűhetetlen írással ahhoz képest). Ha a méret is számít, vagy magasabb szekvenciális sebességre vágysz, lehet NAND M.2 SSD is.[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
Lehet, hogy felületesen olvastam. Tudom, hogy a Live! eleve RAM-ból fut, ezért gondoltam, hogy nem Live! rendszerről van szó.
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
válasz
Antaran
#33612
üzenetére
Miért nem teszel rá egy EFI partíciót FAT23-vel, rá egy EFI Stub kernelt, hogy ne kelljen még GRUB se? (Vagy ha OCD-ből kell a redundáns boot manager, akkor efibootmgr-t.)
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
Ezek közül melyiket érdemes aktiválni a kernel menuconfig-ban SkyLake Xeon-hoz (sima, nem -X)? Vagy teljesen mindegy, mert úgy is mindig az optimális lép életben akkor is, ha mind be van pipálva?
CONFIG_CPU_IBRS_ENTRY:x Compile the kernel with support for the spectre_v2=ibrs mitigation.x This mitigates both spectre_v2 and retbleed at great cost tox performance.CONFIG_CPU_UNRET_ENTRY:x Compile the kernel with support for the retbleed=unret mitigation.CONFIG_CALL_DEPTH_TRACKING:x Compile the kernel with call depth tracking to mitigate the Intelx SKL Return-Speculation-Buffer (RSB) underflow issue. Thex mitigation is off by default and needs to be enabled on thex kernel command line via the retbleed=stuff option. Forx non-affected systems the overhead of this option is marginal asx the call depth tracking is using run-time generated call thunksx in a compiler generated padding area and call patching. Thisx increases text size by ~5%. For non affected systems this spacex is unused. On affected SKL systems this results in a significantx performance gain over the IBRS mitigation.CONFIG_CPU_IBPB_ENTRY:x Compile the kernel with support for the retbleed=ibpb mitigation.Értelem szerint a GSD mitigation OFF, mert nem akarom elveszíteni az AVX-et, ugyan így nincs kiiktatva a HyperThreading sem. (Igen, tudom, ha paranoiás vagyok, akkor vegyek újabb vasat, de "válsággazdálkodás van... Plus vannak extra igényeim, mint pl. natív RS-232 port.)
Mindetncsak a Gentoo repóból telepítek, de van 1-2 nyitott port, pl. van egy szimpla HTML weboldalam is (semmi PHP, vagy ilyemi, csak text). Illetve még VPN server van tervben, csak az istennek nem sikerüklt úgy beállítanom, hogy natív Windows 11 csatlakozzon hozz. egyxtra sztoftver nélkül.
[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
Képes a Linux KSMBD automatikusan map-elni Windows-os email login-okat Linux usernevekre, mint a Samba?
Google-el nem találtam használható választ.TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
válasz
#79484416
#33771
üzenetére
De nem működik. Copy-paste írom be Putty-ba az --add-user email/pass-t és nem csatlakozik a friss Win11. Bár lehet azért, mert Samba-val Btrfs ACL-ekkel van megadva a hozzáférés, és az MS email-em = root (vannak mások is, akik sima user-ek a Linux szerveren, ők is elérik, amit szabad nekik, és nem, amit nem...).
Az ACL-eket viszont Windows alól állítgattam be (mint én = root).Tehát Linux-on nincs jános@hotmail.com, csak root, istvan, stb. És a KSMBD ezt nem tudja map-elni, hogy melyik email melyik Linux user...
[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
Megtetszett, hogy kb. a felére csökken a foglalt adat méret, ha zstd:15 opcióval betömörítem a rendszert. Viszont az EFI BTRFS driver alapon boot-oló gépem (2022-es kiadású a cucc, amit az alaplapi firmware-be égettem, de nem tudom pontosan melyik GRUB verzióból jött, mert utána még átutatzott valami más project-en a kód és valószínűleg sohasem lesz már update) reset-elni kezdett reboot után.
Vicces, hogy nincs mód mindent kitömöríteni ugyan úgy, ahogy be.
Leszedtem rekurzívan a "c" (compress) flag-et mindenről, aztán futtattam sima btrfs defrag-ot 10GB extent target mérettel, de alig nőtt a foglalt terület (azóta nem próbáltam még boot-olni, mert lehoztam egy másik géphez az SSD-t, és nem akarom visszaszerelni, míg nem tűnik "jónak", ebbe viszont nincs beégetve BTRFS támogatás).[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
![;]](http://cdn.rios.hu/dl/s/v1.gif)
De azért fura, hogy ennyire merev a rendszer, és hogy senki olyannak nem jutott még ez eszébe virtualizáció kapcsán, akinek megvan a tudása/ideje/jogosultsága, hogy bevarázsoljon egy mount opciót, aminek hatására minden műveletet directio-ként kezelődik.
De nincs kedvem. 
("Ami működik, azt ne nagyon piszkáld". A compile task-ok miatt szerintem jobb Gentoo alá az SSD...)
Leszedtem rekurzívan a "c" (compress) flag-et mindenről, aztán futtattam sima btrfs defrag-ot 10GB extent target mérettel, de alig nőtt a foglalt terület (azóta nem próbáltam még boot-olni, mert lehoztam egy másik géphez az SSD-t, és nem akarom visszaszerelni, míg nem tűnik "jónak", ebbe viszont nincs beégetve BTRFS támogatás).Új hozzászólás Aktív témák
- Villanyszerelés
- Kerékpárosok, bringások ide!
- Újabb Samsungok telepíthetik a Galaxy AI-t
- bb0t: Gyilkos szénhidrátok, avagy hogyan fogytam önsanyargatás nélkül 16 kg-ot
- Mindent megtudtunk az új Nokia 3210-ről
- Milyen billentyűzetet vegyek?
- Képeken az egyik kameráját elvesztő Sony Xperia 10 VI
- nVidia tulajok OFF topikja
- Vezetékes FÜLhallgatók
- Léghűtés topik
- További aktív témák...
- Microsoft licencek KIVÉTELES ÁRON AZONNAL - UTALÁSSAL IS AUTOMATIKUS KÉZBESÍTÉS - Windows és Office
- Számlás!Steam,EA,Epic és egyébb játékok Pc-re vagy XBox!
- PC JÁTÉKOK (OLCSÓ STEAM, EA , UPLAY KULCSOK ÉS SOKMINDEN MÁS IS 100% GARANCIA )
- Eredeti Windows, telepítéssel! Digital Doctor Számítógép Szerviz
- Steam, Windows, Origin kulcsok, előfizetések közvetlenül a kiadótól, a LEGJOBB ÁRON!
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Promenade Publishing House Kft.
Város: Budapest