-
GAMEPOD.hu
Xpenology Téma Összefoglaló
Új hozzászólás Aktív témák
-
kgymac
őstag
válasz sutszi #15414 üzenetére
Nem igazán, bár esxi-t használok, de passtrought h200 sas vezérlővel, 4 hdd-vel (smart miatt), diszk img nélkül, az alaplapi sas-on csak a datastore van.
Állítsd le a VM-et, klónozd le, abban növeld meg a diszket, majd indítsd el az új VM-et. Lépj be, nézd meg a kötet tulajdonságainál, ha lehetséges a növelés, a dsm szólni fog, ha igen és akkor is, ha nem.
Ha nem, marad egy másik, nagyobb disk img-s VM létrehozása, majd ha már létrejött benne az új, nagyobb kötet, átmásolnám az eredeti vm-ből az img-t és becsatolnám másodiknak.Migrálás után az adatokat átmásolhatod, a beállításokat is át lehet vinni a másik vm-ből (régi dsm-ből beállítás export, új dsm-ben beállítás import). A használt alkalmazásokat valószínűleg újra kell telepítened, de elvileg át is lehet másolni mc-vel (bár minden másolt file tulajt le fog cserélni az új userre), ha nem futnak a telepített alkalmazások. Elvileg el fognak indulni az új kötetről (gépnév, kötetnév azonosság esetén). A beállítások export/importja az usereket is átviszi, nálam legalábbis működött, amikor az n40l-emet klónoztam egy n36l-re. -
kgymac
őstag
válasz sutszi #18183 üzenetére
Én ugyan nem így használom, dedikált sas vezérlőt kap passtrought módon, azon csücsülnek a hdd-k.
Ups-ed van ? Valami logikai sérülésnek tűnik, állítsd le a VM-et,
készíts mentést az xpeno VM diszk img-ről, majd készíts egy linux vm-et, annak add oda 2. lemezként az xpeno-s disk img-t, linux terminál indít, sudo, majd állítsd össze mdadm-mel a kötetet (ehhez esetleg telepíteni kell az mdadm csomagot is a linux VM-ben), NE csatold fel a létrejövő /dev/mdX eszközöket, csak fsck.ext4-gyel ellenőrizd le a 2. diszk 3. partíciójából keletkezett mdX-t (/proc/mdstat segít, miből mi lett). Két körben ellenőrizném, az elsőben hibajavítás nélkül, csak a második körben engedném rá a tényleges javítást. A második köri javítást is csak akkor, ha felismerte ext4-nek a kötetet, egyébként semmi értelme.
Majd shutdown linux VM, start xpeno VM, ellenőrzés a syno lemezkezelőben.
Ha nincs ups-ed, szerezz be egyet, de csak akkor ér igazán valamit, ha le is tudod kapcsoltatni a VM-eket és a host-ot is (van nut client esxi-re, simán megy a DSM 6.1 nut szerverével, el is tudja indítani a host gépet, ha eléggé feltöltődött az ups).
Egy kollegának volt esxi-n dsm6.1-ről 6.2-re téves frissítése, az is hasonló megoldást igényelt, le is írta, mit csinált. Csak itt nem az md0 md1 köteteken kell küzdeni.szerk: látom, szép nagy az img. Ez egy fizikai diszk, csak a diszk lett átadva a VM-nek (proxy2 esxi xpeno leírás, 2. diszk átadási mód) ?
Ha igen, lehet, h mégis kehes a diszked, az esxi smart-ja elég gyengusz, de elvileg lehet rá telepíteni smartctl-t. Én emiatt használom a vezérlő direkt átadását, akkor a VM hozzáfér a smart-hoz (bővebb is, mint az esxi-s)[ Szerkesztve ]
-
kgymac
őstag
válasz sutszi #18193 üzenetére
Ez előzőn módosítottam közben, olvasd el azt is.
ssh-n belép a vm-re, admin jogú userrel,
sudo -i
,mount | grep /volume2
Azért nem tudsz írni, mert ro módon csatolt. Sérült az ext4.
Állíts le a torrentet, + mindent, amit a vol2-re telepítettél, fsck.ext4 a dsm-ben is van. Ha lecsatolod a volume2-t, akár meg is futtathatod, fsck.ext4 --help adja az opciókat. Első körben javítás nélkül javasolt futtatni. H afelismeri az fsck, akkor mehet a javítás is, ha nem, valami adatmentő sw-re lesz szükséged (már ha fizikai a diszk).
fsck.ext4 után mount, de lehet, elég lesz egy újraindítás, ha úgy egyszerűbb. A torrentet és egyéb szolgáltatásokat majd el kell indítanod újra.szerk: remélem, nem írtam el a grep után a kötetnevet, ha nem hoz adatot, csak simán mount megmondja a pontos kötetneveket.
[ Szerkesztve ]
-
kgymac
őstag
válasz sutszi #18196 üzenetére
Tehát proxy2 cikk első módszer.
Igen, jó eséllyel ki fogja javítani -f kapcsoló nélkül, Y válaszokkal.Azt az eszközt kell javítani, ami csatolva volt (umount után persze). Volt 2 3TB-s hdd-m SHR-ben, ami két 6TB-sre lett cserélve, majd bővítve az új kapacitásra. Az eszköz a /dev/mapper/...-ben van, volume groupban. Két mdadm mdX eszközből áll, amit a VG fog össze. A legfelső szintű eszközt kell javítani, ami nálam a /dev/mapper/... volt, nem a nálam két mdadm blokkot (ami nálam /dev/md3 és /dev/md5).
szerk: miért nem direkt adtad át (proxy2 2. módszer) ? Csak le kellett volna listázni az esxi alatt a diszkeket, majd a VM konfigban a diszk paramban beírni. Ugyan brutálisan hosszú az azonosító, de több ezer diszkre tervezték a vmware-nél, így nem lehet rövid
[ Szerkesztve ]
-
kgymac
őstag
válasz sutszi #18277 üzenetére
Van egy régi 3TB-s WD red-em, a tartalék gen7-ben, shr kötetben van, 16-17e óra működéssel, 1 bad sectorral, kb. éve van rajta, max 20 bekapcsolás és 200 óra a dsm-ben, előtte egy nsa325-ben töltötte élete nagy részét. A syno topicban volt téma a bad sector limit, én 6.1 alatt megemeltem a bad sector figyelmeztetési szintjét 100-ra. Elvileg a syno default 1, ha eléri a bad sector szám a limitet, akkor a kötet "tönkrement" státuszú lesz, a következő újraindításkor javítja a syno, ha az értesítésen yes, remap the disk-et kér a tulaj (pipa alapértelmezett).
[link] -
kgymac
őstag
válasz sutszi #18284 üzenetére
Nálam 2x3TB-s red van, 16e ill. 17e óra üzemidővel, a 16e-sen van 1 bad sector. A syno topicban volt 1.5-2 éve téma a dsm smart hiba jelzése wd redeknél (csak 4tb-nél jelentkezett). Gyugyo79 pont most postolta a syno topicban, h az SMR-es wd redek körül csak a 2 és 6 TB-s szerepel a komatibilitás listán. DJ Ru$i hdd-i nem SMR-esek (elvileg).
ACA sorozatú 3TB-s toshibáim már többet futottak (6db), egynél fordul elő, h néha raw read error jelentkezik, de 1-2 nap múlva már nincs. Naponta küldetem magamnak a smartctl-lel a szerintem fontos smart attributumokat. Csak tipp, de a raw read error függ attól is, hogy olvas-e egy bizonyos részről a lemezen, más magyarázat nem nagyon van a "megjavulásról". Hibás blokk nincs, a syno sem panaszkodott rá soha.
Egy P300-as külső usb-s házban, ext4, DS tölt rá, eddig semmi problémám vele.
A cégnél P300-as toshibákat vettünk tavaly év végén, amiről most kiderült, hogy SMR. Sajna tényleg háklis rá egy adaptec sata raid vezérlő, már kétszer kiköpte a raid1 kötetből. Centos + mdadm raid1 alatt még rendben megy minden, de hetente kell raid tisztítás.
Céges samuk úgy 57000 óránál tartottak csere előtt. Évek óta nem voltak kikapcsolva vpn+távoli asztal használat miatt. -
DJ. Ru$y
félisten
válasz sutszi #18294 üzenetére
Sajnálom, neked is!
Mivel RAID1 így hála égnek ez nem probléma, elég volt elvesztenem 12 éve tízen pár giga adatot, azóta minimum megvan minden 2x ami nem pótolható. (A RAID1-ről külső merevlemezre mentve van minden érzékeny adat.)
Szakmai kérdésekre privátban nem válaszolok! Használd a fórumot! | R.I.P PH!TV!
-
petir
senior tag
válasz sutszi #18322 üzenetére
Oké, megvan ! Köszönöm szépen! Most már akkor csak az a kérdés adguard vagy pihole.
Ki mit használ?Melyik a hatékonyabb?
Esetleg valaki csinált már leírást?A legjobban a Youtube idegesít TV-n erre egy opció van YoutubeVanced-del indítom de így mindig mobilról kell babrálni...
[ Szerkesztve ]
Új hozzászólás Aktív témák
A Synology szervereinek a Quickconnect használatával történő visszaéléséről szóló hozzászólások vagy témák előzetes értesítés nélkül törlésre kerülnek!
A párosított generátorok (MAC és SN) linkek vagy eszközök is törlésre kerülnek!
A Surveillance Station feltörésére vonatkozó hozzászólások vagy témák és / vagy a feltört / SS hivatkozások létrehozása törlésre kerül előzetes értesítés nélkül.
- Ukrajnai háború
- Redmi Note 12 Pro - nem tolták túl
- EAFC 24
- Vodafone mobilszolgáltatások
- Samsung Galaxy A54 - türelemjáték
- NBA és kosárlabda topic
- Samsung Galaxy A52s 5G - jó S-tehetség
- Házi barkács, gányolás, tákolás, megdöbbentő gépek!
- Debrecen és környéke adok-veszek-beszélgetek
- Konzolokról KULTURÁLT módon
- További aktív témák...
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Promenade Publishing House Kft.
Város: Budapest