- Kormányok / autós szimulátorok topicja
- AMD vs. INTEL vs. NVIDIA
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- Azonnali VGA-s kérdések órája
- Amlogic S905, S912 processzoros készülékek
- Gaming notebook topik
- A kánikula elviseléséhez hardverek is kellhetnek a napernyő mellé
- Milyen TV-t vegyek?
- Milyen CPU léghűtést vegyek?
- Computex 2024: monstrumhűtő a DeepCoolnál (videóval!)
Hirdetés
-
A kánikula elviseléséhez hardverek is kellhetnek a napernyő mellé
ph Tajpeji kiruccanásunk hetén többek között notebookok, monitorok, NAS, szimulátor-kiegészítő és kompakt hűtő igyekszik árnyékot találni.
-
Frissítve! Summer Game Fest 2024 - Az összes bejelentés egy helyen!
gp A show késő este kezdődik, de utána az összes trailert összegyűjtjük egy helyre.
-
Perelnek a vallásos kripto-piramisjáték miatt
it Két kriptocéget perel New York államügyésze, mert több mint 1 milliárd dollárral károsították meg az áldozatokat.
-
PROHARDVER!
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
-
OddMan
őstag
[Btrfs] fájlrendszert szeretnék használni adattárolásra. A kérdésem, hogy a RAID56 többnyire már megbízhatóan használható? Itt azt írják [link], hogy több bug-ot is sikerült már kijavítani ezzel kapcsolatban, bár jelenleg maradt még egy komolyabb bug a "write-hole". Ha jól tudom, ez a jellegű hiba az mdadm-ben is benne van jelenleg is, mégis mindenki használja. Ugye a "write hole" bug akkor okozhat gondot, ha a szerver nem megfelelően indul újra vagy áll le pl. áramszünet miatt. Mondjuk gondolom szünetmentes használatával ennek a hibának az előfordulása azért drasztikusan csökkenthető. Ha jól tudom már a "scrub" használata sem okoz adatvesztést, akkor sem ha raid56 mellett használjuk. Érdekelne olyanok véleménye akik Btrfs-t használnak, hogy mi a tapasztalatuk, illetve ti mit hallottatok erről a témáról mostanában 2019-ben? I
[ Szerkesztve ]
''A szíved szabad! Légy bátor és kövesd!''
-
OddMan
őstag
-
samujózsi
tag
Linuxon létezik olyan virtualizációs szoftver, ami linux hostRA (a vmware különböző variációi emiatt kiesnek azt hiszem) telepíthető és amivel a UEFI+secure boot is használható?
Mielőtt a fizikai vason nekiesek, szeretném virtuális gépen kipróbálni az archlinux telepítését ilyen környezetben.
A virtualbox tud UEFI-t (talán már működik is benne ), de emlékeim szerint nem secure boot-os.Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
samujózsi
tag
Használ itt valaki LVM snapshot-ot online mentésekhez?
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
Frawly
veterán
Én jelenleg a QEMU-t használom KVM-mel, ahhoz ha telepíted a ovmf csomagot, és megmutatot a proginak az OVMF_CODE.df binárist, akkor UEFI-t használ, és ahogy a menüjében matattam, Secure Bootot is tud. Viszont én nem ajánlom, hogy Secure Bootot használj, sok előnye nincs, de az OS telepítéseket rendkívül megnehezíti.
-
samujózsi
tag
válasz Frawly #29056 üzenetére
Köszi, úgy egy órája fedeztem fel, hogy az ovmf picit több a sima efi-nél, csak nem volt időm foglalkozni vele (mindig így járok: kérdezek, aztán amíg várom, hogy valaki válaszoljon, unalmamban megtalálom a választ )
Sajnos a secure bootot nem tudom mellőzni, mert hülye lesz tőle az alaplapom. Valami BIOS bug lehet, de pl több napos uptime után se reboot, se poweroff nem működik, bios/efi szinten lefagy, és ha nincs secure boot... már nem emlékszem, de akkor valamiért egyáltalán nem tudtam bebootolni rajta pendrive-ról. Régi Asus alaplap.
Eddig legfeljebb annyi problémám volt a secure bootból, hogy bsd-t nem sikerült telepíteni. Szerencsére az ubuntu megy vele.
De ha kicserélem az ssd-t, majd megnézem újra, hátha csak én rontottam el valamit amikor ki akartam kapcsolni.Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
Dißnäëß
veterán
Sziaszok !
Remélem elfér haladóban, de lehet kezdőben kellene.. mindegy. (Elnézést, ha igen).
Két könyvtár közötti szinkronizációs kérdésem lenne.Van két media fájlokat tartalmazó könyvtáram, A és B. (Legyenek privát képek a DSLR-emből, raw-k).
B könyvtárat apámnak adnám egy külső HDD-n, így őt A-ból képeztem, kb. háromnegyede megvan B-n az A-nak és ez így is marad, nem kell minden.
Viszont kiderült számomra, hogy pár kisebb könyvtárszerkezeti módosítást és "újítást" B-n csináltam meg, A helyett, holott a kettőnek identikusnak illene lennie. Tehát a B-n lévő ~75%-nyi adatot vissza kellene valahogy replikálnom A-ra úgy, hogy:
- B alkönyvtáraiban ugyanazok a RAW fájlok vannak, mint A-n, ezeket skip-elje a másoló, nem kell átvinni őket újra (majdnem 1 tera)
- B alkönyvtáraiban nincsenek újabb alkönyvtárak, mint A-n, így A-n lévő alkönyvtárakat ki kéne gyepálnia a másolónak és teljesen identikusan a B alkönyvtár struktúrát kellene, hogy leképezze A-n is
- a többi alkönyvtárat A-n hagyja érintetlenülVan erre valami tool, parancs, bármi, ami segíthet ? Szinkronizálás lenne a cél, tehát ami megvan B-n már, azt tegye át A-ra úgy, hogy A-ba módosítson bele B-knek megfelelően, ami többlet pedig A-n van, azt hagyja békén.
POKE 16017,44 ..... SYS 2077
-
Dißnäëß
veterán
válasz OddMan #29051 üzenetére
Bár a kérdésedre nem válasz, én a btrfs raid-jellegű funkcióitól még kicsit félek, nem véletlenül írják sok helyen, hogy inkább zfs-ezzen az ember, vagy klasszik md raid. Viszont az tetszik benne, hogy nincs adat degradation, mert block level checksum-okat használ + még pár olyan funkció, ami hasznos lehet később.
Én azt látom, hogy szimpla egyedülálló fájlrendszerként (1 partícióra) ajánlják, bár mai napig nem stabil a hivatalos státusza az egésznek (ez önmagában kérdőjel ugye, hogy használjuk-e), az extra és vonzó funkciói viszont még ehhez képest is experimental szint.
1-2 hónapon belül építek egy virtualizációs host-ot, ezen lesz egy NAS-ra használt VM is terveim szerint, a host-ba 3db HDD jön az SSD-k mellé és a HDD-ket md raid 5-be teszem, majd erre btrfs-t, így a raid megvalósítás nem a btrfs-re hárul, amiben nem tudnék megbízni, hanem a klasszik softraid. És utóbbi sem tökéletes, de én még mindig kevésbé fázok tőle, mint btrfs ezen funkcióitól. (Vagy zfs, lehet errefele is elkacsintgatok, ott natívan zfs alatt merném csinálni a raidz-t, az sokkal kiforrottabb).
Jópár évig volt Debianon 3x2TB majd 3x4TB md raid 5-öm, meredek dolgokat is csináltam vele, nekem amúgy eléggé bevált, nem láttam indokoltnak a 6-ot, de ez ízlés kérdése, pedig tele voltam mindenféle fontos fotókkal (hobbi fotósként).
Egy olcsó szünetmentes nem árt azért, amit havi 1x kipróbálsz valami más fogyasztóval, akksi idő tekintetében. (Egy dolog, mit jelez magáról és egy másik dolog, hogy ténylegesen kitart-e X terhelés mellett annyi ideig, míg a gép szépen lelövi magát és leáll).
De ez csak én vagyok - 1 óvatos duhaj.
POKE 16017,44 ..... SYS 2077
-
samujózsi
tag
válasz Dißnäëß #29060 üzenetére
Félve kérdezem: nincs itt némi kavarodás a fejekben a különböző RAID megvalósítások használatát/célját illetően?
Ami fontos, arról backupot kell készíteni, akár naponta többet is.
A RAID arra van, hogy hardverhiba esetén ne kelljen leállni, illetve egyes variációknál a performancia javítására.
Nem először látok olyat, hogy fontos adat=RAID, csak ezért említem.Ha olyan adatokról van szó, ahol akár pár percnyi adatvesztés is gondot okoz, akkor meg adatbázis, folyamatosan fizikailag másikndiszkre archivált redo logokkal. Vagy ha tud ilyet a btrfs/zfs, akkor akár azt is lehet használni.
[ Szerkesztve ]
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
Dißnäëß
veterán
válasz samujózsi #29061 üzenetére
Szerintem nincs kavarodás. Nekem például a softraid egy desktop kategóriájú gépen belefér, nincs igényem olyanra, hogy szünetmentes táp és külön belső akkuval ellátott kontroller kártya és ilyesmi megoldások. Jó, hogy egyben lát az ember logikailag olyan dolgot, ami mind sebességben, mind megbízhatóságban tolerál minimum egy diszk kiesést, még ha minden egyéb feltétel is nemredundáns.
Alaplap SATA vezérlő beszarás és társai ellen nem véd, nyilván. (Bár ha mindegyik alkatrész külön PCIe kontrollerről megy, a softraid ezt már kezelte is, de a többi ellen akkor sem véd, pláne nem memória hiba ellen, stb. De hát a desktop az desktop).
Kérdésedre válaszolva: lehet ezt feketén-fehéren is nézni és akkor semmi értelme az otthoni raid-nek sem, a szoftver raid-nek sem (a sebességen kívül), btrfs-nek meg pláne nem. Viszont lehet szürkén is nézni és akkor oda helyezed a megkötendő kompromisszum-csúszkát, ahova szeretnéd. Van aki feketébe tolja el, szeret kockáztatni egyre nagyobbat és van, aki fehérbe, a szürkén belül, minimalizál 1-2 kockázatot. És ez így jó és szép, hogy van lehetőségünk erre.
Nem túl sok kompromisszum, nem túl sok biztonság, több kompromisszum (enterprise szerverek, pénz, zúgás), több biztonság, ezek egyszerű dolgok, de semmiképp sem egybitesek, mint ahogy az igény sem egybites, ami ezen technológiák létrejöttét indukálta.
Ha NAGYON félsz adatvesztéstől, nyilván tudod a megfelelő védekezést ez ellen, de az tökmás liga, mint egy desktop motyó tele kompromisszummal, épphogy a bare-minimumot adva. Nálam ez a bare minimum tök elég évek óta. Lehet statisztikailag kimutatható lenne, hogy az elkövetkező 80 életévem alatt mekkora az esélye egy újra és újra átmigrált többterás raid5 tömbömön ülő adat részleges, vagy teljes elvesztésének, de nem nagyon rugózom ezt agyon, viszont annak igenis piszok nagy esélye van, ha 1 diszken tárolom mindezt, hogy akár 1 éven belül is bukjam őket. Számomra elégséges ezt a kockázatot mitigálni.
POKE 16017,44 ..... SYS 2077
-
Dißnäëß
veterán
válasz Dißnäëß #29062 üzenetére
Az már érdekesebb kérdés, hogy szükéges-e mindezt az adatot egyszerre, egyben elérni, vagy elég archiválni őket (az archív redundanciájának biztosításáról beszéltünk már? ) , vagy ahogy Te írod, backup, tehát minimum két helyen van aszinkron módon tárolva ugyanaz az adat, az egyik az élő, a másik meg akkor frissül, mikor úgy gondolja a user.
Ez jó meglátás, de én itt is hiába vannak mondjuk 2014-es képeim, a kényelmet választottam, hogy bárhol, bármikor elérem őket. Raid van, backup nincs. Raid logikai hiba ellen nem véd, viszont szegmentálva a storage-ot vagy fájlrendszereket vagy könyvtárakat (kinek mi), lehet olyat, hogy aktuál évi adat r/w, tavalyi és régebbi adat r/o -ként mount-olva és akkor ez ad némi biztonságot user hiba ellen is.
De amúgy jogos a felvetés.
POKE 16017,44 ..... SYS 2077
-
samujózsi
tag
válasz Dißnäëß #29062 üzenetére
Az kimaradt: a RAID nem véd a fájlrendszer sérülése ellen. (Pl zsaroló vírusok, vagy épp egy jól irányzott dd parancs )
Értelme lehet házi használatnál is, például a sok kis kapacitású diszkből egy nagyot összerakni (ezt szintén kifelejtettem).
Csak mikor olyat látok, hogy valaki fontos adatot és RAID-et említ egy mondatban, akkor feláll a szőr a hátamon.Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
Dißnäëß
veterán
válasz samujózsi #29064 üzenetére
DD-zni azért root kell, ha meg mezei user kezdi el tolni ezt, eléggé falba ütközik és én user-ként használom a Linuxot, nem rootként, még sudo-t se adtam a saját user-emnek.
Persze rommá lehet törni bármit.. 100% biztonság nincs.Jött már be nekem ez a softraid, mert SMART szerint az egyik HDD-n lett 1 szem (!) bad sector-om, ami elvileg pótolva lett a tartalék területről (relocated), több nem szaporodott már hónapok óta, de intő jel, hogy sürgős csere, a diszket meg megtartom
porno-ralinux iso-raPOKE 16017,44 ..... SYS 2077
-
samujózsi
tag
válasz Dißnäëß #29059 üzenetére
Nem állítom, hogy pontosan értem, mit szeretnél.
Ha a B alatti könyvtárstruktúra módosítást szeretnéd az A-ra átvezetni, arra szerintem (!!) nem találsz automatizált megoldást.
Van az rsync, amivel azonos könyvtárstruktúrákat tudsz szinkronba hozni, akár úgy is, hogy ami az egyik oldalról hiányzik, azt törölje a másikon is, de ha jól értelek, akkor nálad olyan kellene, hogy x fájlt a sokadik alkönyvtárból fel kéne hozni mondjuk a második szintre (példa: A/s/d/f/x van most az egyik, B/m/x a másik helyen és te az A/s/d/f/x-et törölnéd, helyette lenne A/m/x, de ha az A/s/d/f alatt van olyan, ami a B/m alatt nincs, akkor azt megőriznéd)
Ezt jelen ismereteim szerint csak manuálisan lehet.Illetve még olyat csinálhatsz, hogy ha van elég helyed, hogy A alá visszamásolsz mindent B-ről, az új struktúrának megfelelően, de törlés nélkül és ráküldöd az fdupes parancsot, és ebből válogatod ki a felesleges fájlokat, majd törlöd őket.
Mondom: feltéve, hogy jól értelek és az rsync sem változott túl sokat az elmúlt két évben.
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
inf3rno
nagyúr
Mert a backup is hozzásegít a rendelkezésre álláshoz, hiszen ha elveszik az adat, akkor minden leáll. Illetve a RAID is hozzásegít a biztonsághoz, mert többször letárolja ugyanazt, így egy meghajtó hibája miatt nem veszik el az adat, és nem kell azonnal a backup-hoz nyúlni. Ezen kívül a modern fájlrendszereknél (zfs, btrfs) RAID-el szokták kombinálni a block checksum-ozást, és így ezek a fájlrendszerek védenek bitrot ellen is, amire a backup önmagában nem képes. A helyzet komolyságától függően lehet a backup-ra is szoftveres RAID-et tenni, illetve lehet több backup-ot is használni, de ez azért a legtöbb projektnél ágyúval verébre.
Buliban hasznos! =]
-
ivana
Ármester
válasz Dißnäëß #29059 üzenetére
Nem vagyok egy nagy szkript mágus, de ezt szerintem úgy kezdeném, hogy mindennek legenerálom az md5sum-ját. Egy-egy fájlba, aztán onnan kiindulva jöhet a többi funkció megvalósítása.
(#29073) inf3rno A modern fájlrendszerek checksum képessége tényleg hasznos. Sőt én emiatt konkrétan elavultnak tartok bármilyen nem szoftver RAID-et. A hardver RAID vezérlő meghalásától sokkal jobban félnék, mint egy stabil fs-től. A másik meg nyilván az ECC ram, ott ahol fontos adat van mindenképpen ECC ram kell.
A helyzet komolyságától függően lehet a backup-ra is szoftveres RAID-et tenni Ennek normál esetben nem látom értelmét. Ha meg valami tényleg komoly kell, akkor meg georedundancia + backup mágnesszalagra.
[ Szerkesztve ]
-
Frawly
veterán
válasz inf3rno #29067 üzenetére
Nem sarkítás, igazuk van. A RAID a backupot nem váltja ki. Mert hiába a rendelkezésre állás, meg a fájlrendszer checksumja, az ellen nem véd, ha pl. emberi hibából, vagy szoftveres bugból adódóan felülírsz adatot, törölsz, vagy pl. ransomware darálja be. Vagy pl. a RAID és a fs checksum hibakorrekciós képessége is korlátos, ha túl sok lemez esik ki, vagy túl nagy blokknyi adat sérül, arra védelmet nem nyújtanak. Backupnak mindig lennie kell, hiába a redundáns RAID megoldás, utóbbi tényleg arra jó, hogy ha a lemez hibájából esik ki valamennyi, akkor legalább a rendelkezésre állás meglegyen.
Sokan tévesen hiszik, hogy jujj, RAID, akkor teljesen védve vannak, és nem kell backup. De, kell.
[ Szerkesztve ]
-
Dißnäëß
veterán
Semmi komoly amúgy, csak nálam úgy "kell" archiválni, hogy közben elérhetőek is maradnak az adatok.
Mondjuk az a rahedli saját CD backup, amiket a kilencvenes évek óta gyűjtögettünk anno faterral, meg sokminden egyéb még.
Kitehetem polcra is (kint is van egy 500 GB-sen) ami hiperfontos nekem, a többi ennél mérsékelten fontosabb csak, de annál meg megint fontosabb, hogy egyetlen diszken legyenek.
Nem vagyok egyszerű eset. Na, ilyenekre jó a softraid + btrfs (míg a btrfs saját raid-szerű megoldása nem lesz iszonyú stabil, silent corruption ellen jó). De lehet végül nem tökölök és feldobok egy VM-ben egy BSD alapú NAS-t, alárendelem a diszkeket és jónapot, zfs.
Még agyalok ezen azért.rsync: a tippet köszi, le-man-ozom.
POKE 16017,44 ..... SYS 2077
-
Speeedfire
nagyúr
Hi!
Adott egy surface pro, amire dual boot-tal egy android x86-ot tettem. Ennek egy grub2 loadere van. A bajom, hogy csak billentyűvel tudok választani a listából. Jó lenne ha lehetne a hangerővel is. Valakinek erre van valami tippje?Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
Dißnäëß
veterán
válasz Frawly #29080 üzenetére
Ohh, ezt nem is tudtam. Viszont feltételezem, a Linux-os ZFS is olyan kiforrott, mint a BSD-s, mármint ilyen téren nincs eltérés a kódok között. Így akkor softraid sem szükséges, legalábbis az MD féle megoldás, hanem egyből raidz (esetemben).
POKE 16017,44 ..... SYS 2077
-
inf3rno
nagyúr
válasz Frawly #29078 üzenetére
Nem állítottam, hogy bármelyik is kiváltaná a másikat.
Ha már így szóba került, akkor inkább azzal lenne értelme foglalkozni, hogyha rendelkezésre állás és backup is kell, akkor mégis hogyan írunk föl több terabyte állandóan változó adatot valamire? Elkezdjük a másolást, aztán mire a végére érünk már tök más adat van fent a lemezen...
[ Szerkesztve ]
Buliban hasznos! =]
-
Frawly
veterán
válasz Dißnäëß #29082 üzenetére
Pont azért egyesítették a két ZFS projektet, hogy ne legyen eltérés a kódok között. ZFS esetén valóban nem szükséges a softraid.
inf3rno: azért az ritka, ha valahol olyan sok tera gyorsan változó adat van, ami már a mentés készítése alatt megváltozik. Eleve a háttértárak korlátozott sávszélessége is korlátozza ennek az előfordulását. Attól is függ milyen adatot akarsz menteni, meg milyen fájlrendszerről.
-
OddMan
őstag
Btrfs fájlrendszer hogyan szórja szét az adatokat raid10 esetén, ha mondjuk 4db 1TB-os HDD-t használok? Ha jól tudom a Btrfs raid10 az inkább a raid 0+1 típusra hasonlít.
Például hardveres vagy mdadm raid esetén sokszor akár 2db lemez kiesése esetén is működik még a raid10 vagy raid0+1.
Például ha a raid10 az sdb1, sdc1, sdd1, sde1 partíciókat használja, akkor a következő esetekben, akár 2db merevlemez is kieshet. Például ha az sdb1, sdd1 vagy az sdc1, sde1 esik ki. Ugye raid0+1 esetén pedig kieshet az sdb1, sdc1 vagy sdd1, sde1.A kérdésem, hogy a Btrfs raid10-nél ez hogyan működik, a fentebbi konfigot figyelembe véve, tehát 4db 1TB-os HDD esetén?
Gyanítom, hogy nem úgy, mint az mdadm vagy egy hardveres raid-nél, bér ebben nem vagyok biztos és erre keresem a választ. Illetve örülnék, ha valaki tudna linkelni valami leírást arról, hogyan teszi az adatokat a Btrfs fájlrendszer a merevlemezekre saját szoftver raid használatkor.[ Szerkesztve ]
''A szíved szabad! Légy bátor és kövesd!''
-
inf3rno
nagyúr
válasz Frawly #29084 üzenetére
A sok tera lehet, hogy ritka, de egy normál HDD olvasási sebessége 120MB/s körül van. Lehet, hogy a RAID valamit dob rajta, de ha többszáz MB adat van, már annak a másolása is több másodpercig tart, és több másodperc alatt történhetnek írások egy átlagos alkalmazás esetében is. Állítólag a snapshot sem csodaszer erre: [link], szóval könnyen lehet, hogy sok backup-ról, amit manapság mentenek el, éles helyzetben kiderül, hogy használhatatlan vagy minimum sérült.
Buliban hasznos! =]
-
Frawly
veterán
válasz inf3rno #29086 üzenetére
A snapshot sérült biztosan nem lesz. Legfeljebb egy időállapotot nem konzisztensen mutat. Ja, ez a megoldás sem mindenható, ha az lenne, akkor kihaltak volna a backup szoftverek és mindenki snapshotokat készítene kizárólag.
De mondom, ennek a gyakorlati jelentősége kicsi, mert olyan rendszerről, aminek a tartalma már a backup készítése alatt megváltozhat. Nyilván, ha tudod, hogy neked ilyened van, akkor más megoldás után kell nézni, vagy le kell csatolni a kötetet, és úgy backupolni.
-
samujózsi
tag
válasz Frawly #29087 üzenetére
Mi köze a backup szoftvernek a snapshothoz?
Egyébként nem annyira a kötetet kell lecsatolni a konzisztens, nulla adatvesztéssel járó backuphoz, hanem az adatok írását végző szoftvert kell lelőni, ha nincs olyan adatbázisod, ami lehetővé teszi az online mentést.
Mondjuk azt nem tudom, btrfs/zfs tudnak-e ilyet, szerintem nem.[ Szerkesztve ]
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
samujózsi
tag
válasz samujózsi #29088 üzenetére
Lejárt a szerkesztési idő: btrfs/zfs kapcsán lehet, hogy frissíteni kell majd a snapshottal és online backuppal kapcsolatos ismereteimet, mert beleolvasva egy wikibe, most úgy tűnik, elég hiányosak a velük kapcsolatos emlékeim/ismereteim.
[ Szerkesztve ]
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
Dißnäëß
veterán
..
[ Szerkesztve ]
POKE 16017,44 ..... SYS 2077
-
inf3rno
nagyúr
válasz Frawly #29087 üzenetére
Minden rendszernél előfordulhat, ami egyszerre fájlrendszert és adatbázist is használ adat tárolásra. Ha csak adatbázis van, akkor esetleg a tranzakciók használata védhet ellene.
Én is úgy értettem a sérültet, hogy inkonzisztens lesz a snapshot időben.
Ha folyamatos rendelkezésre állás kell, akkor az írás leállítása nem feltétlen jöhet szóba.
[ Szerkesztve ]
Buliban hasznos! =]
-
Dißnäëß
veterán
Kedves haladó Linuxosok !
Dual boot-os a masinám, az SSD egy részén W10 C: , másik részén pedig egy Debian, utóbbin QEMU-s virtualizácós móka, műxik is gyönyörűen.
Van valami egyszerű mód arra, hogy meglévő W10 installációmat mount-oljam egy QEMU-s VM alá, mint HDD-t, és boot-oljon és használhassam ?
Csak érdekel és nem akarom a W10-et újratelepíteni, hanem csak leinstallálok róla olyanokat, ami nem kell és marad az, ami nem tud Windows nélkül létezni (pl. Battlefield V). Átállnék minden egyebemmel, mindennapos tevékenységeimmel a Linuxra.
POKE 16017,44 ..... SYS 2077
-
samujózsi
tag
válasz Dißnäëß #29092 üzenetére
Qemu-ban futtatnád a fizikai vasra telepített windows10-t?
Mert az (szerintem) nem fog menni.
Telepítéskor a windows a hardverhez igazítja magát és a qemu-ban totál más hardverkörnyezetet fog találni. 10-esnél erre nem vennék ugyan mérget, korábbi verziók mind így működtek.Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
Dißnäëß
veterán
válasz samujózsi #29093 üzenetére
10-es elég flexibilis ilyen téren, rengeteg mindenen beindul ugyanaz a telepítés (próbáltam már, még az Intel-AMD-Intel dupla váltásomat is túlélte egy előző install-om, csak teleszemeteltem).
Lehet simán kiköltözök róla akkor és Linux alatt egy VM-es W10-re teszem át azt a keveset, aminek Windows kell.
Arról van infód, hogy host SSD-n ha létrehozok qcow2 default formátumú diszket, TRIM van-e egészen a fizikai SSD-ig kezelve ? A rátett Linuxnak megadhatom a discard-ot, de vajon értelmezi a host OS ezt ?
POKE 16017,44 ..... SYS 2077
-
samujózsi
tag
válasz Dißnäëß #29094 üzenetére
Elvileg tud trimet közvetíteni, kvm guest és az ssd közt, de nem tudom, mit kellett beállítani hozzá és költözéskor legyalultam a virtuális gépeket a notebookról.
A guestből az lsblk segítségével meg tudod nézni, alkalmasnak látja-e a virtuális géped a diszket ilyesmire, de erről sincs több emlékem.Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
-
Frawly
veterán
válasz Dißnäëß #29094 üzenetére
Nem a guest-ben kell a discard-ot beállítani, hanem a host OS fájlrendszerében, amin a qcow2 képfájl van. Kivéve, ha az SSD-t fizikai egészében adod át a virtuális gépnek, mert akkor a guest-en kell állítani, a host pedig nem használja.
(#29097) bambano: robokuty nagyon eltűnt mostanában.
-
-
Frawly
veterán
válasz samujózsi #29099 üzenetére
Most hogy újra végiggondolom, igazad van. Mégis csak át kéne engedni, különben a fizikai host gépen hiába van TRIM, ha úgy látja, hogy az egész qcow2 fájl foglalja a saját lemezterületét, hiába lett valami törölve belőle, nem szabadul fel a már nem használt blokk belőle.
Ezen a linken az első válaszban adnak meg működő példát.
De a legtisztább az lenne, ha az SSD oda lenne dedikálva fizikailag a virtuális gépnek, mert akkor semmit nem kell átengedni, a guest-en elég simán beállítani a TRIM-et.
Illetve NVMe-n nem tudom hogy lehet megoldani. Mert a TRIM parancs csak PATA/SATA/AHCI SSD-khez van, az UNMAP csak SCSI/SAS/UASP interface-esekhez. NVMe-n viszont a TRIM-et végző parancs bele van integrálva más lemezműveletekbe, ezért külön nem lehet meghívni, meg semmin keresztül átengedni. Na már most nem tudom, hogy a discard átengedése ezen mit segít.
Új hozzászólás Aktív témák
Állásajánlatok
Cég: Alpha Laptopszerviz Kft.
Város: Pécs
Cég: Ozeki Kft.
Város: Debrecen