zfs + ssd : trim ?
zfs + ssd : trim ?
Mam v priprave skusit raidz2 (4 ssd), server ma radic c202 sata/sas ziadne hba a pod., zol vsak nevie trim. Niekto pise, ze postaci garbage col. a disky plnit max na 80%. Nie je to dokonale, ale ze vraj funkcne. Taky proxmox hodi pool na cely disk, tak ma napadlo spravit resize a skusit to pouzivat. Ma cenu to testovat ? Zatial som mal vsade ext3 skrz lvm snapshot a ext3 som fstrimoval cez cron. Jedna sa hlavne o zivotnost SSD. Je tu moznost pouzit Intel S3500, ale cenovo by to mnohonasobne presiahlo cenu zeleza. Snad to nie je kalamitna otazka ...
-
- Pokročilý používateľ
- Príspevky: 12259
- Dátum registrácie: St 27. Apr, 2011, 11:16
- Bydlisko: ta Blava, ňe ?
Re: zfs + ssd : trim ?
no to som zvedavy aka hlboka debata sa tu strhne.
ZOL : ja v to nemam doveru, ked to porovnas s nativnym FreeBSD/Solaris/vecami tak je to katastrofa. Ziadne seriozne data by som tomu nezveril a na testovanie ti vyhovie cokolvek ine, napriklad FreeBSD respektive webgui derivaty a'la FreeNAS / Nas4free a podobne.
Nie disky plnit na 80%, ale vytvorit na nich particie maximalne 80% a teda zvysok nechat lezat ladom. Vtedy sa na MODERNYCH SSDckach dokaze velmi slusne uplatnit garbage collection. Samozrejme ze TRIM je lepsi, ved na to bol vymysleny - SSD nerozumie filesystemu ktory na nom lezi.
Ma to cenu testovat. Ake disky pouzivas, co si od toho slubujes a kolko zapises denne ?
V neposlednom rade, "cena riesenia" nie je len o cene SSDciek. Aku cenu ma tvoj vypadok ? Kolko si ho mozes dovolit ? Ake je tvoje disaster recovery riesenie a kolko stalo, kedze mas styri rovnake disky - co ked sa nahodou dva pokazia naraz pretoze su z jednej serie a jedneho modelu ? Ked sa ti kvoli vypadku SSD zastavi nejaka vyrobna linka na hocico, tak skody ratas kludne na stovky tisic a nie na haliere ktore zaplatis navyse za S3500 respektive Intel P rady. Kolko casu minies ty ako administrator riesenia aby si vyriesil tuto uzasnu skladacku ? Dva tyzdne nad tym budes maturovat ? Aku to malo cenu len v podobe tvojho platu (nezabudni zaratat odvody platene zamestnavatelom takze superhrubu mzdu) a kto dane riesenie potvrdi ze je v pohode ?
Vies to su take veci...
Takze naspat k najdolezitejsiemu : Ake disky pouzivas, co si od toho slubujes a kolko zapises denne ? Pridam : kolko budes mat dat na tych styroch SSDckach ?
ZOL : ja v to nemam doveru, ked to porovnas s nativnym FreeBSD/Solaris/vecami tak je to katastrofa. Ziadne seriozne data by som tomu nezveril a na testovanie ti vyhovie cokolvek ine, napriklad FreeBSD respektive webgui derivaty a'la FreeNAS / Nas4free a podobne.
Nie disky plnit na 80%, ale vytvorit na nich particie maximalne 80% a teda zvysok nechat lezat ladom. Vtedy sa na MODERNYCH SSDckach dokaze velmi slusne uplatnit garbage collection. Samozrejme ze TRIM je lepsi, ved na to bol vymysleny - SSD nerozumie filesystemu ktory na nom lezi.
Ma to cenu testovat. Ake disky pouzivas, co si od toho slubujes a kolko zapises denne ?
V neposlednom rade, "cena riesenia" nie je len o cene SSDciek. Aku cenu ma tvoj vypadok ? Kolko si ho mozes dovolit ? Ake je tvoje disaster recovery riesenie a kolko stalo, kedze mas styri rovnake disky - co ked sa nahodou dva pokazia naraz pretoze su z jednej serie a jedneho modelu ? Ked sa ti kvoli vypadku SSD zastavi nejaka vyrobna linka na hocico, tak skody ratas kludne na stovky tisic a nie na haliere ktore zaplatis navyse za S3500 respektive Intel P rady. Kolko casu minies ty ako administrator riesenia aby si vyriesil tuto uzasnu skladacku ? Dva tyzdne nad tym budes maturovat ? Aku to malo cenu len v podobe tvojho platu (nezabudni zaratat odvody platene zamestnavatelom takze superhrubu mzdu) a kto dane riesenie potvrdi ze je v pohode ?
Vies to su take veci...
Takze naspat k najdolezitejsiemu : Ake disky pouzivas, co si od toho slubujes a kolko zapises denne ? Pridam : kolko budes mat dat na tych styroch SSDckach ?
Som matematik... Vzrusuju ma cisla, napriklad 8300 na otackomeri alebo 2,15 baru z kompresora a este aj 1-12-5-8-3-10-6-7-2-11-4-9.
Re: zfs + ssd : trim ?
Nejedna sa o miss critical data, doteraz bol kontainer na kazdom ssdcku zvlast a jednalo sa o klasiku SSD Intel do PC, pripadne sumsong 850 pro ... proste nic extra, ide o to aby to ako celok vydrzalo. Proste nejaku tu hodinu, potom tam clovek vymeni disk a spusti sa resil.
Otazka je, ci ten radic bude schopny pracovat ak sa nejaky disk zblazni, pripadne poserie. Zazil som, ze proste masina vytuhla a bolo jedno kolko disko to malo spare atd. Stale sa jednalo o soft raid. Verim, ze co tu mam dalsiu masinu s p410i, 256MB cache toto nenastane (zatial sa nestalo nikdy).
Takze nejedna sa o nejake uber data, ale ide o minimalizovanie vypadku ...
Tych 80% som myslel ako particiu, v ramci disku, zrejme som to zle popisal ...
No na diskusiu som aj ja zvedavy (:
Otazka je, ci ten radic bude schopny pracovat ak sa nejaky disk zblazni, pripadne poserie. Zazil som, ze proste masina vytuhla a bolo jedno kolko disko to malo spare atd. Stale sa jednalo o soft raid. Verim, ze co tu mam dalsiu masinu s p410i, 256MB cache toto nenastane (zatial sa nestalo nikdy).
Takze nejedna sa o nejake uber data, ale ide o minimalizovanie vypadku ...
Tych 80% som myslel ako particiu, v ramci disku, zrejme som to zle popisal ...
No na diskusiu som aj ja zvedavy (:
-
- Pokročilý používateľ
- Príspevky: 12259
- Dátum registrácie: St 27. Apr, 2011, 11:16
- Bydlisko: ta Blava, ňe ?
Re: zfs + ssd : trim ?
Intelacke SSD spachaju po urcenom pocte zapisov samovrazdu (vid testovanie techreport.com). Sumsong 850Pro nazvat nic extra si vyzaduje extremnu davku ignorancie, nic lepsie z hladiska vydrze v consumer class nenajdes. Nebavime sa o rozdiele par percent, bavime sa o mnohonasobkoch zivotnosti beznych SSDciek. Sumsong samotny tvrdi - ale nikto nevidel - ze ich 128GB Pro850tky namlatili 8000 TB a este furt bez najmensich starosti funguju. Bezne 256GB SSDcka skapu niekde okolo 700TB, tie najlepsie okolo 1500TB. Pozor na 256GB versus 128TB, tam sa bavime automaticky o minimalne dvojnasobnej zivotnosti.
A vies co ? Ja ti mam obrovsku tendenciu im verit. Preco ?
a) 3D proces ktory nikto nema (okej, Intel sa zacal vytahovat ale realny produkt nie je a Micron/Toshiba takisto nieco splietaju). Nikto nedokaze povedat o kolko sa zvacsi zivotnost. Vieme ze minimalne 10x podla pesimistickych WMI vnutornych dat SSDciek samotnych (anandtech.com)
b) tie bunky maju 4x nm process. Mozno 40nm, mozno 45nm, nikto nevie. Dnesne SRAGORY maju 1x nm litografiu, 16nm, 19nm, ENTERPRISE ssdcka biju 19/20/25nm. Co dodat.
c) v dosledku 3D usporiadania namiesto klasickeho planar sa ukrutne zmensuje vzajomne ovplyvnovanie susediacich clankov, co nepochybne znasobuje zivotnost.
d) Samsung 845DC Pro, ktory je priamy brat 850Pro, ma garantovanu vydrz 14400 TB pre zapis. Od 850Pro sa lisi PREDOVSETKYM tym ze ma 20% overprovisioning... 1024GB model predavaju ako 800GB. Navyse je to "zastarala" generacia 24vrstvovej 3D technologie, dnes uz mame 32 a 48 vrstiev kde dochadza samozrejme k mensiemu ovplyvnovaniu == vacsej zivotnosti.
e) Sammy 840Pro vydrzal 2000 TB zapisov (techreport.com). Nevidim jediny dovod preco by 850Pro nemal vydrzat minimalne 10x tolko. Skor tak 50x viac...
Na zaklade uvedeneho vyjadrujem moj nazor ze Sammy 850Pro v kapacite 256GB vydrzi polahky 8000 TB na zapis bez toho aby si uprdol. Ocakavam ze realna zivotnost moze byt veselo niekde pri 20.000 TB (cize radovo 80.000 P/E na kazdu bunku) a to je teda ina nálož. Vychadzam z UPLNE BEZNEJ zivotnosti ktoru dosahovali 40nm technologie [!!!] bez 3D [!!!] par rokov dozadu a vobec, ani trosku vobec ju neznasobujem 3D technologiou a inymi pokrokmi/optimalizaciami v priebehu tych vela rokov.
Som vnutorne presvedceny ze v consumer-class oblasti nedokazes spravit nic lepsie z hladiska vykonu a zivotnosti, ako Sammy 850Pro ktory overprovisionujes 20% navrch oproti vyrobcovi. Vtedy namlati 40.000 random 4kB IOPS [!!!] az do armageddonu, velmi spickovo vyrovnanych. Pri 10% overprovisioningu uderi "len" 20.000 IOPS zapisu donekonecna, pri akomkolvek rieseni 90.000 random 4kB IOPS pre citanie. Lepsi consumer class disk z hladiska performance a zivotnosti v tomto momente proste nie je.
A teraz po exkurzii do vyrobneho procesu NAND naspat k povodnemu problemu cirkus ktory si zazil je jednoducho sposobeny SATA diskami a ich konstrukciou. Su schopne zablokovat zbernicu. Cely problem. Posledny moze zhasnut. SAS to riesia uplne inak. Pozor, tym ze na SmartArray P400/P800 zapojis SATA disky, nemas nic vyriesene.
Minimalizovanie vypadku : zase si treba polozit tucet otazok. Preco, na ako dlho, co sme ochotni spravit, kolko mame dukatov, ako a co tie data pouziva, kde mozeme vymysliet jednoduchu a lacnu redundanciu (co napriklad takto Microsoft SQL AlwaysOn / Exchange DAG ; pripade Storage Spaces s multi-path externymi boxami s diskami a duplovanymi radicmi, ved nech si jeden vytuhne, pripadne online == synchronous SW replikacia dvoch nezavislych LACNYCH serverov nech aj jeden z nich zamrzne ako si to uz zazil v dosledku padnuteho disku), proste je tam tuuuuuucet rieseni zavislych od konkretneho nasadenia a co sa musi dosiahnut. Pouzivam VMware s virtualizovanymi aplikaciami pre pristup k tym datam alebo akekolvek ine riesenie ktore nativne podporuje MPIO ? Spracovavaju sa tie data lokalne na tom stroji kde su ulozene (a potom o akej redundancii chcem vobec spekulovat) ? Mozes v najhorsom na infrastrukture kde sa vykonava aplikacia spravit SW raid, kde pole natiahnes medzi dvomi storage a ked sa jeden z nich zasekne tak ta to prilis vzrusovat nebude ?
Mas naladu rozpravat konkretne co potrebujes ? Ale uplne konkretne a detailne ?
A vies co ? Ja ti mam obrovsku tendenciu im verit. Preco ?
a) 3D proces ktory nikto nema (okej, Intel sa zacal vytahovat ale realny produkt nie je a Micron/Toshiba takisto nieco splietaju). Nikto nedokaze povedat o kolko sa zvacsi zivotnost. Vieme ze minimalne 10x podla pesimistickych WMI vnutornych dat SSDciek samotnych (anandtech.com)
b) tie bunky maju 4x nm process. Mozno 40nm, mozno 45nm, nikto nevie. Dnesne SRAGORY maju 1x nm litografiu, 16nm, 19nm, ENTERPRISE ssdcka biju 19/20/25nm. Co dodat.
c) v dosledku 3D usporiadania namiesto klasickeho planar sa ukrutne zmensuje vzajomne ovplyvnovanie susediacich clankov, co nepochybne znasobuje zivotnost.
d) Samsung 845DC Pro, ktory je priamy brat 850Pro, ma garantovanu vydrz 14400 TB pre zapis. Od 850Pro sa lisi PREDOVSETKYM tym ze ma 20% overprovisioning... 1024GB model predavaju ako 800GB. Navyse je to "zastarala" generacia 24vrstvovej 3D technologie, dnes uz mame 32 a 48 vrstiev kde dochadza samozrejme k mensiemu ovplyvnovaniu == vacsej zivotnosti.
e) Sammy 840Pro vydrzal 2000 TB zapisov (techreport.com). Nevidim jediny dovod preco by 850Pro nemal vydrzat minimalne 10x tolko. Skor tak 50x viac...
Na zaklade uvedeneho vyjadrujem moj nazor ze Sammy 850Pro v kapacite 256GB vydrzi polahky 8000 TB na zapis bez toho aby si uprdol. Ocakavam ze realna zivotnost moze byt veselo niekde pri 20.000 TB (cize radovo 80.000 P/E na kazdu bunku) a to je teda ina nálož. Vychadzam z UPLNE BEZNEJ zivotnosti ktoru dosahovali 40nm technologie [!!!] bez 3D [!!!] par rokov dozadu a vobec, ani trosku vobec ju neznasobujem 3D technologiou a inymi pokrokmi/optimalizaciami v priebehu tych vela rokov.
Som vnutorne presvedceny ze v consumer-class oblasti nedokazes spravit nic lepsie z hladiska vykonu a zivotnosti, ako Sammy 850Pro ktory overprovisionujes 20% navrch oproti vyrobcovi. Vtedy namlati 40.000 random 4kB IOPS [!!!] az do armageddonu, velmi spickovo vyrovnanych. Pri 10% overprovisioningu uderi "len" 20.000 IOPS zapisu donekonecna, pri akomkolvek rieseni 90.000 random 4kB IOPS pre citanie. Lepsi consumer class disk z hladiska performance a zivotnosti v tomto momente proste nie je.
A teraz po exkurzii do vyrobneho procesu NAND naspat k povodnemu problemu cirkus ktory si zazil je jednoducho sposobeny SATA diskami a ich konstrukciou. Su schopne zablokovat zbernicu. Cely problem. Posledny moze zhasnut. SAS to riesia uplne inak. Pozor, tym ze na SmartArray P400/P800 zapojis SATA disky, nemas nic vyriesene.
Minimalizovanie vypadku : zase si treba polozit tucet otazok. Preco, na ako dlho, co sme ochotni spravit, kolko mame dukatov, ako a co tie data pouziva, kde mozeme vymysliet jednoduchu a lacnu redundanciu (co napriklad takto Microsoft SQL AlwaysOn / Exchange DAG ; pripade Storage Spaces s multi-path externymi boxami s diskami a duplovanymi radicmi, ved nech si jeden vytuhne, pripadne online == synchronous SW replikacia dvoch nezavislych LACNYCH serverov nech aj jeden z nich zamrzne ako si to uz zazil v dosledku padnuteho disku), proste je tam tuuuuuucet rieseni zavislych od konkretneho nasadenia a co sa musi dosiahnut. Pouzivam VMware s virtualizovanymi aplikaciami pre pristup k tym datam alebo akekolvek ine riesenie ktore nativne podporuje MPIO ? Spracovavaju sa tie data lokalne na tom stroji kde su ulozene (a potom o akej redundancii chcem vobec spekulovat) ? Mozes v najhorsom na infrastrukture kde sa vykonava aplikacia spravit SW raid, kde pole natiahnes medzi dvomi storage a ked sa jeden z nich zasekne tak ta to prilis vzrusovat nebude ?
Mas naladu rozpravat konkretne co potrebujes ? Ale uplne konkretne a detailne ?
Som matematik... Vzrusuju ma cisla, napriklad 8300 na otackomeri alebo 2,15 baru z kompresora a este aj 1-12-5-8-3-10-6-7-2-11-4-9.
-
- Pokročilý používateľ
- Príspevky: 12259
- Dátum registrácie: St 27. Apr, 2011, 11:16
- Bydlisko: ta Blava, ňe ?
Re: zfs + ssd : trim ?
PS: zabudol som asi to najdolezitejsie : naco ti prepana je ZFS a RaidZ2 na STYROCH ssdckach ? To je trosku nezmysel. Sprav si pool s dvomi vdemvi s Raid1, takisto mas 50% kapacity v prdeli, mozu ti padnut dve SSDcka naraz (i ked s podmienkou ze musia byt kazde v inom pooli, lebo ked padnu obidva disky v jednom raide tak vsetky data su v prdeli) ale vykon bude ukrutne niekde inde. Uplne ze porovnavat raidz2 a 2xraid1 je ako porovnavat Daciu a Bentley okrem ceny a spotreby. Navyse v buducnosti vies lepsie "homogennejsie" rozsirovat cely ten ansabel.
Ako by som riesil redundanciu ? Mal by som jedno SSDcko pripravene na policke ak mas masinu dostupnu. Nejake ti padne, samozrejme mas monitoring, notifikaciu atd, dojdes tam s cigou v ruke, vymenis SSDcka - ach ano, urcite mas hotswap takze zaziva - do desiatich minut sa zresilveruje a vymalovane.
PS2 : a vobec musi to byt ZFS ? Pre taketo stvordiskove pouzitie urobit RAID10 (2x Raid1) mozes na vsetkom, ano viem ze RaidZ2 je ine a nevie ho kazdy OS. Ja ti nejako nevidim dobre ten Zfs-on-Linux ale mam pokrivene oko enterprise triedou... ZFS mam natlacene na 18x Sammy 850Pro ale zfs-on-linux mi nevonia.
Ako by som riesil redundanciu ? Mal by som jedno SSDcko pripravene na policke ak mas masinu dostupnu. Nejake ti padne, samozrejme mas monitoring, notifikaciu atd, dojdes tam s cigou v ruke, vymenis SSDcka - ach ano, urcite mas hotswap takze zaziva - do desiatich minut sa zresilveruje a vymalovane.
PS2 : a vobec musi to byt ZFS ? Pre taketo stvordiskove pouzitie urobit RAID10 (2x Raid1) mozes na vsetkom, ano viem ze RaidZ2 je ine a nevie ho kazdy OS. Ja ti nejako nevidim dobre ten Zfs-on-Linux ale mam pokrivene oko enterprise triedou... ZFS mam natlacene na 18x Sammy 850Pro ale zfs-on-linux mi nevonia.
Som matematik... Vzrusuju ma cisla, napriklad 8300 na otackomeri alebo 2,15 baru z kompresora a este aj 1-12-5-8-3-10-6-7-2-11-4-9.
Re: zfs + ssd : trim ?
Ja som dlhorocny odchovanec proxmoxu, ZOL to podporuje a viem, ze to nie je nic extra, proste sa pohravam s myslienkou aspon nejakej redundancie. Ako som uz pisal, doteraz bol kazdy kontainer na jednom SSD, takze s toho ti musi byt jasne, ze o dostupnost extra nejde (zatial). K tej p410, na nej mam sas 10k a nakolko nevie smartpath tak som o sata SSD ani neuvazoval.
Chapem, ze EVO je dieta sumsongu a tak si veria, ale mam skepsu k 3D, tlc. Intel disky tu mam, takze preco to nepouzit.
Raid10 je tiez alternativa. Snazim sa vyhnut kockopsu, ja nemam problem pouzit mdadm, ale pri kazdej aktualizacii proxmoxu sa to rozbije, proste nemaju radi SW raid tohto typu. U ZOL to maju osetrene, nakolko ho podporuju.
Este k tomu co na tom pobezi, nejaka mariadb, postfix, apache. Vykon neni nejak moc treba, tolko iops co ma SSD to zvlasne nadherne pri aktuálnej zatazi.
Ak by som chcel naozaj aby to bezalo nonstop, tak dam zvlast pole a spravim HA cluster a budem tomu verit viac ako zlepencu co chcem spravit. Bohuzial, pre dane podmienky sa snazim trochu improvizovat a hladat riesenia (:
Este padla myslienka na zvlast radic, Fujitsu s tym nema nejaky extra problem, ale u sata s tym nic neziskam ...
Dakujem za kazdu radu a vazim si zatial normalnej diskusie
Chapem, ze EVO je dieta sumsongu a tak si veria, ale mam skepsu k 3D, tlc. Intel disky tu mam, takze preco to nepouzit.
Raid10 je tiez alternativa. Snazim sa vyhnut kockopsu, ja nemam problem pouzit mdadm, ale pri kazdej aktualizacii proxmoxu sa to rozbije, proste nemaju radi SW raid tohto typu. U ZOL to maju osetrene, nakolko ho podporuju.
Este k tomu co na tom pobezi, nejaka mariadb, postfix, apache. Vykon neni nejak moc treba, tolko iops co ma SSD to zvlasne nadherne pri aktuálnej zatazi.
Ak by som chcel naozaj aby to bezalo nonstop, tak dam zvlast pole a spravim HA cluster a budem tomu verit viac ako zlepencu co chcem spravit. Bohuzial, pre dane podmienky sa snazim trochu improvizovat a hladat riesenia (:
Este padla myslienka na zvlast radic, Fujitsu s tym nema nejaky extra problem, ale u sata s tym nic neziskam ...
Dakujem za kazdu radu a vazim si zatial normalnej diskusie
-
- Pokročilý používateľ
- Príspevky: 12259
- Dátum registrácie: St 27. Apr, 2011, 11:16
- Bydlisko: ta Blava, ňe ?
Re: zfs + ssd : trim ?
o EVO tu zatial rec nebola z 3D vobec, ale vobec nemaj strach pretoze je to najblizsia buducnost, 2D uz skoncilo (zapamataj). Potom nastupia tie nove X-vymysly od Intelu a Micronu/Toshiby ale tie budu veeeeeeeelmi drahe (zivotnost prakticky neobmedzena).
Pamataj moje slova : vsetci vyrobcovia budu robit 3D. Respektive tych par firiem to bude vyrabat a vsetci pouzivat.
TLC : tam mas pravdu, tri bity na rozlisenie musi byt horsie ako dva == TLC je horsie ako MLC. Bez debaty. Ale 850Pro nie je TLC. EVO sem neplet, to je hracka pre chudobne deti ktore su prilis bohate na to aby rozmyslali.
Zaver mas spravny, s akymkolvek radicom SATA nic neziskas (mam dojem ze "Fujitsu" radice su LSI, ale nemal som to v ruke takze neviem, Delly robia LSI).
Pamataj moje slova : vsetci vyrobcovia budu robit 3D. Respektive tych par firiem to bude vyrabat a vsetci pouzivat.
TLC : tam mas pravdu, tri bity na rozlisenie musi byt horsie ako dva == TLC je horsie ako MLC. Bez debaty. Ale 850Pro nie je TLC. EVO sem neplet, to je hracka pre chudobne deti ktore su prilis bohate na to aby rozmyslali.
Zaver mas spravny, s akymkolvek radicom SATA nic neziskas (mam dojem ze "Fujitsu" radice su LSI, ale nemal som to v ruke takze neviem, Delly robia LSI).
Naposledy upravil/-a mp3turbo v Ut 10. Nov, 2015, 10:39, upravené celkom 1 krát.
Som matematik... Vzrusuju ma cisla, napriklad 8300 na otackomeri alebo 2,15 baru z kompresora a este aj 1-12-5-8-3-10-6-7-2-11-4-9.
Re: zfs + ssd : trim ?
Sakra nie EVO, ale PRO ... uz sa v tom hrabem moc dlho sry
Este pockam co pride bbwc, premigrujem vpska a potom sa na to vrhnem. Dam ked tak info, ako som to nakoniec poriesil.
Este pockam co pride bbwc, premigrujem vpska a potom sa na to vrhnem. Dam ked tak info, ako som to nakoniec poriesil.
Re: zfs + ssd : trim ?
Nakoniec som dal mdadm -> lvm -> ext4
pre zaujimavost :
ssd raid10
CPU BOGOMIPS: 39908.96
REGEX/SECOND: 1627541
HD SIZE: 7.21 GB (/dev/dm-0)
BUFFERED READS: 911.05 MB/sec
AVERAGE SEEK TIME: 0.15 ms
FSYNCS/SECOND: 96.02
Inak pri 120GB SSD trval rebuild cca 1 min (: ked som dal na test faulty drive
p410i + 10k sas raid10 + bbwc ratio 10/90
CPU BOGOMIPS: 85335.68
REGEX/SECOND: 681166
HD SIZE: 7.75 GB (/dev/dm-0)
BUFFERED READS: 213.19 MB/sec
AVERAGE SEEK TIME: 6.43 ms
FSYNCS/SECOND: 2655.80
Aj by to dalo viac, ale uz bezi a nie je v idle ... viem ze to dalo cca 280-290MB/s
pre zaujimavost :
ssd raid10
CPU BOGOMIPS: 39908.96
REGEX/SECOND: 1627541
HD SIZE: 7.21 GB (/dev/dm-0)
BUFFERED READS: 911.05 MB/sec
AVERAGE SEEK TIME: 0.15 ms
FSYNCS/SECOND: 96.02
Inak pri 120GB SSD trval rebuild cca 1 min (: ked som dal na test faulty drive
p410i + 10k sas raid10 + bbwc ratio 10/90
CPU BOGOMIPS: 85335.68
REGEX/SECOND: 681166
HD SIZE: 7.75 GB (/dev/dm-0)
BUFFERED READS: 213.19 MB/sec
AVERAGE SEEK TIME: 6.43 ms
FSYNCS/SECOND: 2655.80
Aj by to dalo viac, ale uz bezi a nie je v idle ... viem ze to dalo cca 280-290MB/s
-
- Pokročilý používateľ
- Príspevky: 12259
- Dátum registrácie: St 27. Apr, 2011, 11:16
- Bydlisko: ta Blava, ňe ?
Re: zfs + ssd : trim ?
no vidis to, Luki - tie SSDcka sa rebuilduju neskutocne perfektne. Je fakt parada vidiet zrebuildovat terabajtove SSD v priebehu cojaviem 45 az 60 minut, co by klasickym diskom trvalo dva dni
A na rozdiel od mechanickych diskov im prakticky vobec nevadi zataz pola pocas prace, samozrejme sposobene pristupovou dobou a nepotrebou presuvat hlavicky.
A na rozdiel od mechanickych diskov im prakticky vobec nevadi zataz pola pocas prace, samozrejme sposobene pristupovou dobou a nepotrebou presuvat hlavicky.
Som matematik... Vzrusuju ma cisla, napriklad 8300 na otackomeri alebo 2,15 baru z kompresora a este aj 1-12-5-8-3-10-6-7-2-11-4-9.