Otázka na úpravu fstab-u [Vyriešené]

Založil 7R7., 08. 04. 2013, 12:53:11

Předchozí téma - Další téma

7R7.

Dobrý den,
mám dve otázky prvá sa týka úpravy fstab-u SSD disku prečítal som si tento článok http://www.root.cz/clanky/optimalizace-prace-s-ssd-disky-v-linuxu/ a chcem sa uistisť či môžem zápis v fstab-u upraviť podľa tohoto /dev/sda1 / ext4    discard,defaults 0 1
môj výpis z fstab-u: # / was on /dev/sdg1 during installation
                             UUID=4defa702-0834-4479-9a3e-1d0fed1c1d7e /               ext4    errors=remount-ro 0       1
                             # /home was on /dev/sdg5 during installation
                             UUID=aaa60936-63dd-4454-ae0b-e6202e19dbce /home     ext4    defaults        0       2

Počítam že TRIM funguje kedže mám jadro 3.2.x a po zadaní príkazu # hdparm -I /dev/sda|grep TRIM
mi vypíše nasledovné: *    Data Set Management TRIM supported (limit 8 blocks)
                                *    Deterministic read ZEROs after TRIM

A druhá otázka je či nieje niečo zlé nakoľko v fstab-e sú moje disky s debianom označené ako /dev/sdg1 a /dev/sdg5 ale keď dám fdisk -l tak sú tieto disky označené ako /dev/sda1 a /dev/sda5

Roman Horník

Parametr discard použij pro všechny oddíly na SSD, ale osobně bych s tím začal až tehdy, když začne klesat výkon disku na nějakým z oddílů. Přece jen, mazání je de facto přepis navíc, a paměťový buňky mají omezenou životnost. Ještě bych použil navíc i parametry noatime a nodiatime (neaktualizuje se čas přístupu k souborům a ke složkám; mohlo by dojít k jistýmu nárůstu výkonu), parametr defaults nebude potřeba.
K tomu sda vs. sdg- když to funguje, není co řešit.
Debian Sid/Experimental 64bit + Mate Desktop Environment
* CPU: Intel i5 3570
* GPU: NVIDIA GTX650 1GD5
* MB: Lenovo IH61M
* RAM: 16GiB Deutsche Demokratische Republik 3 @ 1600MHz

Palo M.

IMHO discard parameter nesposobi vobec ziaden zapis navyse, len OS oznami disku, ze dany sektor sa uz nepouziva. Az ked sa stanu vsetky sektory daneho bloku nepouzivane (ci uz kvoli tomu, ze boli tiez zmazane, alebo boli modifikovane, cim doslo k ich relokacii do inej oblasti SSD), tak sa zmaze cely blok. Ale to zmazanie je potrebne tak ci tak (technologia - NAND sa neda prepisat, musi sa najprv vynulovat a az potom sa moze zapisat), takze ziaden "zapis navyse" sa nedeje. Finta je v tom, ze zapisuje sa po strankach (4KiB, co je rovne velkosti bloku vacsiny filesystemov, napriklad ext4), ale maze sa po celych blokoch (128 stranok naraz). Ked sa nejaky sektor modifikuje, tak sa jeho stranka oznaci ako nepouzita a novy obsah sa zapise do uplne ineho bloku (a SSD si pamata, ktora LBA je v ktorej oblasti disku)... Ked su vsetky stranky bloku oznacene za nepouzite, SSD zmaze cely blok "do zasoby". Vid popis tu: https://en.wikipedia.org/wiki/Write_amplification#Garbage_collection

Ak sa TRIM zapne az ked zacne klesat vykon disku (tj disk uz nema ziadne volne bloky a pri zapise jedneho sektora musi najprv precitat cely blok, zmenit v RAM len jednu stranku, potom zmazat cely blok a potom zapisat vsetky stranky ktore povazuje za pouzite), tak je to podla mna uz prilis neskoro - tie sektory, ktore boli dovtedy suborovym systemom zmazane, sa uz disku nikdy neoznamia ako zmazane (posielaju sa iba novo zmazane sektory), takze disk ich nemoze znovu pouzit a teda cely blok nemoze byt zmazany, ale na tento blok sa musi vzdy udiat spominane "cvicenie" (citanie-mazanie-zapis celeho bloku) a vykon uz bude stale degradovany a zbytocnych zapisov bude v konecnom dosledku omnoho viac.

Okrem toho SSD disky pouzivaju aj tzv. wear leveling: https://en.wikipedia.org/wiki/Write_amplification#Wear_leveling
V skratke ide o to, ze ak by si raz zapisal nejake sektory a uz ich nikdy neprepisoval (povedzme si ulozis nejaky film ktory mas rad a odvtedy uz ho len mas na disku a pozeras, teda len citas a nikdy ho nezapisujes), tak prislusne bloky by na SSD mali jeden zapis a boli by stale v spickovej kondicii, kym ine bloky (obsahujuce meniace sa data) by sa prepisovali casto a tym sa nicili... Takze cast disku by bola vo vybornej kondicii (ktora by sa ale nikdy neuplatnila), zatialco druha cast disku by bola brutalne opotrebovana. Aby k tomuto efektu nedochadzalo, aplikuje sa spominany wear leveling, teda SSD sam presuva bloky, ktore boli menejkrat modifikovane (aj vtedy, ak OS dane sektory sam nemodifikuje), aby mali vsetky bloky priblizne rovnaky pocet zapisov. Takze ak by si zapol TRIM az po dlhsom case pouzivania SSD, tak tie stranky, ktore boli zmazane pred zapnutim TRIMu, sa budu (donekonecna) relokovat tiez a teda ti vyrazne narastie pocet (naozaj zbytocnych) zapisov.

Ja teda SSD momentalne nemam, ale keby som ho mal (resp. az ho raz budem mat), tak TRIM zapinam okamzite.

7R7.

Ďakujem za odpoveď doteraz som nemal čas sa tomu venovať. Teraz som sa na to dal spravil som secure erase podľa tohotohttp://www.thomas-krenn.com/de/wiki/SSD_Secure_Erase a teraz nastávajú veci kde niesom si na 100% istý a to:
1. pri kontrole po secure erase SSD disku som si všimol hlášky doesn´t contain a valid partition table tak sa chcem spýtať aký typ tam mám dať lebo prvé čo je v gparted je ms-dos ale tento disk bude len pre debian.
2. pochopil som to tak že zarovnanie oddielov sa robí pred delením disku a inštaláciou OS pomocou napr. Live CD? Alebo sa to robí priamo pri inštalácií debianu alebo dokonca po čo sa mi nezdá.

Palo M.

Neviem, kedy/cim bol ten disk rozdeleny. Bolo to pri instalacii Debianu? Ak ano, tak pri instalacii Wheezyho na cisty disk sa oddiely vytvorili a snad by mali byt zarovnane dobre...

Ta hlaska (o absencii partition table) moze byt sposobena tym, ze disk ma GPT rozdelenie. Je tam sice aj protective MBR, ale ten je tak trocha nestandardny (vsetko okrem nulteho sektora je jeden velky oddiel specialneho typu, aby stare programy na nic nesahali - ale pri "standardnej" MBR vacsinou prvy oddiel zacina na 63. sektore, takze niektore programy mozu na tuto "anomaliu" upozornovat.

Odporucam ti pouzit gdisk -l, tam uvidis ci mas GPT alebo MBR. Ak mas GPT, tak si cez gdisk mozes pozriet aj to, ako su oddiely zarovnane. Ak ale gdisk -l vypise, ze nemas GPT, tak ho na ine veci (okrem prepinaca -l) radsej nepouzivaj, aby si si nechtiac neskonvertoval MBR na GPT (samozrejme, ak tu konverziu chces, tak gdisk je dobry nastroj). Ak nemas GPT, tak si cez fdisk -lu pozri, na ktorych sektoroch zacinaju jednotlive oddiely.
Ak nemas na disku ziaden iny system, len Debian, tak GPT je podla mna lepsia volba. MBR a tooly na nu urcene su uz zastarale (nepozeraju na disk ako na sekvenciu blokov, ale cez geometriu Cylinder/Sektor, co uz nezodpoveda realite ani pre klasicke magneticke disky, no a pre SSD je to uz uplne mimo).

Ak by si nahodou nemal oddiely spravne zarovnane, tak ich zarovnanie bude riskantna operacia (teda predtym rozhodne zalohuj data na iny disk)...

7R7.

Disk je teraz uz prazdny, bude tam len debian a grub, na druhom separatnom disku mam win7.
Predtym bol disk deleny len pri instalacii debianu, boli tam dva oddiely / a /home , teraz po secure erase uz tam niesu je tam jeden oddiel, teraz pouzivam Live CD Ubuntu a na tom nieje program gdisk, ale pri fdisk -lu mi vypisalo
ubuntu@ubuntu:~$ sudo fdisk -lu

Disk /dev/sda: 120.0 GB, 120034123776 bytes
255 heads, 63 sectors/track, 14593 cylinders, total 234441648 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/sda doesn't contain a valid partition table

Chcel som si tento disk rozdelit pomocou gparted ale tam mi pise ze najprv musim urobit No partition table found on device /dev/sda. A partition table is required before partitions can be added. To create a new partition table choose the menu item: Device --> Create Partition Table. a teraz neviem ci ho mozem vztvorit?
Este jedna drobnost moja doska ma namiesto BIOSu UEFI, a pri GPT som narazil ze su s tym nejake problemy.
Inac velmi pekne dakujem za rady

7R7.

Ďakujem za rady, podarilo sa mi to vyriešiť.
Partition table som nakoniec po prečítaní pár fórumov nakoniec dal MBR, síce GRUB2 sa mi nenainštaloval pri inštalácii debianu ale toto riešim vždy pri inštalovaní debian a spol na EFI doske a to riešim pomocou Boot-repair-disk zatiaľ nikdy nesklamal.
Disk som si rozdelil a predpripravil pomocou GParted a ten mi aj oddiely zarovnal tak ako mal takže som ďalej zarovnávanie neriešil.
A fstab som upravil nasledovne.
# / was on /dev/sdg1 during installation
UUID=914e8d01-234c-409e-91fb-2f6b19063cd1 /               ext4    errors=remount-ro,noatime,discard   0       1
# /home was on /dev/sdg2 during installation
UUID=9fca1cde-370c-48f1-8e09-ef8dfb80a3cd /home           ext4    defaults,noatime,discard   0       2