- Gurulunk, WAZE?!
- Luck Dragon: Asszociációs játék. :)
- gban: Ingyen kellene, de tegnapra
- hcl: Philips M120D/10 kamera hackelés és parajelenségek
- sziku69: Fűzzük össze a szavakat :)
- urandom0: Kicsit most elfáradtam...
- sziku69: Szólánc.
- N€T0X|N: EP2 -> FK2
- gerner1
- sellerbuyer: Milyen laptopot vegyek? Segítek: semmilyet!
-
LOGOUT
Arch Linux topik
Új hozzászólás Aktív témák
-
Frawly
veterán
Ezt egy kicsit bővebben kifejtem, mert nem érthető.
Tehát az SSD-ket ún. lapméret alapján szokták alignálni. Az SSD-n a NAND cellák NAND lapokba vannak rendeződve. De egy darab cellát nem lehet írni/olvasni (az SSD vezérlője nem képes rá), hanem csak egy egész NAND lapot (akkor is, ha csak 1 cellát érint majd a módosítás, olvasás). Ez a lapméret jellemzően 4KB volt a régi SLC-MLC-s SSD-ket, egy ideig még a TLC-seken is, de a modern 3D NAND-on már általában 16 KB vagy még több.
Emiatt a legtöbb particionálóprogi 1024K eltolással particionál, mert az maradék nélkül osztható 4K-s, 8K-s, 16K-s, 32K-s, ..., 512K-s, 1024K-s lapmérettel is, megfelelve a jövőbeni SSD-k igényének is.
Na most itt ebben a topikban valaki német fórumok javaslata alapján felvetette, hogy egy még nagyobb egység, a blokkméret alapján kéne alingálni. Ugyanis a NAND lapok egy még nagyobb egységbe, ún. blokkban is kezelhetők, ennek törléskor, trimeléskor van előnye. A blokkméret általában elég nagy, ilyen több MB-os, SSD-nként eltérő, modern 3D NAND-okon magasabb, mint korábbi 2D-seken, ilyen 6-30 MB nagyjából. Tehát egy blokkban ~1000-es nagyságrendű lap van.
De itt jön a logikai bukfenc. A fájlrendszerek által kezelt logikai szektorok 0,5-4K-sak jellemzően, ez meg is felel, maradék nélkül osztható a 4-16K-s lapmérettel, és az 1024K alignálással, mert így a lemezműveletek nem lógnak át laphatárokon. De tegyük fel, hogy nem blokkméret alapján vannak alignálva a partíciók. Ekkor a partíciók első és utolsó pár szoktora, fizikai lapja átlóghat blokkhatárokon, de ez csak ezt a pár szektort, lapot érinti. De a közöttük lévő szektorokat nem, mert azoknak a lapmérete/szektormérete maradék nélkül osztható a blokkmérettel, így nem lesz olyan köztes lap/szektor, ami blokkhatárokon nyúlna át.
Vegyük például az én átlagos felhasználásomat. Egy régi 3D TLC-s SSD-m van, 16 KB-os lapmérettel, 24 MB-os blokkmérettel (1 blokkban 1536 NAND lap van), és 4KB clusterméretes ext4 partíciókat használok rajta, 512 bájtos logikai szektormérettel. A partíciók 1024K-n vannak alignálva. Ez azt jelenti, hogy a partícióim első 23 megabájtja (1472 lapja vagy 5888 logikai klusztere vagy 47104 logikai szektora) átlóg blokkhatárokon. Az ezek után lévő többi szektor, lap nem lóghat át blokkhatáron, ami a tárterület 99,99%-át jelenti.
A gyakorlatban tehát ezzel annyit bukok, hogy ezeknek a szektoroknak a törlése lassabb egy nagyon minimálisan, talán már ez sem mérhető. De mi annak az esélye, hogy pont az ezekre eső blokkot érinti a törlés? Nagyon minimális. Szóval a gyakorlatban nincs semmi értelme blokkméret alapján alignálni, felesleges önszopatás. Nem nagy áldozat, mert maximum 23 MB veszteséggel járna az első partíció előtt a kihasználatlan terület, de nekem pl. nem tetszene, hogy emiatt nem feltétlenül lennének egész GB-tal osztható partícióméreteim. Ez utóbbi akkor jön jól, ha szétcsesződne a partíciós tábla (bár GPT-n ilyenkor van belőle több másolat), könnyű rekonstruálni a partíciós táblát.
Persze továbbra sem lehetetlen, mert csinálhatnám úgy, hogy partícióméretek ne csak 1 GB-tal, hanem 24 GB-tal legyenek oszthatóak (pl. az első partíció 48 gigás, a második 240, a harmadik 480, stb.), de ez felesleges matek, meg helypocsékolás az első partíció előtt. Ez ilyen tipikus német precízkedés, hogy 0,00000001% előnyért szopjuk, hogy elméletileg is maximálizáljuk a lehetőségeket. Nehogy egy krumlihéjnyi valami is pocséka menjen.
Arról nem is szólva, hogy az adott SSD blokkmérete elég nehezen deríthető ki adott esetben. Az SSD gyártók fel sem tüntetik, hanem be kell azonosítani a NAND típusát (ha ezt sem találni meg online, akkor szét kell szedni az SSD-t, vagy leszedni róla az M.2 matricát, ami azonnali garivesztés, és megnézni milyen NAND van rajta), majd a NAND gyártójának valami részletes technikai spec sheetjéből nyomozható ki. Tényleg nem éri meg vele szívni.
Új hozzászólás Aktív témák
- iPhone topik
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- BestBuy topik
- Budapest és környéke adok-veszek-beszélgetek
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Gyúrósok ide!
- Milyen TV-t vegyek?
- Kamionok, fuvarozás, logisztika topik
- Gurulunk, WAZE?!
- One mobilszolgáltatások
- További aktív témák...
- Xbox Series X 1 TB Játékkonzol! Ajándék Joystick + RGB-s Hűtő!
- ASUS RTX 5060 Ti DUAL OC 8GB GDDR7 DLSS4 új, 3év garis eladó
- Keresek több darab DDR4 memóriát - 8 - 16 GB
- SzinteÚJ! HP Elitebook 860 G10 i7-1355U 16GB 1000GB 16" FHD+ Gar.: 1 év
- GYÖNYÖRŰ iPhone 13 128GB Starlight -1 ÉV GARANCIA - Kártyafüggetlen, MS3434
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest