Üdv!

A sötétebb zöld blokkok még nem jelentenek szektorhibát, amit a fejlesztő válasza is szemléltet. Ezeknél valami miatt lassabb az elérés a szokásosnál, ami pl. egy aktív rendszermeghajtónál történő tesztelésnél az éppen futó operációs rendszer és programok miatt annyira nem lenne meglepő. De egy adatlemeznél már nem lehet erre fogni és nem is ideális, ha a lemez teljes felületén periodikusan és sűrűn ismétlődik. Ha csak ennél a dokkolónál produkálja ezt a merevlemez, akkor meg pláne nem. Vagyis ilyenkor ez az adott dokkolóban történő használat miatt lehet, ahol ha adatátviteli hibákat is jelez a program, akkor érdemes lenne első körben egy másik USB-kábellel is kipróbálni. Ahogyan szükség esetén akár másik (megfelelő) tápegységgel is, ha az eredetivel esetleg valami gond van. Ha nem az előbbiek a probléma forrásai, akkor valószínűleg maga a dokkoló, aminél a működésen javítani max. csak a firmware frissítésével lehetne. Volt olyan külső házam, amelynél pl. a HD Tune teszt végig ehhez hasonló esésekkel volt tele, másolásnál is rendre "lebökött". De azt végül a firmware frissítése megoldotta.

A másik dolognál az lehet a probléma, amiről legutóbb pl. ebben a hozzászólásban volt szó bővebben. Vagyis önmagában nem az a gond, hogy az egyik eszköz Initio, a másik meg JMicron chipes, hanem az, hogy USB-n valószínűleg eltérő logikai / fizikai szektorméreteket használnak. Azon pedig az eszköznél max. a firmware módosításával, illetve frissítésével lehet változtatni, ami az előbb linkelt korábbi válaszban is le van írva. Egyébként a gyártók nem nagyon szokták megadni az ilyen külső házaknál és dokkolóknál az erre vonatkozó információt (512e / 4Kn) és rendszerint csak utólag derül ki, hogy valójában mi is a helyzet. Ha kiderül, mert vannak akik csak USB-n, csak abban a külső házban / dokkolóban használják a merevlemezt és úgy nyilván nem okoz gondot. Illetve pont emiatt itt a topikban sincsen minden ilyen eszközzel ilyen irányú tapasztalat.

[ Szerkesztve ]

Szia!

A dokkolónál a gyártó weboldalán nincsen arról információ, hogy kezel-e 2 TB-nál nagyobb HDD-ket. De ha USB 3.0-s és ASM1053 chip van benne, akkor elvileg kellene. A firmware frissítésénél az MP Tool konfigurációs beállításai között az a 2 TB nevezetű opció ahhoz kell, ami egy másik válaszban volt részletezve. Vagyis natív 4K-s (4Kn) logikai és fizikai szektorméretet állít be USB-n és úgy az MBR 2 TB-os korlátja kitolható akár 16 TB-ig is. De ha a dokkoló támogatja a 2 TB+ HDD-ket, akkor nyilván anélkül is kezelnie kellene USB-n egy 3 TB-os merevlemezt GPT partíciós sémával.

Az a leírtakból nem derült ki, hogy a Windows lemezkezelőjében pontosan mi a helyzet. De ha maga a fizikai lemez tárolókapacitása kisebb a valósnál, az abnormális. Egy másik topikban volt korábban másnak ilyen problémája dokkolónál (példa), amit végül a MaxLBA átállítása megoldott. Ha USB-n most netán 4Kn szektorméret lett beállítva a 2 TB-os opció bejelölésével, akkor akár az is okozhat kavarodást (példa). Az alábbi példa pedig azt is szemlélteti, amikor nem kezeli rendesen a külső ház / dokkoló a 2 TB-nál nagyobb tárolókapacitású HDD-t.

[ Szerkesztve ]

Nyilván tud kezelni több partíciót is, ez nem is lehet kérdés. Valamint a gyártó weboldala alapján a > 2 TB HDD-ket is támogatja, tehát az is rendben van. Az viszont nem derült ki, hogy a HDD hol (SATA / USB) lett inicializálva és particionálva, illetve GPT séma szerint, vagy netán másik USB-s külső házban / dokkolóban MBR-re, ami USB-n AF 512e helyett 4Kn szektorméretet használ. Aztán az szintén nem ismert, hogy pontosan mit mutat az adott OS lemezkezelő alkalmazása. Ha az utóbbi Windows (?), akkor a lemezkezelőt kellene megnyitni, ahol jó esetben csak meghajtóbetűjelet kell hozzárendelni a partícióhoz.

[ Szerkesztve ]

Érdekes az első screenshoton a másolásnál a GB/s sebesség, de az elvileg tényleg GB/s lehet, nem Gb/s, nem az utóbbi szerint szokta kiírni a Windows fájlkezelője. Az oka valószínűleg a gyorsítótárazott RAM lehet, meg a külső merevlemeznél a bekapcsolt írási gyorsítótárazás is dobhat rajta főleg apróbb méretű fájlok másolásánál, ilyenkor szoktak a valósnál jóval nagyobb értékek megjelenni. Valamint ha az "Asztal" valamilyen SSD, akkor arra az írás is jóval gyorsabb lehet, mint magára a külső HDD-re. Igaz normál esetben az utóbbi olvasási sebességének limitálni kellene a másolás során, de vélhetően az előbbi okok miatt jöhettek ki ilyen magas értékek.

Aztán ami még érdekes, az szintén az első screenshoton a HDS ATA információk. Az egyiknél 4096 [Advanced Format] (4K), míg a másik simán csak 4096 [Advanced Format]. Az utóbbi az 512e Advanced Format lemezeknél szokott lenni, míg a 4K utótag a natív 4K, más néven 4Kn lemezeknél. Illetve jelen esetben USB-n maga a külső ház használhat 4Kn szektorméretet (check), ellenben a HDD nyilván 512e lehet, akárcsak egy korábbi dokkolós példánál. Ha ez a helyzet, akkor az okozhatja azt a problémát, hogy a 4Kn alapon inicializált és particionált HDD tartalma nem lesz hozzáférhető az 512e megoldást használó külső házban.

[ Szerkesztve ]

A formázásnál csak a lemezfoglalási egységet lehet állítani, ami NTFS fájlrendszernél 16 TB-ig alapértelmezetten 4 KB. Viszont itt most a logikai és a fizikai szektorméret a lényeg, illetve főleg a logikai. Az pedig eleve fix, sima formázással nem lehet módosítani egy ilyen USB-s külső háznál (sem), max. a firmware módosításával, lásd az előzőleg linkelt példát.

USB-n a 4Kn, vagy akár 4Ke néven is emlegetett szektorméretnek, illetve az emulációjának akkor van értelme, ha MBR alapon kell használni egy 2 TB-nál nagyobb tárolókapacitású HDD / SSD meghajtót olyan OS miatt, ami a GPT-t nem kezeli (pl. 32 bites Windows XP). Ugyanis 4 Kn (4Ke) alapon az MBR korlátja kitolható egészen 16 TiB-ig, az 512e alapon megszokott 2 TiB helyett (bővebben). Ezáltal pedig az előbbinél a 32 bites XP is tud kezelni USB-n pl. egy 8 TB-os külső HDD-t MBR-re inicializálva (példa). Valamint a FAT32 fájlrendszer 2 TiB korlátja (512e) 4Kn alapon szintén kitolható 16 TiB-ig. De mivel az XP támogatása már évek óta megszűnt, meg a FAT32 is elavult fájlrendszer és sok OS, tv-készülék stb. eleve kezeli az NTFS-t is, ezért újabban a gyártók sem erőltetik már (annyira) USB-n a 4Kn megoldást. Meg gondolom számodra sem létszükséglet, mivel már nem használsz XP-t és Windowson eleve NTFS-re formázod a külső HDD-ken lévő partíció(ka)t. Bár egyes tévéknél, médialejátszóknál még jól jöhet, amik nem kezelik a GPT-t. Viszont ezeket leszámítva sok értelme nincsen USB-n a 4Kn megoldásnak, sőt adott esetben inkább szívás van miatta, ha a HDD-t később 512e alapon működő külső házba kell áthelyezni, avagy fordítva. Valamint a PC-s használatnál is ezért okoz gondot, mivel ott az 512e HDD SATA-n nyilván 512e alapon lesz kezelve, hiába volt USB-n 4Kn, illetve 4Ke emuláció.

[ Szerkesztve ]

Ha a külső házban 4Kn alapon MBR-re inicializálod a 3 TB-os HDD-t, az addig lesz használható, 1:1-ben hozzáférhető a tartalma, amíg abban a külső házban van. Ha utána berakod a PC-be, ott SATA-n 512e alapon lesz kezelve, ahol 2 TB felett eleve GPT kellene. Vagyis amiatt elvileg ütközés lesz és egyáltalán nem, vagy csak részben lehet hozzáférni a HDD tartalmához.

A megoldás le volt már írva, meg a linkelt példa is szemlélteti.
Vagyis a külső háznál a firmware frissítése, módosítása. Ha ASMedia ASM1053 chipes a Rapid-Case és PID: 55AA azonosítós, akkor annál lehetséges az összefoglalóban leírt módon. De ez egyrészt kényes művelet és csak saját felelősségre alkalmazandó! Másrészt, hogy pontosan melyik firmware jó hozzá ilyen téren, melyiknél van biztosan 512e beállítás, az jó kérdés. Bár a Plugable weboldalán a 130107_91_7d_00 firmware-nél utalnak az 512e támogatásra, de ez korábban másnál (szintén Rapid-Case) gondot okozott az állapotjelző LED működésénél és helyette a 130409_11DA_01 firmware vált be, ami az USBDev oldaláról tölthető le.

[ Szerkesztve ]

Ez a VID:04A9, PID:10D3 elég érdekes, mivel ASMedia chipeknél jellemzően 174C szokott lenni a gyártóazonosító (VID), a PID meg lehet pl. 1053, 1153, 1351, 55AA. A 101203005b06 firmware-verzió viszont már reálisabb, korábban egy másik fórumtagnál szintén USB 3.0-s Sharkoon Rapid-Case külső háznál ugyanilyen firmware volt. Viszont az a leírtak alapján ASM1051 chipet tartalmazott, aminél a VID-PID azonosító is az előbbeknek megfelelő volt.

Igen, a HDS is fel szokta hívni a natív 4K-s (4Kn) szektorméretre a figyelmet és az ATA információknál is megjelöli az Advanced Format után 4K utótaggal.

[ Szerkesztve ]

Mivel 3 TB-os a külső házba tett HDD, ezért értelemszerűen a GPT-t kellene választani az inicializálásnál, máskülönben csak 2 TB (pontosabban 2 TiB —► 2,2 TB) lesz használható MBR partíciós séma és Advanced Format 512e szektorméret (példa) alapon. Ez alól USB-n max. az kivétel, ha 4Kn szektorméretet használ a külső ház, amiről egy másik válaszban volt szó nemrég.

"mit válasszak, hogy a műholdvevőn , ami médialejátszóként is funkcionál működjön a lejátszás"

Itt csak az a kérdés, hogy ezek a készülékek kezelik-e egyáltalán a 2 TB-nál nagyobb tárolókapacitású, illetve GPT séma szerint particionált meghajtókat USB-n. Ha igen, akkor nincs gond, mehet a GPT. Ha nem, akkor viszont nyilván csak az MBR jöhet szóba, de akkor 512e alapon értelemszerűen nem lesz használható a HDD teljes (3 TB) tárolókapacitása. De amúgy ez is csak az ilyen tévé, xy lejátszó, router stb. készülékeknél szokott kérdés lenni, ellenben PC, Mac & desktop OS környezetben nyilván nem téma, pláne modern alapokon nem.

[ Szerkesztve ]

Itt röviden egyrészt annyi a lényeg, hogy ha az "A" külső házban/dokkolóban inicializált és particionált 2 TB+ HDD-t áthelyezed "B" külső házba/dokkolóba, akkor az utóbbiban csak akkor lesz közvetlenül "olvasható", hozzáférhető a tartalma, ha megegyezik USB-n a logikai/fizikai szektorméret. Ha eltérő, azaz egyiknél pl. 4Kn, másiknál 512e, akkor viszont nem és az általad tapasztalt probléma fog fennállni. Amire az egyik megoldás a HDD újrainicializálása és újraparticionálása (példa) lehet a másik ("B") külső házban/dokkolóban, de akkor a rajta lévő adatok is törlődnek. Ha azok megtartása a cél, akkor vissza kell helyezni a HDD-t az eredeti külső házba/dokkolóba ("A") és úgy lementeni őket, vagy eleve ott használni tovább. Másik megoldás a firmware módosítása úgy, hogy USB-n passzoljon a szektorméret "A" és "B" külső ház/dokkoló esetében egyaránt (példa). Ha esetedben az eszköz gyártója biztosított, küldött a support ehhez megfelelő firmware-t, akkor a megoldás elvileg adott.

Másrészt a logikai/fizikai szektorméret meg értelemszerűen USB-s csatlakozásnál, a külső házra/dokkolóra vonatkozóan értendő. Maga a HDD ilyen szempontból másodlagos, mivel USB-n nem annak a szektormérete lesz a döntő, hanem az, amit a külső ház/dokkoló emulál. Valamint a legtöbb mai HDD-nél fixen eleve Advanced Format 512e megoldás szokott lenni, a natív 4K logikai szektorméret max. az egyes enterprise kategóriás, vállalati felhasználásra szánt modelleknél jellemző. Vagyis ha az előbbi van neked, akkor annál nincs olyan, hogy natív 4K-s, max. a fizikai szektorméret lehet annyi, ami a jelen probléma szempontjából viszont lényegtelen. Ahogyan itt az sem számít, hogy a Windowsban milyen lemezfoglalási egységgel formázod a HDD-n lévő partíciót, mivel az a logikai szektorméretre nincsen hatással, hiszen az utóbbi fix érték és USB-n (is) max. a firmware módosításával lehet változtatni rajta. Aztán a partícióeltolás elvileg szintén nem számít ilyen téren, meg annak eleve rendben kell lennie, ha modern operációs rendszerrel, Windowsok esetében ≥ Vista verzióval particionáltad a HDD-ket.

[ Szerkesztve ]

Tehát az "A" és "C" 4Kn szektorméretet használ USB-n, ellenben ha a "B", "D" és "E" tárolóeszköz csak 512n és 512e típusút támogat, akkor az utóbbiakban nyilván nem lesz közvetlenül hozzáférhető az előbbiekben inicializált és particionált 2 TB+ HDD. Illetve itt az is lényeges, hogy az említett probléma általában > 2 TB | GPT felállásnál jellemző, ellenben ≤ 2 TB | MBR lemezek esetében nem (példa). Az a régi Samsung HDD pedig ugye csak 1,5 TB-os és vélhetően MBR séma szerint lett particionálva, meg az még nem 512e Advanced Format, hanem 512n típusú lehet. Vagyis a most leírtak értelmében vélhetően ezért nem kezeli megfelelően pl. a "B" külső ház az "A" és "C" tárolóegységben particionált 3 TB-os és 4 TB-os HDD-ket, ellenben a 1,5 TB-osat igen.

A kézenfekvő megoldás továbbra is az lenne, ami az előző válaszban már említve volt. Vagyis USB-n egységes szektormérettel (pl. 512 bájt logikai) rendelkező külső házakat/dokkolókat használni, szükség esetén beállítani a megfelelőt a firmware-ben. Vagy másik megoldásként nem variálni összevissza a HDD-ket az adott külső házakban/dokkolókban, hanem mindegyiket azzal használni, amelyiknél nem jelentkezik az említett probléma. Vagyis ha pl. az egyik külső ház/dokkoló 4Kn-es, akkor az abban inicializált és particionált 2 TB+ HDD-t nyilván nem rakjuk át egy másik olyanba, ami 512e alapon kezeli, mivel akkor az utóbbiban nem lesz közvetlenül hozzáférhető és használható a HDD, max. csak törlés és újraparticionálás után.

Ha a médialejátszó kezeli USB-n a 2 TB+ HDD-ket, valamint a GPT partíciós sémát és/vagy az MBR 4Kn megoldást, akkor nyilván kellene a 3 TB-osat és a 4 TB-osat egyaránt. Ha egyazon külső házban/dokkolóban, vagy ugyanolyan szektorméretet használó modellben lettek inicializálva és particionálva a HDD-k, akkor meg szintén. Ha nem, ellenben PC-n gond nélkül működnek, akkor az már egyértelműen a médialejátszó hibája, korlátja lehet. De ez az ilyen készülékeknél mondjuk annyira nem meglepő, már az jónak számít, ha kezelik egyáltalán a 2 TB+ és a GPT partíciós séma szerinti lemezeket.

[ Szerkesztve ]

Azért, mert egyrészt a gyártóknak egyszerűen nem szokása bizonyos információkat megadni a specifikációban. Másrészt előfordulhat egy adott külső ház/dokkoló akár többféle vezérlővel, firmware-rel is, eltérő logikai szektorméretet használva, vagyis már csak ezért sem egyszerű egységes információt megadni ezekről. De ez a 4Kn megoldás amúgy már kikopóban van, meg a legtöbb gyártó rendszerint amúgy is csak a GPT partíciós sémát nem támogató OS-ek miatt szórakozott ezzel, lásd pl. a már nem támogatott 32 bites Windows XP esetét. Ennek (4Kn) köszönhetően az XP is kezelte pl. a 8 TB-os külső HDD-ket MBR alapon (példa), illetve ilyenkor egész pontosan 16 TiB a limit. Plusz ezzel a megoldással a FAT32 fájlrendszer 2 TiB korlátja is kitolható 16 TiB-ra, ezzel is játszadoztak egyes gyártók a nagy kompatibilitás jegyében.

Azért nem mindennapos gond, mert egyrészt a 4Kn megoldások már kevésbé jellemzők, lásd az előbb leírtakat. Másrészt korántsem mindenki pakolgatja ide-oda a HDD-ket egyik külső házból/dokkolóból a másikba, vagy éppen veszi ki a PC-ből és utána teszi a külső házba/dokkolóba, vagy éppen fordítva. Ha az adott HDD-t többnyire csak egy bizonyos külső házban/dokkolóban használják, akkor úgy nyilván nem okoz gondot a szektorméret, mindegy hogy 512e / 4 Kn alapon kezeli-e a külső ház/dokkoló USB-n.

Az előző válaszban le van írva, hogy a "B" esetében valószínűleg mi okozhatta a problémát. Ahol a "többé már nem olvassa a 3 és 4TB-seket" gondolom a közvetlen hozzáférésre vonatkozik, mert amúgy normál esetben magát a fizikai lemezt nyilván ki kellett listáznia az OS-nek, majd törlés és újraparticionálás után annak újból használhatónak kellett lennie.

[ Szerkesztve ]

Maga az ASM1153E chip általánosan támogatja az UASP-t, ellenben a tényleges működés már a firmware függvénye lehet. Aztán OS szinten a Windows 10 szintén támogatja, viszont a tényleges működés az adott hardvertől (géptől), annak alaplapi USB 3.X vezérlőjétől, az ahhoz tartozó drivertől is függhet. Vagyis esetedben vagy a külső ház nem támogatja, vagy az adott hardver- és szoftverkörnyezet miatt nem működik. Viszont ha más, UASP-t támogató USB-s tárolóeszközöknél működik az UASP ugyanazon gép és OS párosításnál, akkor egyértelműen az Ewent EW7055 külső ház nem támogatja azt firmware szinten. Ami amúgy nem feltétlen akkora gond, a jelen HDD sebességéhez elég a BOT mód is. Az UASP az USB 3.0 szabvány maximumának éléréséhez feltétel, illetve oda már SSD szükséges a HDD helyett.

A szektorméretnél egy dolog az Advanced Format, ami az említett HDD-nél fixen 512e, vagyis 512/4096 bájt logikai és fizikai szektorméret. Ellenben én a külső házra vonatkozóan kérdeztem, hogy annál USB-n mit mutatnak az alábbi screenshoton lévő parancsok. Azaz pl. nem-e 4Kn, vagyis 4096/4096.

A HDS-nél azok a teljesítményértékek csak a program adatbázisában lévő adatok az említett HDD-nél, nem egy friss mérés eredményei a saját hardver- és szoftverkörnyezetedben. Meg elsődlegesen amúgy is az a mérvadó, amit a HDD gyártója ad meg az adatlapon.

Köszönöm az újabb információkat!

[ Szerkesztve ]

Először inkább annak kellene utánajárni, megkérdezni a tévé gyártójának topikjában, hogy kezel-e egyáltalán a tévé USB-n 2 TB+, illetve 4 TB-os külső HDD-t, valamint GPT partíciós séma szerinti lemezeket. Ha nem, akkor MBR alapon max. 2 TB-os lehet opció, vagy esetleg 4Kn (4Ke) szektorméretes megoldással lehetne összehozni a 4 TB-os kezelését MBR alapon, de az külön mókolást igényelhet és nem is minden külső háznál, gyárilag készre szerelt külső merevlemeznél támogatott.

Ha 3,5"-os, USB 3.0-s külső ház kell, akkor a topik összefoglalójában és pl. ezen hozzászólásban is említve vannak konkrét példák. + Ha visszaolvasol, akkor nemrég egy Ewent és Orico külső házról is volt szó, akár azok is szóba jöhetnek. A külső házba venni és tenni kívánt (belső) merevlemez felül viszont már értelemszerűen azon téma topikjában kellene érdeklődni.

Aztán azt is célszerű fixen eldönteni, hogy biztosan 3,5"-os külső HDD kell-e, vagy nem-e inkább 2,5"-os, valamint biztosan külső házas megoldás, vagy inkább gyárilag készre szerelt. Ha 2,5"-os, akkor 5 TB-ig az is opció, valamint ha van a tévén "HDD 5V 1A" feliratú USB-port, vagy egymás mellett 2 db 0,5 A-es Y-kábel használatához, akkor a tápellátás sem lesz gond. Továbbá pl. az egyes gyárilag készre szerelt WD-knél elvileg van arra lehetőség, hogy MBR séma szerint particionálva is használható legyen a 2 TB+ külső HDD, ami akkor jöhet jól a tévénél, ha nem kezeli a GPT-t. Viszont a gyárilag készre szerelt megoldásokkal nem ezen topik, hanem a külső merevlemezes téma fő topikja foglalkozik.

[ Szerkesztve ]

Az IB-123CL-U3 dokkolónál a gyártó weboldalán is fel van tüntetve, hogy "HDD capacity: Unlimited", azaz nincsen a jelenlegi HDD-k tárolókapacitásához mérten reális limit és nyilván kezel 3-4-6 TB-os HDD-ket. Nem tudom hol olvastál itt olyat, hogy nem kezeli. Max. olyan eset volt, ahol a dinamikus lemez volt a gond USB-n, egy másiknál pedig az 512e vs. 4Kn szektorméret, de egyik sem arról szólt, hogy maga a dokkoló nem kezeli a 3 TB-os HDD-ket.
Ha egyéb kétlemezes dokkolók is érdekelnek, akkor meg lásd a legutóbbi esetnél linkelt modelleket, amelyeknél szintén alap a 2 TB-nál nagyobb tárolókapacitású (pl. 3-4-6 TB) HDD-k kezelése.

[ Szerkesztve ]

Ez a "Tökéletesen felismeri és kezeli az összes vinyómat" pontosan mit jelent, az eredetileg PC-ben SATA-n / USB-n másik külső házban/dokkolóban / USB-n ebben a Sharkoon dokkolóban inicializált és particionált 4 és 6 TB-os merevlemezeket? Csak mert az előzőleg linkelt példában pont az volt a gond, hogy az illetőnél az ugyanilyen dokkolók nem kezelték direktben (törlés és újraparticionálás nélkül) a máshol inicializált, particionált 2+ TB lemezeket, max. a firmware frissítése, módosítása után. Illetve azoknál gyárilag AF 4Kn szektorméret volt USB-n, nem a megszokott 512e.

Amúgy köszönjük a beszámolót!

[ Szerkesztve ]

Ha működik oda-vissza a 2+ TB | GPT HDD-k kezelése, akkor 512e szektorméret és újabb firmware lehet a dokkolónál, meg ezek szerint a gyártó már nem erőlteti az újabb gyártású modelleknél a korábbi 4Kn megoldást. Ez pedig nyilván jobb így, meg korábban is leginkább csak a 32 bites Windows XP miatt szórakoztak egyes gyártók a 4Kn szektormérettel, mivel úgy USB-n MBR alapon az XP is kezelni tudta a 2+ TB-os HDD-ket (példa): De azóta az XP már rég EOL lett és okafogyottá vált ezen beállítás, illetve az újabb Windows-verzióknál már nem téma a GPT kezelése.

A leírt melegedés nem meglepő, mivel ugyan hiába van félig-meddig szabadon a HDD a dokkolóban, attól még egy aktív hűtéses PC házzal ellentétben a dokkoló passzív hűtéses marad, meg a 7200 RPM-es HDD is jobban melegedhet, mint egy 5400-as modell. + Nyáron a magasabb környezeti hőmérséklet miatt is intenzívebb lehet a HDD melegedése, meg ha nem klimatizált a helyiség, ahol üzemel. A max. 44-45 °C általánosan amúgy még úgy-ahogy elmegy, 50 °C körüli, meg pláne afeletti hőmérsékleten viszont már nem tanácsos gyakorta és hosszabb ideig üzemeltetni a merevlemezeket.

Köszönöm!

[ Szerkesztve ]

Ha veszel egy vadonatúj HDD-t, akkor az gyárilag particionálatlan, vagyis nem meglepő, ha az első használatbavételnél a Windowsban először inicializálni (2 TB felett GPT-re), majd particionálni és formázni kell a lemezkezelővel (bővebben). Az meg alap, hogy ha eleve, illetve tartósan a külső házba téve lesz használva a HDD, akkor ott, USB-s csatlakozásnál kell ezeket elvégezni, nem a PC-be téve SATA-n.

A 4K fizikai szektormérettel kapcsolatban lásd egy másik válaszban leírtakat, illetve már többször volt róla szó itt a topikban. Vagyis ha az alábbi szemléltetés alapján tényleg 4Kn (4096/4096) szektorméretet használ USB-n az általad vásárolt külső ház, akkor a 2+ TB | GPT paraméterű HDD tartalma másik külső házban USB-n, vagy a PC-be téve SATA-n nem lesz közvetlenül hozzáférhető, ha az utóbbiaknál eltérő, azaz pl. 512e (512/4096) szektorméret van. Törlés és újraparticionálás után viszont újra használható lesz a HDD, de akkor előtte az adatokat értelemszerűen le kell menteni róla az eredeti környezetbe, illetve külső házba visszahelyezve.

"A majd érkező ORICO ház felfogja ismerni?"

Ha az ORICO külső ház is 4Kn szektorméretet használ USB-n, akkor igen, ha 512e szektorméretet, akkor viszont nem, max. törlés és újrainicializás, újraparticionálás stb. után, lásd az előbb leírtakat. De amúgy nem világos minek összevissza cserélgetni, egyikből a másik külső házba tenni a HDD-t, ha jelenleg megáll a Sharkoon modellben is. Vagy ha ez csak ideiglenes állapot és eleve másik HDD lesz abba rakva, az új meg alapból az ORICO külső házba megy, akkor addig nem kellett volna USB-n beüzemelni, pláne elkezdeni rámásolni az adatokat, stb.

A firmware módosításával, frissítésével jó esetben amúgy megoldható a 4Kn —► 512e váltás az adott külső háznál, dokkolónál (példa). De az egyrészt csak és kizárólag saját felelősségre javasolt, mivel rossz esetben balul is elsülhet (példa)! Másrészt az hirtelen passz, hogy a Swift Case Pro esetében ASM1153E chipnél melyik firmware biztosan 512e és melyik 4Kn, bár a korábbi verzióknál külön is állítható, be/ki kapcsolható volt ez az MP Tool kezelőfelületén.

[ Szerkesztve ]

Az egyrészt előzőleg már le lett írva, hogy a WD My Book sorozatnál a hardveres titkosítás miatt máshol nem lehet hozzáférni a HDD tartalmához, max. törlés és újraparticionálás után lesz újra használható. + Szükség esetén ott van még a 3,3 V pin reset is.
Másrészt arról is volt szó nemrég egy másik esetnél, hogy 2+ TB | GPT felállásnál ha eltérő (pl. 512e vs. 4Kn) logikai-fizikai szektorméretet használ a PC SATA-n - dokkoló/külső ház USB-n, vagy USB-n a 2 dokkoló/külső ház, akkor azért nem lehet majd direktben hozzáférni egyik/másik helyen a HDD tartalmához, max. törlés és újraparticionálás után lesz használható.
Harmadrészt nem derült ki, hogy a külső házban maga a HDD felpörög-e egyáltalán, valamint hogy pontosan mit jelent a nem ismeri fel, azaz pl. Windows esetén megjelenik-e a külső meghajtó az eszközkezelőben és a lemezkezelőben. Ha igen, akkor eleve helytelen az előbbi állítás, miszerint nem ismeri fel. Illetve akkor nem ismeri fel, ha semmilyen szinten nem jelenik meg az eszköz a Windowsban.

[ Szerkesztve ]

Az pontosan mit jelent, hogy "még formázni sem lehet", hol próbáltad, lemezkezelőben, vagy parancssorban, van valami konkrét hibaüzenet is? Valamint esetleg nem a nemrég tárgyalt 512e vs. 4Kn szektorméret miatti problémába futottál bele, ha a HDD-k eredetileg máshol (pl. PC-ben SATA-n) lettek inicializálva és particionálva?

[ Szerkesztve ]

Esetedben pontosan mit is jelent ez a "nem látja az adatokat"?
Ha csak a fájlkezelő alapján állítod, akkor az kb. semmi és pontatlan lehet, mivel ott csak a meghajtóbetűjellel rendelkező lemezek, partíciók jelennek meg. Alap, hogy a lemezkezelőt kellene nézni, ahol akkor van gond, ha pl. GPT-védőpartíció (akár 16 TB formában) vagy RAW a másik külső házban még meglévő NTFS partíció, illetve egy 3 TB-os lemeznél az alábbi screenshoton lévő módon is megjelenhet 2 részben (pl. GPT-védőpartíció + nem lefoglalt terület).

Ha az utóbbi a helyzet a lemezkezelőben, akkor lásd egy másik esetnél leírtakat. Ahol ilyenkor az a gond, hogy eltérő (pl. 4Kn vs. 512e) logikai szektorméretet - amit pl. így lehet megnézni Windowson - használ a 2 külső ház, azért nem kezeli egyik a másikban inicializált és particionált (nem szimplán formázott) 3 TB-os HDD-t.

Ez esetben a lehetőségek az alábbiak:

1. Amit magad is már leírtál: "Most vennem kell egy 3. vinyót, hogy átmásoljam arra az adatokat, majd a Sharkoon-ban megformázni a HDD-t, és visszamásolni az adatokat."
2. Másik külső házat venni és használni, illetve olyat, amelyiknél a logikai szektorméret megegyezik a régi külső házéval. Viszont ez gyakran lutri, mivel a gyártók nem nagyon árulják el melyik milyen (bár korábban pl. az ezen hozzászólásban említett Chieftec 512e szokott lenni), van hogy összevissza módosítják akár ugyanazon modellnél - ezért is fordulhat elő, hogy eltérő a két Swift Case Pro esetében, lásd pl. ezt és ezt az esetet - is, stb.
3. Az új külső háznál a firmware házilagos módosítása, frissítése - lásd a téma összefoglalóban leírtakat - olyanra, hogy passzoljon a logikai szektorméret a régi külső háznál meglévőhöz (csak példa). De ez csak és kizárólag saját felelősségre javasolt! + Már csak azért is, mert a gyártói firmware felhasználó általi házilagos módosítása elvileg garanciavesztéssel járhat és az ASMedia MP Tool esetében nincs lehetőség lementeni a gyári firmware-t egy esetleges későbbi visszaállításhoz, mint pl. a JMicron esetében (csak példa).

[ Szerkesztve ]

"Most van "két ugyanolyan rack", ha meghal az egyik, akkor oda az összes adat, mert se az asztali PC, se a másik rack nem fogja látni a HDD-t."

Az egyrészt max. akkor lehet, ha maga a HDD megy tönkre, a külső ház hibája, illetve az 512e / 4Kn miatti "inkompatibilitás" a jobbik eset. Másrészt egyes adatmentő programok (pl. GetDataBack Pro) képesek akár a korábban USB-n 4Kn (4Ke) szektormérettel kezelt HDD tartalmához 512e alapon PC-ben SATA-s csatlakozásnál, vagy USB-n egy másik külső házba téve is hozzáférni.

A leírtakból egyébként az nem derült ki, hogy megnézted-e milyen logikai + fizikai szektorméretet használ egyik és másik Swift Case Pro. Ha a korábban vásárolt a 4Kn-es és az újabb az 512e, akkor esetleg lehet esély ismét egy újabbnál 512e megoldásra, bár nincs rá garancia. Illetve csak emiatt szvsz felesleges egy 3. ugyanilyen külső házat venni, meg ha nem lesz célirányosan kihasználva, valamint ugye lutri mikor éppen milyet fog ki a vásárló. Az 512e szektorméretet használó külső ház egyébként a jobbik eset, mert alapvetően a 4Kn a problémásabb, amiatt van esetedben is ez az egész kavarodás.

"Ez a firmware frissítés is jó lehetne, de a végén még azt a HDD-t sem fogja látni, amit most lát."

Ilyen értelemszerűen csak akkor lesz, ha annál a külső háznál van utólag módosítva az 512e / 4Kn szektorméret másikra, amelyikben jelenleg van a 3 TB HDD-os és amelyik jelenleg megfelelően kezeli. Ellenben ha a másiknál, akkor annak nyilván semmi köze az előbbihez. Valamint ha pl. az "A" külső ház 512e és abba téve lett inicializálva + particionálva a 3 TB-os HDD, a "B" pedig 4Kn, majd a "B"-nél történik firmware-frissítés és utána a "B" is 512e lesz, akkor értelemszerűen mindkettő rendesen kezelni fogja a 3 TB-os HDD-t és nem kell adatmentő programmal nekiesni, törölni, újrainicializálni és újraparticionálni, stb. Illetve az a lényeg, hogy mindkettőnél azonos legyen a szektorméret, azaz vagy 512e - 512e, vagy 4Kn - 4Kn. Ahol ha szempont, hogy szükség esetén PC-be téve és SATA-n csatlakoztatva is közvetlenül hozzá lehessen férni a 3 TB-os HDD-k tartalmához, akkor az nyilván 512e alapon fog működni, 4Kn (4Ke) esetén nem.

[ Szerkesztve ]

Nem derült ki honnan töltötted le, de amik pl. az USBDev weboldalán vannak, azok az állományok nem szoktak vírusosak lenni és eleve RAR-ba vannak tömörítve. Amik a Plugable weboldaláról vannak linkelve a téma összefoglalóban, azok viszont .exe kiterjesztésű fájlok, de azok sem vírusosak. Ha az utóbbi forrásból próbáltad letölteni a firmware-t, vagy az előbbinél kitömörítés után futtatni az MP Tool programot és arra beriasztott az AV, akkor ott valószínűleg inkább arról lehetett szó, hogy az említett külső antivírus szoftver volt túlbuzgó és adott false positive találatot.

"hdd szektorméret pedig 4096 (advanced format) (4K)"

A HDS-nél a lemezinformációk szektoronként bájtok sora végén a 4K a 4Kn (4Ke) megoldást jelöli, ami pont a rosszabbik eset, meg ha jelenleg mindkét 3 TB-os HDD abban a külső házban lett inicializálva és particionálva. Ez esetben a másik külső házban csak akkor látszana rendesen a HDD, ha annál is 4Kn-es firmware lenne, de hogy pontosan melyik ASM1153E firmware olyan, az hirtelen passz. Illetve a korábbi ASMedia chipek és MP Tool verziók esetén külön be/ki kapcsolható volt a 4Kn a firmware-frissítés, flashelés során, viszont az újabbaknál már nem feltétlen működik ez a külön be/ki jelöléses módszer (példa).
Másik lehetőség lementeni az adatokat a HDD-kről másik fizikai lemezre, aztán a korábban vásárolt Sharkoon külső háznál a meglévő 4Kn-es firmware-t saját felelősségre (!) megpróbálni frissíteni 512e megoldást használóra, majd utána 512e alapon újrainicializálni, újraparticionálni stb. a HDD-ket a külső házakba téve, végül pedig visszamásolni a fájlokat.
Következő lehetőség olyan külső házat vagy dokkolót beszerezni, ami 4Kn-es, de hogy jelenleg pontosan melyik olyan, az passz a korábban leírt ok miatt.

[ Szerkesztve ]

Azért karanténozta, mert false positive találat lehetett, mint már említve volt. Illetve nálam Windowsokon pl. a beépített Defender és az ESET IS szerint is oké az MP Tool, nem ugrik rá egyik sem, ennyit erről.
Az USB 3.0-s ASM1053(E) és ASM1153(E) ASMedia chipekhez egyébként pl. a 2.02-es vagy újabb 2.X verziójú MP Tool használatos, a 3.6.X az USB 3.1 Gen 2 vezérlőkhöz való elsődlegesen, a Product String mezőben is szerepel az USB 3.1 Storage Device megnevezés.

Az meg ugye nem meglepő, ha eredetileg a 4Kn-es külső házban inicializált és particionált 3 TB-os HDD az 512e szektorméretet használó külső házban a linkelt screenshoton lévő módon jelenik meg a lemezkezelőben. Ahol ilyenkor normál esetben bal oldalt a lemez reális kapacitásának kellene megjelennie a lemezkezelőben, nem 2 TB-nak a 3 TB-ból.
Az pedig szintén nem újdonság, hogy GPT-védőpartíciónál inaktívak a lemezkezelőben a törlési, formázási stb. opciók. Ellenben ilyenkor parancssorban megoldható a törlés, majd az újraparticionálás és az újraformázás, amiről már volt szó itt pont a Swift Case Pro kapcsán. Amit lehetőleg a külső házba téve kellene megejteni, ha ott lesz használva a HDD, nem pedig a PC-ben. Bár ha az előbbi USB-n 512e szektorméretet használ, akkor passzol a PC-hez SATA-n, mivel ott is 512e van alapesetben, csak a 4Kn problémás USB-n ilyen szempontból.

Ha többlemezes, illetve azok közül is 4-lemezes külső ház kell, akkor lásd egy másik kérdésben és az arra adott válaszban leírtakat.
Ha nem feltétel mind a 4 db HDD "bedobozolása" egy külső házba és egyidejű használata, akkor másik lehetőség pl. egy HDD dokkoló, illetve abból is akár egy 4-lemezes változat (példa), vagy egy IDE/SATA-USB adapter (példa).

+ Lásd a nemrég tárgyalt másik esetnél leírtakat, ami pláne a PC-ben 512e alapon inicializált és particionált 4 TB-os HDD-nél lehet aktuális, mármint akkor lehet majd a tartalmához közvetlenül hozzáférni, ha az USB-s külső ház / dokkoló / adapter is ugyanolyan (512e) szektorméretet használ. Viszont hogy manapság gyárilag melyik biztosan 512e és melyik 4Kn (4Ke), az passz, bár az utóbbi már egyre kevésbé jellemző.

[ Szerkesztve ]

Annál a korábbi esetnél az volt a gond, hogy eltérő logikai szektorméretet (4Kn vs. 512e) használt USB-n a 2 külső ház, azért nem lehetett normál módon hozzáférni a másikban a HDD tartalmához, a már meglévő partícióhoz. Amiből következik az is, hogy ha megegyezik a szektorméret (pl. 512e) esetedben a Captiva és az új Sharkoon külső házaknál, akkor nyilván nem lesz ilyen gond. Ha eltérő, akkor viszont értelemszerűen lehet. Bár az utóbbinál sem feltétlen minden esetben, mivel főleg 2 TB feletti tárolókapacitású és GPT séma szerint inicializált merevlemezeknél szokott ez probléma lenni, ellenben ≤ 2 TB és MBR felállásnál már nem feltétlen (példa).
+ Az előbbihez kapcsolódóan itt egyébként nem szimpla formázásról van szó, nem az a lényeg, hanem az inicializálás MBR / GPT séma szerint, majd utána a particionálás.

[ Szerkesztve ]

A gyártó weboldaláról vett kép alapján az említett routeren csak Type-A portok vannak, vagyis gondolom egy külön vásárolt Type-A - Type-C kábellel / adapterrel lett megoldva a külső ház csatlakoztatása, meg ha gyárilag csak Type-C - Type-C kábelt mellékeltek az utóbbihoz, ahol a 30 cm meglehetősen rövid, olyan hosszúságút 2,5"-os külső házakhoz szoktak inkább.

Ha a PC-ben SATA-s csatlakozásnál a GPT séma szerint inicializált 12 TB-os HDD utána USB-n a külső házban is használható volt, akkor a külső ház 512e szektorméretet használ, nem 4Kn - lásd egy másik esetnél - megoldást, amely előbbi még a jobbik eset.

A részben fémházas kivitel és a HDD csavaros rögzítési lehetősége előnyös, ha a készenléti (alvó) mód valamint az OS-ben a szoftveres leválasztás (pl. Windows) utáni leállítás is működik, akkor az + pont. Ha gyárilag nem mellékeltek gumitalpakat, az nem feltétlen olyan vészes, mert ugye olyat külön is lehet venni, vagy akár fabrikálni házilag.

A külső ház ára ugyan a megszokottnál kicsit magasabb, de ahhoz képest még nem feltétlen olyan vészes, hogy ez ugye már USB 3.1 Gen 2 (10 Gb/s) Type-C típusú, ahol nyilván ez is tesz rá némi felárat. Bár amit manapság egy 3,5"-os, 7200 RPM-es Seagate IronWolf SATA3 HDD tud (példa), ahhoz pont felesleges az USB 3.1 Gen 2 (10 Gb/s) és elég bőven az USB 3.0 (5 Gb/s) is, meg az előbbi szabvány maximuma SSD-vel használható ki (példa), de mindegy.

Apropó 7200 RPM, ha ilyen HDD-vel tényleg csak langyos a külső ház és intenzívebb használatnál sem melegedik benne túlságosan (pl. 45 és főleg 50 °C fölé), akkor úgy néz ki ez is rendben van.

Köszönjük a beszámolót!

[ Szerkesztve ]

"Támogatja a 3,5 hüvelykes SATA III / II / I merevlemezeket, kapacitástól függetlenül"

Ami szerintem kellően világos és egyértelmű, meg ha másnál 6 TB-os HDD-t is kezel, akkor nyilván nem téma a "legalább 2TB-osat (de akár 4-5 is lehet)". Sőt, akár még pl. 8 - 18(+) TB-osat is kezelne, mivel a jelenlegi HDD-k tárolókapacitásához mérten nincsen tényleges limit. Ami manapság a modern, USB 3.X külső házaknál általában jellemző, max. az egyes régi, USB 2.0-s típusoknál lehet ok aggodalomra, mivel az utóbbiaknál szokott 2 TB-os limit lenni, de itt most ugye eleve nem olyanról van szó és pont ezért nincs miről beszélni.
Itt a HDD illetve az azon lévő partíció kezelése szempontjából probléma max. akkor lehet, hogy ha az a helyzet áll fenn, amiről nemrég volt szó egy másik esetnél. Vagyis ha eltérő logikai szektorméretet használ a külső ház USB-n mint ami a PC-ben van SATA-n / másik külső házban van USB-n, valamint ilyenkor nem a külső házban USB-n, hanem a PC-ben SATA-n / másik külső házban USB-n lett / lesz inicializálva és particionálva a 2+ TB-os HDD. Viszont ha nem 4Kn (4Ke) szektorméretet használ USB-n az AXAGON külső ház (eddig nem említette is senki, hogy 4Kn (4Ke) típust kapott volna), akkor nyilván nincs miről beszélni és nincs miért aggódni, valamint értelemszerűen akkor sem, ha tárolókapacitásról függetlenül eleve a külső házban lenne inicializálva + particionálva a HDD, Továbbá akkor sem, ha ≤ 2 TB tárolókapacitású a HDD és pl. a PC-ben MBR séma szerint lett inicializálva + particionálva, lásd más esetét.

Ha olcsó USB 3.0-s külső ház kell, akkor mind az említett AXAGON, mind az LC-Power megfelelhet a célra. Ahol ugyan nem feltétlen tökéletes egyik sem, az előbbinél volt aki a HDD melegedésére panaszkodott, míg az utóbbinál más a linkelt bejegyzésben a nem túl masszív belső vázat és az erős fényű LED-eket hozta fel. Viszont ha eleve csak ritkán, pár havonta lenne használva a külső ház offline biztonsági mentés célra, akkor nyilván ezek sem különösebben téma, ahogyan az előbb linkelt példában másnál sem volt az ilyen használatnál.

[ Szerkesztve ]

Hol írtak olyan "okosságot", hogy a JMS578 vezérlő egyáltalán nem támogatja a SMART-ot?
Nyilván támogatja, amit egy itteni beszámoló is szemléltet, meg ez kb. alap funkció szokott lenni az ilyen USB-s külső házaknál. + Itt nem szimplán a vezérlő, hanem annál a firmware a lényeg, az utóbbi függvénye hogy támogatja-e pl. az UASP, UNMAP (TRIM), készenléti (alvó) mód, OS-ben az eszköz szoftveres leválasztása után a HDD leállítása funkciókat, valamint 512e vs. 4Kn (4Ke) logikai - fizikai szektorméretet használ, stb.

[ Szerkesztve ]

Ha megnézed ezzel kapcsolatosan a téma összefoglalóban lévő információkat és táblázatot, akkor láthatod, hogy nemhogy 2 TB-os, hanem 6 TB-os HDD-t is kezelhet, sőt akár 8+ TB-osat is az ott feltüntetett vagy annál újabb verziójú firmware-rel.

Az ASMedia MP Tool config ablakában a 2 TB beállítási opció a 4Kn (4Ke) megoldásra utal, azzal az MBR 2 TiB korlátja kitolható egészen 16 TiB-ig.
Ez a "látja, de nem olvassa" nem lett részletezve, de lehet akár annál is probléma az előbbi szektorméret, mármint ha eltérő (pl. 4Kn vs. 512e), lásd itt más eseténél + az ennél leírtakat.

"Kap egy új fw-t, és meglátom"

Az egyrészt csak PID: 55AA azonosítójú típusoknál oldható meg a téma összefoglalóban leírt módon és azoknál is csak saját felelősségre javasolt.
Másrészt ha az a probléma ami az előbb linkelve lett, akkor azt a firmware frissítése max. akkor oldhatja meg, ha módosít a logikai szektorméreten.

[ Szerkesztve ]

• Nem derült ki pontosan hogyan történt az a firmware-frissítés, de nyilván natívan futó Windowson kellene és javasolt elvégezni, nem virtuális gépen vagy egyéb tákolással, meg az ASMedia MP Tool amúgy is .exe kiterjesztésű fájl.
• Aztán az sem derült ki, hogy ha fizikai szemrevételezés után tényleg ASM1051 - ASMT-2105 azonosító lehet ASM1051 és akár ASM1053 chipeknél is - chipről van szó, akkor arra pontosan melyik verziójú firmware lett letöltve és honnan, milyen MP Tool verzióval történt a frissítés, stb.
• Az az előző válaszban már le lett írva, hogy a Config / More Config ablakban az a 2 TB opció a 4Kn (4Ke) szektorméret beállításához - amit alapesetben nem feltétlen kell piszkálni, bejelölni - való és nem feltétlen attól függ, hogy alapvetően kezel-e a külső ház 2 TB-nál nagyobb tárolókapacitású HDD-t vagy sem. + A korábbi "látja, de nem olvassa" állítás továbbra sem derült ki hogy pontosan mit jelent, lemezkezelő alkalmazás mit mutat, stb.
• Arról már volt szó itt többször (példa), hogy az ASMedia MP Tool esetében a Device Info X (kikapcsolt) és O (bekapcsolt), valamint azon belül az Idle Timer = Never értékei nem feltétlen minden esetben a valós állapotot mutatják, van hogy csak a konfigurációs (.ini) fájlból olvassa ki a program az előre betáplált alapértelmezett értékeket.

[ Szerkesztve ]

Dehogy tudja a linuxos ugyanazt mint windowsos változatok, eleve nem érhetők el a linuxos változatban bizonyos beállítási és tesztelési lehetőségek, ritkább ütemben frissítik és adnak ki új verziót, stb., nem véletlenül fizetősek az utóbbiak és ingyenes az előbbi.

Akkor pláne érdekes, ha sima ASM1051 chip esetén is ugyanúgy működnie kellene. Az a 2 TB beállítási lehetőség meg ugye a 4Kn (4Ke) szektorméret emulálásához való, ahol annak is 2 TB felett van értelme, amit ha nem kezel megfelelően a külső ház, akkor igen, akár amiatt is lehetett a probléma a firmware frissítésénél.

[ Szerkesztve ]

Volt már arról szó ebben a topikban is többször (példa), hogy elsődlegesen értelemszerűen mindig a gyártó/termék weboldalán leírt információk és a saját személyes tapasztalat a mérvadók, nem az egyes webáruházakban lévő helyenként hiányos vagy pontatlan információk, értékelések.
Ahol a linkelt webáruházban ez a "megsemmisítette a HDD-n lévő adatokat" ki tudja pontosan mit takar, mivel nem lett kifejtve és itt a topikban sem panaszkodott eddig senki ilyen problémára aki ilyen dokkolót használ. Meg ott konkrétumok nélkül ennyi erővel akár az is lehet, hogy a kedves tulaj csak félreértelmezte az adatok megsemmisülését és valójában nem is történt olyan, vagy ha esetleg igen akkor a saját hardver- és szoftverkörnyezetében nem stimmelt valami, vagy ő maga csinált valamit rosszul (user error) és azért lett gond. Vagy ha nem az előbbiek és nem is a HDD-k hibája miatt történt, akkor még esetleg a gyári hibás dokkoló esete jöhet szóba, de az ugye nem általánosan és nem ténylegesen jellemző minden egyes olyan termékre, hanem csak esetlegesen egyes példányokat érintő eshetőség és ezért az alapján megint nem lehet általánosítani.

Ha már probléma, akkor max. pl. olyan fordulhat elő, ami legutóbb egy másik esetnél lett itt részletezve. Vagyis ha eltérő logikai szektorméretet használ a dokkoló USB-n (pl. 4Kn) mint ami pl. PC-nél van SATA-n (pl. 512e), a felhasználó pedig olyan 2+ TB-os és GPT séma szerinti HDD-t helyez a dokkolóba, ami máshol (nem a dokkolóban) lett inicializálva és particionálva. Viszont eddig nem említette itt senki, hogy az említett dokkolóból 4Kn (4Ke) szektorméretet használó változatot kapott volna. Meg ugye az utóbbi esetben sem arról van szó, hogy megsemmisülnek az adatok, max. nem lehet direktben hozzáférni máshol az eltérő logikai szektorméret miatt a HDD-n lévő partíció tartalmához, ellenben az eredeti helyre visszahelyezve a HDD-t továbbra is hozzáférhető lesz a tartalma.
+ Windowson is pl. a biztonságos szoftveres eltávolítás hiánya okozhat rossz esetben adatvesztést vagy RAW problémát (példa), de az ugye egyben user error is, mármint ha nem használja a dokkoló kedves tulaja a tárolóeszköz fizikai eltávolítása (pl. USB-kábel kihúzása, dokkoló kikapcsolása) előtt.

[ Szerkesztve ]

Az eltérő logikai-fizikai szektorméret miatt lehet, amiről már többször volt szó itt (példa) és a Captiva külső háznál is volt már téma. Ahol esetedben a Captiva USB-n a leírtak alapján 4Kn (4Ke), míg a Kolink USB-n és a PC SATA-n 512e szektorméret szerint kezeli a HDD-t, azért az eltérés.

Lásd a topik téma összefoglalójában lévő + ezeket a példákat egylemezes külső házakra attól függően, hogy pontosan milyen (pl. információs táblázat szerinti jellemzők alapján) kell.

A 4Kn (4Ke) logikai - fizikai szektorméret és amiatt pl. ennél az esetnél részletezett probléma a korábban gyártott, régebbi firmware-rel rendelkező egyes külső házaknál volt jellemző (+ példa), ellenben manapság már aktualitását - GPT partíciós sémát nem támogató asztali operációs rendszerek (pl. 32 bites Windows XP) is kezelni tudják MBR alapon a 2 TB-nál nagyobb tárolókapacitású külső HDD-ket - vesztette ezen megoldás és a mostanság gyártott külső házaknál már csak elvétve találkozni ilyennel (4Ke).

[ Szerkesztve ]

• 2 TB-os tárolókapacitásig inicializálható Windowsoknál (is) MBR és GPT séma szerint egyaránt a HDD / SSD meghajtó. Vagyis ez alapján a kérdésre nyilván igen a válasz, lehet MBR séma szerint is inicializálni a külső házban lévő 2 TB-os HDD-t és aszerint használni.
• 2 TB-os tárolókapacitás felett viszont alapesetben (pl. 512e logikai és fizikai szektorméret) mindenképpen GPT séma szerint kell inicializálni a HDD-t, máskülönben nem lesz particionálható a 2 TB feletti lemezterület (példa). Ez alól a 4Kn (4Ke) logikai és fizikai szektormérettel rendelkező - amit Windowsoknál pl. az ebben a hozzászólásban szemléltetett módon lehet megnézni - USB-s külső merevlemez illetve jelen esetben külső ház lehet kivétel, annál MBR alapon akár 16 TB-ig (pontosabban 16 TiB-ig) is lehet inicializálni és particionálni a belehelyezett HDD / SSD meghajtót, amiről már volt szó itt többször.
• Ha összehasonlítjuk az MBR és GPT sémákat, akkor a GPT-nek eleve vannak bizonyos előnyei az MBR-rel szemben és ezért adott esetben jobb választás lehet a GPT séma használata akár egy ≤ 2 TB tárolókapacitású HDD-nél is.

[ Szerkesztve ]

Lásd egy másik válaszban részletezve, hogy mikor érdemes külső házat és mikor dokkolót használni. Ahol ha esetedben a "C" pontnál leírtak jellemzők, akkor igen, megfelelhet a célra az említett AXAGON ADSA-ST kétlemezes dokkoló.

Ugyanúgy működik egy vadonatúj HDD üzembe helyezése a PC-be (SATA) és a dokkolóba (SATA-USB) téve egyaránt. Ahol a dokkoló esetében is Windowson a lemezkezelőben először inicializálni kell a HDD-t ((4 TB-osat GPT séma szerint) , majd utána particionálni és formázni (elég alapesetben a gyorsformázás) NTFS-re,

A dokkoló / külső ház és a PC vagy másik dokkoló / külső ház közötti "kompatibilitással" akkor szokott gond lenni, ha eltérő a logikai és fizikai szektorméret, az előbbinél pl. 4Kn (4Ke), az utóbbinál pedig 512e (példa). Viszont manapság a 4Kn (4Ke) szektorméretet használó dokkolók és külső házak már egyre kevésbé jellemzők, az újabb gyártású modelleknél rendszerint eleve 512e szektorméret van, vagyis azoknál a 4 TB-os HDD tartalma a dokkolóból a PC-be áthelyezve is közvetlenül hozzáférhető lesz. Ahol az említett AXAGON ADSA-ST dokkolónál rendszerint az 512e szektorméret jellemző, lásd az alábbi kérdésekre adott válaszokban leírtakat.

[ Szerkesztve ]

• Az fsutil fsinfo ntfsinfo x: paranccsal értelemszerűen csak akkor kérdezhető le a logikai-fizikai szektorméret Windowson, amikor már benne van a dokkolóban / külső házban a már inicializált, particionált, NTFS-re formázott, valamint meghajtóbetűjellel rendelkező HDD.
• Az adott dokkolóknál és külső házaknál rendszerint nem szokták közölni a gyártók, hogy milyen logikai-fizikai szektorméretet használ az eszköz, vagyis jobb híján csak a tényleges kipróbálásra, itteni / egyéb tapasztalatokra - más már vett olyat és kipróbálta - lehet hagyatkozni ez ügyben.
• Az előző válaszban már le lett írva, hogy a 4kn (4Ke) megoldás manapság már egyre kevésbé jellemző és az újabb gyártású dokkolóknál, külső házaknál rendszerint 512e szektorméret szokott lenni.
• Ha tönkremegy egy 4Kn (4Ke) szektorméretet használó dokkoló / külső ház és nincsen másik 4Kn-es dokkoló / külső ház amibe a 2+ TB | GPT séma szerinti HDD-t át lehetne tenni, akkor 512e alapon nem lehet közvetlenül hozzáférni a HDD tartalmához, mármint GPT-védőpartícióként fog megjelenni a Windows lemezkezelőjében, lásd egy korábbi válaszban leírtakat. Viszont adatmentő programmal elvileg lehet rá esély, ha tudja kezelni az adott program a 4Kn (4Ke) meghajtókat, lásd ugyancsak egy korábbi válaszban leírtakat.
• Az adatbiztonság ott kezdődik, hogy a fontos adatokról van legalább 1, de inkább 2-3 db különálló biztonsági másolat, lásd az egyik társtopikban bővebben kifejtve. Ahol akkor nyilván nem különösebben lesz téma, ha egy 4Kn-es dokkoló vagy külső ház esetleg tönkremegy, mivel másik tárolóeszközökön 1:1-ben megtalálhatók lesznek ugyanazok a fontos adatok.

[ Szerkesztve ]

• A 4Kn (4Ke) logikai-fizikai szektorméret szokott problémás lenni egy külső háznál / dokkolónál, akkor van az, hogy ha a benne lévő 2+ TB | GPT HDD-t a PC-be helyezik és 512e alapon SATA-n csatlakoztatják, akkor a rajta lévő kötet GPT-védőpartíció / GPT-védőpartíció / RAW formában jelenik meg és nem lehet a szokásos módon pl. a fájlkezelőben hozzáférni a tartalmához.
• Ha a HDD-vel megegyező 512e logikai-fizikai szektorméret használ a külső ház / dokkoló is, akkor viszont nem lesz az előbbi probléma, ami elvileg 512n logikai-fizikai szektorméretnél is érvényes.
• Adott a lehetőség ténylegesen kipróbálni (meg amíg még nincsen telemásolva adottal a HDD), azaz a dokkolóból a PC-be és / vagy a PC-ből a dokkolóba helyezni a HDD-t, akkor világosan látszik majd, hogy mi a helyzet.

[ Szerkesztve ]

"látszólag sem a 4Kn nem megy benne hibátlanul, sem a SMART"

Ezeket nem világos miből sikerült leszűrni, amikor annál az esetnél eleve áramszünet szakította meg a működést, felmerült az USB-kábel esetleges hibája is, stb. Na meg a S.M.A.R.T. támogatása eleve alap szokott lenni az ilyen dokkolóknál, aminek támogatása az említett dokkolónál a termék hivatalos weboldalán is le van írva. Másrészt a 4Kn vagy USB-n inkább 4Ke logikai-fizikai szektorméret támogatása megint más, arról nem is volt szó. Sőt, annál pont az a jó, ha nem 4Kn (4Ke) megoldást használ a dokkoló, hanem 512n / 512e, mivel akkor oda-vissza használható a benne lévő HDD a PC és a dokkoló között, ellenben 4Kn (4Ke) esetén ilyen probléma lehet.

Az AXAGON ADSA-ST eleve kétlemezes dokkoló, míg az AXAGON ADSA-SN csak egylemezes, azért is drágább valamivel az előbbi, mint az utóbbi.
Ha elég egy egylemezes dokkoló, akkor elvileg az ADSA-SN is megfelelhet a célra, meg ha SATA SSD is használva lesz benne és fontos amiatt a TRIM illetve USB-n az UNMAP biztos támogatása.

[ Szerkesztve ]

Ja, hát az nem lett említve eredetileg, hogy 4Kn HDD-vel lenne használva a dokkoló, úgy lehet értelme annak, ha a dokkoló is eleve olyan szektorméretet használ USB-n. Viszont hogy pontosan melyik dokkoló 4Kn (4Ke), azt ne kérdezd, mert azt nem szoktak megadni a gyártók és amúgy is összevissza váltogatják, de manapság már egyre ritkább a 4Kn (4Ke) megoldás.
Ha konkrét példa kell, akkor pl. ebben és ebben a korábbi hozzászólásban volt szó 4Kn (4Ke) dokkolókról, viszont azok közül nem mindegyik kapható már, amelyik igen, annál meg ki tudja maradt-e a korábbi állapot, vagy már módosított rajta a gyártó firmware szinten.

[ Szerkesztve ]

Igen, a leírtak alapján esélyes, hogy itt is a 4Kn (4Ke) vs. 512e logikai-fizikai szektorméret a probléma, akárcsak korábban egy hasonló esetnél, ahol le lett írva erre vonatkozóan a lényeg.

Az ASMedia MP Tool programnak elvileg akár még HDD nélkül is fel kell ismernie a kompatibilis vezérlővel szerelt külső házat, már ha valóban ASM1051 chip van benne, azt mutatja a fizikai szemrevételezés is.
Aztán ugye az ASMedia MP Tool verziója sem feltétlen mindegy, a régebbi ASM1051(E) és ASM1053(E) chipekhez inkább régebbi verziók, pl. az 1.10 és 2.02 használata volt javasolt az itteni tapasztalatok alapján, nem feltétlen a legújabbé (jelenleg 3.7.2.5), utóbbi alapesetben inkább az újabb chipekhez való.

[ Szerkesztve ]

Olyan probléma csak akkor lesz, ha eltérő logikai-fizikai szektorméretet használ a két külső ház / külső ház és a PC, egyik pl. 4Kn (4Ke), míg a másik 512e, lásd korábban egy másik esetnél bővebben kifejtve. Ahol a mostanában gyártott külső házaknál már nem nagyon szokták erőltetni a gyártók ezt a 4Kn (4Ke) megoldást, ami amúgy Windowson is eleve ellenőrizhető egy másik hozzászólásban szemléltetett módon.

Tehát ASMedia chipes PID: 55AA - ahol 55AA azonosítónál ugye frissíthető szükség esetén a firmware a téma összefoglalóban szemléltetett módon, ellenben pl. a 1153 azonosítójú változatnál nem - azonosítóval, ellenben a chip pontos típusa ebből nem derül ki. Igaz az utóbbi sokszor csak fizikai szemrevételezéssel állapítható meg, amihez viszont lehet szét kellene szerelni a dokkolót, de annyit nem ér az egész, meg az ugye garanciavesztéssel is járhat.

A gyártó weboldalán egyébként szépen le van írva kb. minden jellemző erről a dokkolóról, úgyhogy sok kérdés nem marad. Az előbbi mellett esetleg még a logikai-fizikai szektorméret kezelése lehet lényegi információ az 512e vs. 4Kn probléma miatt, de vélhetően 512e megoldást használ, aminek ellenőrzése Windowson egy másik hozzászólásban szemléltetve van.
+ Mivel kétlemezes dokkoló, még az lehet lényeges, hogy pl. 2 db 2,5" / 3,5" HDD-vel mennyire működik stabilan, bírja-e a tápegysége, stb., mert ugye nemrég az is téma volt itt.

Ami viszont nem a legjobban kivitelezett ennél az AXAGON ADSA-DC DUAL CLONE dokkolónál az az, hogy bár USB-C modellként jellemzik, ellenben USB-C csatlakozási lehetőség csak az eszköz (dokkoló) felől van, míg a gazda (PC / Mac) felől a standard USB-A. Ez így szimpla félmegoldás, mivel az USB-C eszközöknél pont az lenne a lényeg, hogy USB-C porthoz is lehessen csatlakoztatni azokat, amit pl. az AXAGON ADSA-M2C DUAL NVMe CLONE dokkolónál már sikerült abszolválni a gyártónak, annál mellékelnek USB-C - USB-C kábelt is az USB-C - USB-A kábel mellé, míg az előbbinél csak USB-C - USB-A kábelt. Úgy látszik a + 1 db kábel már nem fért bele a gyártási költségbe, vagy ki tudja.

Köszönjük a beszámolót!

[ Szerkesztve ]