Keresés

Új hozzászólás Aktív témák

  • Lenry

    félisten

    válasz Jester01 #30519 üzenetére

    Nálam többnyire viszont úgy haltak meg az SSD-k, ahogy most írtad.
    1 vagy 2 olyan volt, aminél valszeg a vezérlő szállt el, mert semmi nem is érzékelte az eszközt

    Gvella Glan! | There are two types of people: Those who can extrapolate from incomplete data

  • Frawly

    veterán

    válasz Jester01 #30519 üzenetére

    Nem tudni mitől döglenek a vezérlők. Szerintem a gyártók méretezik alul tervezett elavulás képpen. Szinte sose a NAND fárad ki, hanem a vezérlő fekszik ki, és ez akkor is megtörténik x időn belül, ha nem írtál a NAND-ra sokat. Nem csak azoknál az SSD-knél, amik a te kezed közé kerültek, hanem kb. az SSD-k 99,9999%-a ilyen.

    (#30517) sh4d0w: nem értem, hogy mi ez, ami van. Az SSD vezérlője nem lát partíciókat, meg fájlokat, meg akármiket. Low level szinten kezeli az adatokat, így ezért mindegy, hogy titkosítva van vagy nincs. Vagyis egy esetben nem mindegy: egész lemezes szoftveres titkosításnál külön át kell engedni a TRIM-et a titkosítási rétegen, különben a vezérlő úgy látja, hogy az egész meghajtó be van telve, minden cellában lévő adatra szükség van, nem szabadíthat fel egy cellát sem. Viszont az átengedett TRIM meg gyengíti a titkosítás biztonságát, mivel mintázati támadást tesz lehetővé. Bár csak elméletileg, olyanról nem olvastam, akinek a titkosított adatait megtörték volna emiatt.

    Aki SSD-t akar titkosítani, annak inkább hardveres titkosítást ajánlom. Egyetlen buktatója, hogy nem elég az SSD-nek tudnia ezt, hanem az alaplapnak és BIOS-nak is támogatnia kell (vagy nem kell, de akkor bootolni nem lehet róla), és a legtöbb konzumer lap nem támogatja, csak a céges kliensek, munkaállomások, üzleti laptopok, stb.. Meg ugye az SSD gyártójának a zárt hardveres titkosítása mindig megbízhatatlan, mivel nyílt forráskód híján csak bízni tudsz benne, hogy nincs az implementációjában gyengeség vagy kiskapu.

Új hozzászólás Aktív témák