Håller med om att Asmedias chipset i olika USB3-SATA produkter har sällan gett några problem och det är just jmicron med dubbel diskplats som har ställt till med fatala problem för min del - och problemet med sådana saker är att under en period så kör alla tillverkare med samma chipset, så det hjälper inte att man kasserar en produkt för att den gör fel och väljer en annan med annan varumärke och utseende och det är samma problem där också och just för att man använder samma chipset och med närmast identisk mjukvara... och problemet när man skall välja andra produkter är att det är oerhört svårt att få ut vilken chipset som används i produkten - i princip måste man köpa hem produkten och plugga in i linux för att se USB-ID:t (tex. med lsusb) och den vägen se var chipseten verka höra hemma.
---
Normalt skall man inte behöva räkna med att det blir sporadiska bitfel vid tex. en kloning med en typisk tillämpning där man dessutom har kloningsfunktion som ett argument i sin marknadsföring för produkten, tycker jag.
När man kör datat över USB och lägger en diskimage på inkopplade disken så är det fortfarande felfritt med deltaco-diskdockan - men under linux har man fortfarande problem med stall i överföringen där USB-porten på diskdockan helt enkelt hänger sig och först efter en USB-bus reset fortsätter (dock utan överföringsfel) och det blir irriterande när stallen kommer med inom 30 sekunders intervall och i linux har man typ 30 sekunder efter stopp innan en bus-reset görs. Dessutom skillnad mellan A-slot och B-slot där B-slot ger färre stopp i överföringen. Nu skall sägas att Linux använder sig av UAS så fort chipseten identifierar sig som UAS-kompatibel medans kör man i BOT-mode (BOT = bulk only transfer) över USB så stöter man inte på samma knirkar som med UAS-mode, särskilt när vissa tillverkare bara har implementerat bara en del av protokollet i ivern att få ut sina chipset tidigt men ändå meddelar sig som UAS-kompatibel... så med deltaco-diskdockan har det i regel gått bättre (men inte perfekt) när man forcerar dess USB-id-nummer att köra i BOT-mode - men det är lite krångel att få det aktivt.
Att allra flesta missar sådan produktfel beror på att ingen verifierar den kopierade imagen med en hash efteråt och bitfelen hamnar sällan på ställen där det gör ont på riktigt och när det blir fel så är det ingen som förknippar det med kloningsprocessen senare då med verifiering skulle ta minst fördubbla tiden och i aktuella fallet handlar det inte om en enda bitfel på kanske körda +10 diskar utan ganska många (ca 1 bit per GB) slumpmässigt spridda.
hade man kört filsystem med checksumma så hade den här typen av fel blivit mycket tydligare - men så länge man kör med NTFS så kan väldigt mycket fel gå under radarn utan att något märker det förrän mycket senare och kanske i kritisk situation.
Nu skall sägas att ext4 är inte så mycket bättre där, men den har i alla fall checksumma på sin metadata vilket NTFS inte har.
