Fórum Ubuntu CZ/SK
Ubuntu pro osobní počítače => Obecná podpora => Téma založeno: Tagy 13 Srpna 2012, 23:11:26
-
Ahoj :)
Prave jsem si prekopiroval svuj stary dobry Debian stable/squeeze na novy SSD disk.
Vse je OK, jen jedine co mi nefunguje je fce TRIM
SSD tuto fci podporuje:
http://www.czc.cz/a-data-s596-turbo-32gb/80370/produkt
Take vypis z hdparm:
hdparm -I /dev/sda | awk '/.*TRIM supported.*/{ if ($1 == "*") print "Yes, TRIM is enabled"; else print "No, TRIM is not enabled.";}'
Yes, TRIM is enabled
V BIOSu, mam nastaveno AHCI (na vyber je jeste ATA...), coz by melo byt OK
Me kroky pri nastavovani:
1)
Vyuziti backports, posledni lnx jadro pro stable nepodporuje TRIM
Stavajici/nove jadro:
root@gaia:/home/m# uname -r 3.2.0-0.bpo.2-amd64
etc/fstab vypada takto:
GNU nano 2.2.4 File: etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
# / was on /dev/sda4 during installation
#UUID=bc1d9ff9-d174-42de-8c6e-ef56af0fc430 / ext4 errors=remount-ro 0 1
UUID=bb907534-2372-4036-8ac2-1c6a27fb377c / ext4 discard,noatime,errors=remount-ro 0 1
# /home was on /dev/sda3 during installation
# Commented out by Dropbox
# UUID=e10376a9-10a6-40b2-b06a-4bcb4f04d33e /home ext3 defaults 0 2
# swap was on /dev/sda2 during installation
#UUID=9fba9ccd-34fd-461c-9e66-675c3034cc8a none swap sw 0 0
/dev/scd0 /media/cdrom0 udf,iso9660 user,noauto 0 0
#UUID=e10376a9-10a6-40b2-b06a-4bcb4f04d33e /home ext3 defaults,user_xattr 0 2
UUID=5d74b861-3dcd-4974-bd9e-4535cd103649 /home ext4 discard,noatime,defaults,user_xattr 0 2
TEST ze to opravdu nefunguje:
root@gaia:/home/m# cd /
root@gaia:/# nano test
root@gaia:/# hdparm --fibmap test
test:
filesystem blocksize 4096, begins at LBA 2048; assuming 512 byte sectors.
byte_offset begin_LBA end_LBA sectors
0 - - -
root@gaia:/# sync
root@gaia:/# hdparm --fibmap test
test:
filesystem blocksize 4096, begins at LBA 2048; assuming 512 byte sectors.
byte_offset begin_LBA end_LBA sectors
0 271064 271071 8
root@gaia:/# hdparm --read-sector 271064 /dev/sda
/dev/sda:
reading sector 271064: succeeded
6673 7765 7766 0a66 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
root@gaia:/# rm t
test tmp/
root@gaia:/# rm test
root@gaia:/# sync
root@gaia:/#
root@gaia:/# hdparm --read-sector 271064 /dev/sda
/dev/sda:
reading sector 271064: succeeded
6673 7765 7766 0a66 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
root@gaia:/#
Posledni vypis by mel byt sama nula...
Poradi nekdo? Diky ;)
-
Ten test není věrohodný. Implementace TRIMu neříká, co se má vracet za správné a jediné hodnoty. Klidně to může být v pořádku. Mé SSD taky vrací shodné hodnoty. V takových testech.
To je jeden neurčitý důvod. Problematika je složitější. Někde jsem o tom četl polemiku, a dávalo to smysl.
Druhá věc co mě napadla, není ten sektor zrovna třeba ve SWAPu?
Třetí věc, nemáš to zašifrované? ;-) (http://worldsmostsecret.blogspot.cz/2012/04/how-to-activate-trim-on-luks-encrypted.html (http://worldsmostsecret.blogspot.cz/2012/04/how-to-activate-trim-on-luks-encrypted.html))
Další test, ale použitelný velmi omezeně je, že po pár měsících nebo rocích spustíš test zápisu na celé SSD a neměly by tam být nějaké propady.
-
Ještě mě zaujal podobný test s flagem direct.
https://sites.google.com/site/lightrush/random-1/checkiftrimonext4isenabledandworking (https://sites.google.com/site/lightrush/random-1/checkiftrimonext4isenabledandworking)
-
Sakra omylem sem to smazal...tak část znovu:
SSD
sudo hdparm -I /dev/sda | grep TRIM
* Data Set Management TRIM supported (limit unknown)
If TRIM is working, then the following should be 0, (assuming / is mount point of the SSD, i.e. /dev/sda mounted on /)
Note, If just enabling and rebooting it probably wont be 0 the first time you do it.
$ sudo fstrim -v /
/: 0 bytes were trimmed
Keep retrying it every few minutes when computer is in use, it should always be 0.
#Clear tmp
rm -rf /tmp/
rm -rf /var/tmp
rm -rf /var/log
#Chrome cache etc uses this by default
rm -rf /home/xxxxx/.cache
ln -s /tmp /var/log?
ln -s /tmp /var/tmp
ln -s /tmp /home/xxxxx/.cache
echo noop > /sys/block/SSDxxx/queue/scheduler
Takže buď máš jen SSD tak si to přidáš do Grub lajny jako elevator=noop vedle splash atd.
Nebo to dáš do souboru rc.local jako echo noop > /sys/block/SSDxxx/queue/scheduler
Lze mít na SSD noop a na HDD CFQ. Někdo dává při kombinaci obou jen DEADLINE. Opravud nevím co je lepší a jak. S tím noopem by měl jet trimm v pohodě. Nevím zda je lepší to mít hend od bootu systému v grub lajně nebo ve texťáku co se načítá až později. A taky nevím co to udělá, když se prohodí sda s sdb např :D
Jo a s tím čištěním bych byl opatrnej a stejně tak s přesměrováním /var/log.
-
ln -s /tmp /var/log?
ln -s /tmp /var/tmp
ln -s /tmp /home/xxxxx/.cache
echo noop > /sys/block/SSDxxx/queue/scheduler
Fakt s /var/log otazníkem? Normálně bych to považoval za překlep, ale v půlce kopírovaného výpisu...
Jinak já hrnu /var/log (a spol) rovnou do tmpfs (ln -s /dev/shm /var/log) - pozor, třeba Apache to nemá rád a je třeba mu upravit startup script...
-
ln -s /tmp /var/log?
ln -s /tmp /var/tmp
ln -s /tmp /home/xxxxx/.cache
echo noop > /sys/block/SSDxxx/queue/scheduler
Fakt s /var/log otazníkem? Normálně bych to považoval za překlep, ale v půlce kopírovaného výpisu...
Jinak já hrnu /var/log (a spol) rovnou do tmpfs (ln -s /dev/shm /var/log) - pozor, třeba Apache to nemá rád a je třeba mu upravit startup script...
Néé :-) To byla poznámka u mě, že se na to ještě mám někdy mrknout.
-
Diky kluci, vse vyzkousim.
Jen jsem ted SSD vyndal, nechovalo se to tak jak by melo, viz nize...
S SSD diskem mi pocitac vytuhnul a musel jsem ho natvrdo vypnout, rozbil se filesystem a ja musel nabootovat z USB gparted a opravit (coz bylo moc fajn kdyz jsem rano spechal do prace, a potreboval jsem se podivat na mapy.cz... no nic jeste ze mam druhej pocitac...)
Dneska z niceho nic prestal fungovat Dropbox, a taky obcas najel a obcas ne celej OS (prepnout se na terminal? Ani nahodou...), ale vsiml jsem si na shellu /to kdyz jsem restartoval/ (ctrl+alt+F2) nejakych erroru pri startu.
Vic napovi log z /var/log/kern.log
Startoval jsem masinu jak s jadrem 2.6.32-5 tak v logu je nove jadro 3.2.0-0.bpo.2-amd64, errory stejne. Pak zase ono stare (nechal jsem si zalohu celeho /boot se starym jadrem)
https://dl.dropbox.com/u/2007219/lnxForum/kernSSD.log (https://dl.dropbox.com/u/2007219/lnxForum/kernSSD.log)
A tohle je kern.log ze sata disku
https://dl.dropbox.com/u/2007219/lnxForum/kernSATA.log (https://dl.dropbox.com/u/2007219/lnxForum/kernSATA.log)
Ten chyby s sda diskem vubec neobsahuje.
Take prikladam vypis logu /SSD/ z gparted
https://dl.dropbox.com/u/2007219/lnxForum/gparted_details.htm (https://dl.dropbox.com/u/2007219/lnxForum/gparted_details.htm)
V tomto stavu to je uplne nepouzitelne... ???
EDIT:
Disk je v poradku...
root@gaia:/home/m# badblocks /dev/sdb
root@gaia:/home/m#
System zkopiruju znovu a jadro nahraju toto:
http://visei.com/2011/08/how-to-enable-trim-for-ssds-in-debian-6-0-squeeze/ (http://visei.com/2011/08/how-to-enable-trim-for-ssds-in-debian-6-0-squeeze/)
EDIT 2:
root@gaia:/home/m# badblocks /dev/sdc
1568256
1568280
1568281
1568282
1568283
13660752
13660760
13660761
13660762
13660763
15371344
15371352
15371353
15371354
15371355
25944592
25944600
25944601
25944602
25944603
root@gaia:/home/m#
Snad to ani komentar nepotrebuje >:(
To same ale se smazanyma partition:
root@gaia:/home/m# badblocks /dev/sdc
16713408
16713432
16713433
16713434
16713435
25944592
25944600
25944601
25944602
25944603
root@gaia:/home/m#
Poslednich par sektoru je stejnych ale co ze se ty predchozi lisi?
-
A tohle je jeste zajimavejsi:
root@gaia:/home/m# badblocks /dev/sdc
16713408
16713432
16713433
16713434
16713435
25944592
25944600
25944601
25944602
25944603
root@gaia:/home/m# badblocks -w /dev/sdc
root@gaia:/home/m#
root@gaia:/home/m#
root@gaia:/home/m#
root@gaia:/home/m#
root@gaia:/home/m#
root@gaia:/home/m#
root@gaia:/home/m# badblocks /dev/sdc
root@gaia:/home/m#
Proc to jednou najde vadne bloky a jednou ne? Tusi nekdo?
-
Proč si kupuješ tu nejhorší značku co je na trhu a pak se divíš?
Adata čipy hoří při trochu větší zátěži ať už jsou v paměťových kartách nebo RAM...
Tím jak to furt testuješ to každou chvíli dorazíš, RIP...