Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
Jak dobrze wyrównać partycje na dysku SSD (Plextor m5p).
Zmarnowałem dużo czasu, a nie posunąłem się za wiele w temacie.
Chodzi mi o te cylindry, głowice i sektory.
fdisk -H 32 -S 32 /dev/sdd
, czy:
fdisk -H 224 -S 56 /dev/sdd
?
Ale to i tak na nic, bo fdisk nie zrobi gtp, a w gdisk, którego do tego używam nie widzę takiej możliwości.
Offline
gdisk robi to automatycznie.
Offline
No tak, ale tylko wyrównuje, a nie ustawia tej magicznej geometrii...
Oną geometrię zalecają zmienić na wiki Debiana.
Offline
einsam napisał(-a):
No tak, ale tylko wyrównuje, a nie ustawia tej magicznej geometrii...
Oną geometrię zalecają zmienić na wiki Debiana.
?
Since wheezy all tools should automatically align filesystems and partitions to the 4096 byte page size. This is one of the most important optimization aspects.
https://wiki.debian.org/SSDOptimization#Partitions_and_Alignment
Partition Alignment
Using partitions that are aligned with the erase block size is highly recommended. In past, this required manual calculation and intervention when partitioning. Many of the common partition tools handle partition alignment automatically (assuming users are using an up-to-date version):
fdisk
gdisk
gparted
parted
https://wiki.archlinux.org/index.php/Solid_State_Dr … ion_Alignment
Offline
Fakt, nie bezpośrednio, ale linkując:
http://www.linux-mag.com/id/8397
http://tytso.livejournal.com/2009/02/20/
Offline
Zwracaj czasem uwagę na taki szczegół — datę.
Powinno wystarczyć to co piszą na wiki.
Ostatnio edytowany przez yossarian (2014-01-14 20:40:13)
Offline
Ależ zwracam:
SSDOptimization (ostatnio edytowane 2013-12-11 21:11:06
Offline
Ja bym to traktował jako lekturę do poduszki dla dociekliwych.
https://wiki.debian.org/SSDOptimization?action=info
Ostatnio edytowany przez yossarian (2014-01-14 20:52:29)
Offline
CHS to przeżytek:
The LBA scheme replaces earlier schemes which exposed the physical details of the storage device to the software of the operating system. Chief among these was the cylinder-head-sector (CHS) scheme, where blocks were addressed by means of a tuple which defined the cylinder, head, and sector at which they appeared on the hard disk. CHS did not map well to devices other than hard disks (such as tapes and networked storage), and was generally not used for them. CHS was used in early MFM and RLL drives, and both it and its successor Extended Cylinder-Head-Sector (ECHS) were used in the first ATA drives. However, current disk drives use zone bit recording, where the number of sectors per track depends on the track number. Even though the disk drive will report some CHS values as sectors per track (SPT) and heads per cylinder (HPC), they have little to do with the disk drive's true geometry.
Więcej tu — http://en.wikipedia.org/wiki/Logical_block_addressing
Ostatnio edytowany przez morfik (2014-01-15 01:18:03)
Offline
Dobra.
A jaki system plików polecacie?
Sprawdzony ext4 czy eksperymentować z f2fs?
Jeśli ext.4, to zakładany z jakimi opcjami?
Na wiki Archa, mamy:
mkfs.ext4 -E discard /dev/sdXY
Chociaż, (jeśli dobrze zrozumiałem man), to nie wiem po co skoro discard jest ustawiany domyślnie?
Attempt to discard blocks at mkfs time (discarding blocks initially is useful on solid state devices and sparse / thin-provisioned storage). When the device advertises that discard
also zeroes data (any subsequent read after the discard and before write returns zero), then mark all not-yet-zeroed inode tables as zeroed. This significantly speeds up filesystem
initialization. This is set as default.
Wiki Gentoo: podać rozmiar bloku:
mkfs -t ext4 -b 4096 /dev/sda2
A to dopiero skromny początek, tego co można znaleźć...
F2fs - mam wątpliwości.
Trochę mało sprawdzony.
Offline
Ja mam tak:
# / was on /dev/sda2 during installation UUID=871d6f4b-ac0a-4736-96da-a61687994dc2 / ext4 noatime,discard,errors=remount-ro,commit=60 0 1 # /home was on /dev/sda4 during installation UUID=c84409a6-44f9-4bf6-87e1-0c635b3485b0 /home ext4 noatime,discard,commit=60,defaults 0 2
Zamiast discard możesz dodać do crona odpalanie fstrim. Czasem to wydajniejsze rozwiązanie.
Działanie TRIM sprawdzisz tak:
http://forum.dug.net.pl/viewtopic.php?pid=244931#p244931
A kiedyś pewnie przesiądę się na btrfs gdy w końcu dojrzeje.
Offline
No to będzie doskonale dojrzały.
Po tylu latach...
Chyba, że "oryginał":
http://zfsonlinux.org/
Offline
Z ext4 problemów nie ma i mi się nie śpieszy ;)
Offline
A tak poza tym coś zmieniałeś w porównaniu dyskiem "zwykłym"?
Bo z różnych czytanek wynika, że najlepiej jak na Ssd nic się nie zapisuje...
Offline
einsam napisał(-a):
A tak poza tym coś zmieniałeś w porównaniu dyskiem "zwykłym"?
Bo z różnych czytanek wynika, że najlepiej jak na Ssd nic się nie zapisuje...
Najlepiej nie wyciągać z kartonu, wtedy sie nic nie zapisze ;)
To co na wiki było: trim i inne opcje montowania, noop, przeniesienie cache przeglądarek do tmp i dalej do Ramu.
Chyba tylko to.
To co piszą w internetach to zazwyczaj nieaktualne i dotyczy starszych generacji dysków ssd.
Offline
Jeszcze muszę wybrać metodę przeniesienia systemu(ów) na nowe partycje.
Pewną metodę.
Fsarchiver jest fajny, ale w tym przypadku niezbyt sensowny.
Chyba zostaje cp, albo rsync?
Co będzie lepsze?
Offline
Bez różnicy, efekt będzie taki sam. Generalnie rsync daje więcej możliwości, ale tutaj to tylko jednorazowe skopiowanie danych z jednej partycji na drugą.
Offline
Piszę z "nowego" systemu.
hdparm -Tt /dev/sda /dev/sda: Timing cached reads: 5278 MB in 2.00 seconds = 2641.50 MB/sec Timing buffered disk reads: 762 MB in 3.00 seconds = 253.93 MB/sec root@debian:/home/tomek# hdparm -Tt /dev/sdb /dev/sdb: Timing cached reads: 4938 MB in 2.00 seconds = 2471.36 MB/sec Timing buffered disk reads: 312 MB in 3.02 seconds = 103.46 MB/sec dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc 1024+0 przeczytanych recordów 1024+0 zapisanych recordów skopiowane 1073741824 bajty (1,1 GB), 5,10787 s, 210 MB/s dd if=tempfile of=/dev/null bs=1M count=1024 1024+0 przeczytanych recordów 1024+0 zapisanych recordów skopiowane 1073741824 bajty (1,1 GB), 4,10788 s, 261 MB/s dd if=tempfile of=/dev/null bs=1M count=1024 1024+0 przeczytanych recordów 1024+0 zapisanych recordów skopiowane 1073741824 bajty (1,1 GB), 0,3907 s, 2,7 GB/s
Dlaczego tak niski jest:
Timing cached reads
Offline
A co w ogóle sprawdzasz?
man hdparm napisał(-a):
-T Dokonuje pomiarów czasu odczytów z cache dla celów porównawczych i testów wydajnościowych. Aby uzyskać miarodajne wyniki, operacja ta powinna być powtarzana 2-3 razy na nieaktywnym pod innymi względami systemie (bez innych aktywnych procesów) z przynajmniej kilkoma megabajtami wolnej pamięci.
Wyświetlana jest szybkość odczytu bezpośrednio z linuksowych buforów cache, bez dostępu do dysku. Wartość ta jest wskaźnikiem przepływu danych między procesorem, cache i pamięcią systemu.
Offline
Generalnie to sprawdzam, prędkości.
Bufor cache "przy okazji".
I nieco niski ni się zdaje.
Offline
Ale to już chyba nie ma nic wspólnego z dyskiem.
Zależy bardziej od konfiguracji sprzętu, systemu, aktualnego obciążenia itp.
Przetestuj w różnych warunkach.
Offline