[Kideritve(?)]Sony SL-BG1S / TRIM

 ( sza2king | 2016. december 28., szerda - 13:25 )

Hi,

A fenti SSD-vel szerencsetlenkedek mar par napja (korabbi topic).

A kerdes az, hogy az alabbi infok alapjan tudna-e valaki segiteni, hogy vegulis mukodik-e a TRIM vagy nem es ha nem, akkor hogyan tudom bekapcsolni?

Rendszer: Debian 8

fstab:

UUID=509df42d-3390-461b-9bc0-73410017c58d /               ext4    discard,noatime,errors=remount-ro 0       1

# lsblk -D
NAME   DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sdc           0        0B       0B         0
└─sdc1        0        0B       0B         0

# hdparm -I /dev/sdc | grep TRIM
	   *	Data Set Management TRIM supported (limit 8 blocks)
	   *	Deterministic read ZEROs after TRIM

# fstrim -v /
fstrim: /: the discard operation is not supported

A hdparm teljes kimenete itt. Mondjuk a model szam alapjan ("FORESEE 120GB SSD") a google-lel semmi relevans infot nem talaltam errol az SSD-rol.

Van a gepben egy belso Samsung mSATA SSD is, azon NTFS (es Win7) van, Linux alol a belso SSD eseten ezeket latom:

# lsblk -D
NAME   DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda           0      512B       2G         0
└─sda1        0      512B       2G         0

# hdparm -I /dev/sda | grep TRIM
	   *	Data Set Management TRIM supported (limit 8 blocks)

Probaltam firmware-t is keresni, de nem talaltam (nem ujabbat, egyaltalan).

Szoval aggodom, hogy esetleg a TRIM nem mukodik erre a diskre.

Segitene valaki? Koszi.

/sza2

Szerk.:

A google hajlando segiteni, ha jol van megfogalmazva a kerdes. Egy "usb ssd trim" keresesre rengeteg relevans talalat van, es a lenyeg:

Vegigolvasva jo nehany oldalt, szinte mindenhol az a konkluzio, hogy USB-n keresztul nem tamogatott a TRIM.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

A / nincs véletlenül lvm-en?

Nincs LVM.

Annyit csinaltam, hogy a gyarilag NTFS-re formazott egyetlen particiot atformaztam ext4-re (atallitottam az MBR-ban a tipust 83-ra, de ez nem hiszem, hogy barmit is szamit) es atmasoltam a HDD-rol a file-okat, majd egy grub-install-lal bootolhatova tettem.

/sza2

Felmerult meg egy kerdes, az over-provisioninggel kapcsolatban (sajnos az adott eszkozrol gyakorlatilag nem talaltam hasznalhato infot).

Az SSD dobozan illetve a gyarto oldalan 128GB-oskent hirdedik, az OS szamara elerheto kapacitas 120GB, gondolom a 8GB kulonbseg van fenntartva OP-re.

Nekem az jott le, hogy minel tobb hely van az OP szamara, annal nagyobb az eselye, hogy tovabb birja az eszkoz.

Sok helyen azt javasoljak, hogy csinaljunk kisebb particiot a maximalis meretnel, igy novelve a nem hasznalt helyet (ami igy OP celokra hasznalhato).

De itt van az amit nem ertek. Szamomra jelenleg ugy tunik, hogy ket metodus van:
- az SSD sajat vezerlojenek okossaga, ami semmit sem tud a felette levo fajlrendszerrol / OS-rol
- az OS / fajlrendszer tudomanya, hogy minel optimalisabb legyen a flash alapu tarolo hasznalata, de ez csak altalanos dolgokat tud (szamara elerheto terulet, write page size / erase block size), azt nem hogy az alatt levo retegben milyen algoritmus probalja gatolni az elhasznalodast.

Azaz, ha a 120GB-os OS altal elerheto teruletbol csak pl. 110GB-on hozok letre particiot, akkor a 10GB "ures" helyrol az SSD firmware-e nem tudja, hogy hasznalaton kivul van, az OS pedig erintetlenul kell hogy hagyja, mert nem az ove, nem hasznalhatja mint ures helyet.

Vegulis erdemes megis kisebb particiot letrehozni? Ha igen, mi a magyarazata?

/sza2

A merevlemez kapacitása nem 128 GBájt, hanem 128*1000^3 bájt, ami pontosan 119.20929 GiB. Nincs itt semmi fenntartva semmire.

Akar igazad is lehetne, de szerencsere nincs. Itt van kifejtosebben a tortenet.

De ettol fuggetlenul, a kerdes nem ez volt, hanem az, hogy erdemesebb-e kisebb particiot letrehozni mint a max. meret, es ha igen, miert?

/sza2

Az op terület ezen felül szokott lenni, nem a használható kapacitásból jön le (normális terméknél, ára alapján ez már azért az).

Érdemes. Az ssd vezérlője nem foglalkozik partíciókkal, hanem csak az adatokkal. Azaz adott blokkban/cellában van-e adat, vagy nincs. Ha több a szabad hely, akkor az jobb lesz neki, mert egyenletesebben tudja használni a cellákat.
Én úgy szoktam csinálni, h ha magamnak használom, akkor maximumra tolom a partíciót, mert én tudom, h nem szabad megtölteni, de kivételes esetben azért meg tudjam tenni, ha usernak megy, akkor ~20%-al kissebb partíciót kap.

"Azaz adott blokkban/cellában van-e adat, vagy nincs"

De honnan tudja a vezerlo, hogy van-e ott adat vagy nincs?

Illetve, szerintem nincs olyan, hogy "nincs adat", barmi van tarolva egy byte-ben, page-en, block-ban, akarhol, az mindenkeppen adat - de az also reteg honnan tudna, hogy az felulirhato-e (mert mondjuk mar torolhetonek lett nyilvanitva a fajlrendszer reszerol), vagy meg kell tartania? Raadasul a particionalatlan terulet nekem olyan senki foldjenek tunik.

Szoval a kerdes meg nyitott, honnan tudja az SSD, hogy a nem particionalt teruletet szabadon hasznalhatja (torolheti, irhat ra sajat celbol)?

/sza2

128 Gb-os 2.5"-os ssd, laptopban, Xubuntu 16.04.

UUID=0c696e02-253c-4c5e-9f63-b5783de025bf / ext4 errors=remount-ro 0 1

UUID=88fc85fe-6cb3-405f-9f9c-228330571907 /home ext4 defaults 0 2

$ lsblk -D
NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda 0 512B 2G 1
├─sda1 0 512B 2G 1
├─sda2 0 512B 2G 1
└─sda3 0 512B 2G 1

$ hdparm -I /dev/sda | grep TRIM
* Data Set Management TRIM supported (limit 8 blocks)
* Deterministic read ZEROs after TRIM

$ fstrim / -v
/: 978,3 MiB (1025794048 bytes) trimmed
$ fstrim /home -v
/home: 1,5 GiB (1571753984 bytes) trimmed

Szerintem vedd ki az fstab-ból a discard-ot és időzítsd cron-nal inkább.

---
A Linux nem ingyenes. Meg kell fizetni a tanulópénzt.
Az emberek 66 százaléka nem tud számolni! Gondoljatok bele, ez majdnem a fele!!
Mindenki jó valamire. Ha másra nem, hát elrettentő példának.

Bocsi, de lehet, hogy erdemes lenne elolvasnod megegyszer amit irtam.

/sza2