:fill(white):strip_exif()/i/2003943496.jpeg?f=thumbmini)
:strip_exif()/i/1321263566.png?f=thumbmini)
:strip_exif()/u/70909/BlueKachina_60x60.gif?f=community)
Even niets...
:strip_icc():strip_exif()/u/286431/crop680f6b95743ca_cropped.jpg?f=community)
Je suggereert dat wij (Firedrunk en ik) hetzelfde probleem hebben. Volgens mij is dat niet het geval. 
Ik had last van timeouts met NCQ enabled. Ik had echter geen corrupted bestanden (volgens ZFS dan).
Met de SMART-status van m'n disks is ook niets mis trouwens.
Het lijkt erop dat ik het probleem nu geëlimineerd heb door NCQ uit te schakelen.
Ik had last van timeouts met NCQ enabled. Ik had echter geen corrupted bestanden (volgens ZFS dan).
Met de SMART-status van m'n disks is ook niets mis trouwens.
Het lijkt erop dat ik het probleem nu geëlimineerd heb door NCQ uit te schakelen.
Gewoon een heel grote verzameling snoertjes
Het zijn HD753LJ's, dat zijn dus Spinpoint F1's.
Deze NCQ-bug had ik ook toen ik ZFSGuru als host draaide.
Nu draai ik het als guest in ESXi en het enige probleem waar ik mee te kampen heb, is dat ik huge interrupt storms krijg op irq 16 (wat mijn doorgegeven SATA-controller is), mits ik meer dan 1 core toewijs aan de VM.
(Zie Compizfox in "Zuinige ESXi Server")
Nu heb ik dus maar 1 core toegewezen aan ZFSGuru maar dat is een beetje suboptimaal aangezien ik er een FX-8120 in heb. Die heeft 8 (per core relatief langzame) cores.
[ Voor 8% gewijzigd door Compizfox op 03-03-2013 19:02 ]
Gewoon een heel grote verzameling snoertjes
:strip_icc():strip_exif()/u/61950/hakker.jpg?f=community)
Gebeurt dit al als je geboot ben voor of zie je de degraded state pas als je later kijkt? In het begin al kan komen door het feit dat je HDD's te veel trekken van je voeding tijdens de boot procedure. Dan kunnen ze rustig 25-30 watt trekken om snel te zakken naar de waardes die je normaal verwacht
en met een reset gaan je hdd's niet volledig uit dus gaan ze niet meer door de hoge wattage cycle heen waardoor ze dan wel gevonden worden.
[ Voor 9% gewijzigd door Hakker op 03-03-2013 22:53 ]
Artificial Intelligence is no match for natural stupidity | Mijn DVD's | Mijn Games | D2X account: Hakker9
Ik ben weer wat leuks tegengekomen. ZFS "klaagt" dat één of meer apparaten een onherstelbare fout tegen het lijf zijn gelopen, maar toont vervolgens alle apparaten doodleuk ONLINE... Wat moet ik hier nu weer mee?
De afgebroken scrub komt doordat mijn videoprojecten ineens toch wel heel erg langzaam gingen Deze bak levert namelijk alle originele videobestanden aan de machine die edit
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
| $ sudo zpool status tank
pool: tank
state: ONLINE
status: One or more devices has experienced an unrecoverable error. An
attempt was made to correct the error. Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
using 'zpool clear' or replace the device with 'zpool replace'.
see: http://zfsonlinux.org/msg/ZFS-8000-9P
scan: scrub canceled on Sun Mar 3 23:39:20 2013
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
raidz2-0 ONLINE 0 0 0
ata-HGST_HTS541010A9E680_JB100013J4J15B ONLINE 0 0 0
ata-HGST_HTS541010A9E680_JB100013J4HGNB ONLINE 0 0 0
ata-HGST_HTS541010A9E680_JB100013J2RP1A ONLINE 0 0 0
ata-HGST_HTS541010A9E680_JB100013J3TXGB ONLINE 0 0 0
ata-HGST_HTS541010A9E680_JB100013J3ST5B ONLINE 0 0 0
ata-HGST_HTS541010A9E680_JB100013J422JB ONLINE 5 0 0
cache
usb-SanDisk_Cruzer_Fit_4C532000041129106180-0:0 ONLINE 0 0 0
usb-SanDisk_Cruzer_Fit_4C532000050913100011-0:0 ONLINE 0 0 0
errors: No known data errors |
De afgebroken scrub komt doordat mijn videoprojecten ineens toch wel heel erg langzaam gingen
Deze bak levert namelijk alle originele videobestanden aan de machine die edit
Je hoeft er niks mee, er zijn fouten gevonden met lezen en opgelost door ZFS. Je kan wel even 'zpool clear tank' doen om die '5' naar '0' te krijgen.
Wat je hier ziet is precies waarom je ZFS gebruikt. Er was iets fout en nu niet meer.
Wat je hier ziet is precies waarom je ZFS gebruikt
. Er was iets fout en nu niet meer.
Ah! Ik had die read errors over het hoofd gezien:
Je hoeft er niks mee, er zijn fouten gevonden met lezen en opgelost door ZFS. Je kan wel even 'zpool clear tank' doen om die '5' naar '0' te krijgen.
Wat je hier ziet is precies waarom je ZFS gebruikt
Morgen ff clearen dan en die scrub afmaken. Bedankt!
Dat is een beetje Off topic hier, maar het is een 760 watt seasonic voeding en het gebeurd ook niet elke keer.:
[...]
Gebeurt dit al als je geboot ben voor of zie je de degraded state pas als je later kijkt? In het begin al kan komen door het feit dat je HDD's te veel trekken van je voeding tijdens de boot procedure. Dan kunnen ze rustig 25-30 watt trekken om snel te zakken naar de waardes die je normaal verwacht
Mijn post was meer om te melden dat zfs na zo'n event het file systeem snel weer ok heeft.
8x330 NO12.5°, 8x330 ZW12.5°, 8x350 ZW60°, 8x325 NO10°, SE8K, P500. 6x410 ZW10° Enphase
Nog even wat achtergrond van mijn problemen. Ik draai ZFSguru dus momenteel onder KVM met 2 controllers doorgegeven via Passthrough. In de logs is niets te zien over enige vorm van ATA/AHCI/SAS controller problemen. Het enige wat ik gevonden heb is een lichte crash van het netwerk omdat er een rare bug in VirtIO blijkt te zitten. Waar deze precies door komt is nog onduidelijk, en ook op internet is er nog weinig over te vinden. Het komt alleen voor als er extreem veel verkeer over VirtIO gaat, dan word er ergens een race conditie ofzo getriggerd 
Toen VirtIO eenmaal crashte ging de ZFSguru VM over de flos (op zich begrijpelijk, want er ging een hoop mis met het netwerk). CPU usage van de VM steeg naar 100% en de vm was amper responsive (maar deed het nog wel...).
Toen heb ik de VM gereboot, en dat ging in princpie goed, ware het niet dat de VM na de ** syncing disks ** een foutmelding gaf over het niet kunnen wegschrijven van bepaalde sectoren. Toen ging de VM uit. DAARNA gingen ineens 4 van mijn 10 schijven opspinnen... Heel vreemd...
Nu dus 167MB repaired door de scrub en weer 82 files corrupt en > 1000 checksum errors per disk
Ben een beetje radeloos...
EDIT: Even nagekeken, de ZFSguru VM zelf geeft 0,0 fouten in kernel logs.
Toen VirtIO eenmaal crashte ging de ZFSguru VM over de flos (op zich begrijpelijk, want er ging een hoop mis met het netwerk). CPU usage van de VM steeg naar 100% en de vm was amper responsive (maar deed het nog wel...).
Toen heb ik de VM gereboot, en dat ging in princpie goed, ware het niet dat de VM na de ** syncing disks ** een foutmelding gaf over het niet kunnen wegschrijven van bepaalde sectoren. Toen ging de VM uit. DAARNA gingen ineens 4 van mijn 10 schijven opspinnen... Heel vreemd...
Nu dus 167MB repaired door de scrub en weer 82 files corrupt en > 1000 checksum errors per disk
Ben een beetje radeloos...
EDIT: Even nagekeken, de ZFSguru VM zelf geeft 0,0 fouten in kernel logs.
[ Voor 3% gewijzigd door FireDrunk op 04-03-2013 09:25 ]
Even niets...
:strip_icc():strip_exif()/u/4824/i.jpeg?f=community)
Hm, die problemen heb ik nog niet gehad. Wel een disk die telkens na een powercycle kwijt raakt, maar volgens mij is dat een power kabel probleempje. In mijn 12 disk raidz2 config merk ik wel dat het schrijven niet super snel gaat. Over nfs lijkt 600Mbit/s wel zo'n beetje de max, maar ik weet nog niet waar dat aan ligt. Op dezelfde hardware, maar dan met een 5 disk raidz ging wel met 1Gbit. Misschien toch een slog ssd nodig?:
Nog even wat achtergrond van mijn problemen. Ik draai ZFSguru dus momenteel onder KVM met 2 controllers doorgegeven via Passthrough. In de logs is niets te zien over enige vorm van ATA/AHCI/SAS controller problemen. Het enige wat ik gevonden heb is een lichte crash van het netwerk omdat er een rare bug in VirtIO blijkt te zitten. Waar deze precies door komt is nog onduidelijk, en ook op internet is er nog weinig over te vinden. Het komt alleen voor als er extreem veel verkeer over VirtIO gaat, dan word er ergens een race conditie ofzo getriggerd
Toen VirtIO eenmaal crashte ging de ZFSguru VM over de flos (op zich begrijpelijk, want er ging een hoop mis met het netwerk). CPU usage van de VM steeg naar 100% en de vm was amper responsive (maar deed het nog wel...).
Toen heb ik de VM gereboot, en dat ging in princpie goed, ware het niet dat de VM na de ** syncing disks ** een foutmelding gaf over het niet kunnen wegschrijven van bepaalde sectoren. Toen ging de VM uit. DAARNA gingen ineens 4 van mijn 10 schijven opspinnen... Heel vreemd...
Nu dus 167MB repaired door de scrub en weer 82 files corrupt en > 1000 checksum errors per disk
Ben een beetje radeloos...
EDIT: Even nagekeken, de ZFSguru VM zelf geeft 0,0 fouten in kernel logs.
Ik volg je helemaal niet...
Ik begrijp niet waarom je mij quote
Ik begrijp niet waarom je mij quote
[ Voor 46% gewijzigd door FireDrunk op 04-03-2013 09:45 ]
Even niets...
Das mooi
Wat ik probeer te vertellen is het volgende, ik heb nu een 12 disk raidz2 config. Vanaf een andere host daarna toe schrijven gaat met max 600Mbit/s.
In dezelfde machine heb ik ook een 5 disk raidz config gehad, het schrijven daarna toe ging met 1Gbit/s.
Beide vanaf dezelfde source, waarbij de ZFSGuru vm de target is.
Oh zo
Omdat ik hetzelfde doe, ZFSGuru in een KVM vm draaien, met VirtIO en vt-d voor de M1015 kaarten.
[ Voor 61% gewijzigd door B2 op 04-03-2013 09:51 ]
Aaaaah, kijk, dat is zeker bruikbare informatie! 
Welke versie OS en KVM (en eventueel LibVirt) heb je?
Welke versie OS en KVM (en eventueel LibVirt) heb je?
Even niets...
Fedora 17:
Aaaaah, kijk, dat is zeker bruikbare informatie!
Welke versie OS en KVM (en eventueel LibVirt) heb je?
code:
1
2
3
| kernel 3.7.9-104 qemu-kvm-1.0.1-4 libvirt-0.9.11.9 |
Files corrupt moet zijn dat ZFS ofwel niet bij de data kan, ofwel dat de data misvormd is. Ik zou suggereren: start eens iets met BSD ZFS op zonder virtualisatie. Een USB-stick met ZFSguru of wat dan ook.:
Nu dus 167MB repaired door de scrub en weer 82 files corrupt en > 1000 checksum errors per disk
Wat ik namelijk verwacht is dat zodra ZFS bugvrij je disks kan aanspreken die 82 corrupte files ook moeten verdwijnen. Hoezo heb je filecorruptie die je pool niet kan corrigeren? Ik neem aan dat je een redundante poolconfiguratie draait namelijk. Misschien je pool config posten inclusief error timers?
In elk geval, dat is wat ik zou doen: even geen virtualisatie en kijken of je die corrupte files kunt terughalen. Ik neem verder aan dat je je RAM kunt vertrouwen; checksum errors random verdeeld over meerdere/alle disks ruikt naar RAM corruptie.
Nu thuis, server gereboot en kernel 3.8.0 draait nu prima.
Ik zie ook geen checksum errors meer, maar mijn SMART waardes zijn nu wel nog steeds bagger (veel multi zone errors en een hoop program count errors)
Nog maar een scrubje.
@CiPHER, je moet even in de nieuwe versie ZFSguru het Lighttpd renicen met:
Dan is de webserver tenminste nog snel als er een scrub runt
Ik zie ook geen checksum errors meer, maar mijn SMART waardes zijn nu wel nog steeds bagger (veel multi zone errors en een hoop program count errors)
Nog maar een scrubje.
@CiPHER, je moet even in de nieuwe versie ZFSguru het Lighttpd renicen met:
renice -n 5 [pid]
Dan is de webserver tenminste nog snel als er een scrub runt
[ Voor 28% gewijzigd door FireDrunk op 04-03-2013 18:12 ]
Even niets...
Is je file-corruptie nu ook weg FireDrunk? Dat was denk ik het meest kritische.
En bedankt voor de renice tip. Ik heb er zelf nooit last van gehad overigens. Maar ik draai dan ook zonder virtualisatie op quadcore (oke ook Brazos).
En bedankt voor de renice tip. Ik heb er zelf nooit last van gehad overigens. Maar ik draai dan ook zonder virtualisatie op quadcore (oke ook Brazos).
Als je 10 schijven in RAIDZ2 hebt is een scrub ook wel erg zwaar...:
Is je file-corruptie nu ook weg FireDrunk? Dat was denk ik het meest kritische.
En bedankt voor de renice tip. Ik heb er zelf nooit last van gehad overigens. Maar ik draai dan ook zonder virtualisatie op quadcore (oke ook Brazos).
De file corruptie is niet weg...
Even niets...
Semi-related vraagje:
Ik heb Final Cut Pro X op mijn MacBook Pro staan, en mijn videobestanden op een disk image (sparsebundle) die ik over het netwerk mount. Deze image staat op mijn ZFS RAID-Z2 set van 6 schijven. Ik merk dat Final Cut niet altijd even snel is, en dat zonder dat de CPU of het netwerk van mijn MBP dichtgetrokken word. Zou een ZIL op een leuke SSD hierbij kunnen helpen?
Of, iets meer gerelateerd aan het topic, hoe kan ik zien (op ZFS on Linux danwel Solaris) of een ZIL in mijn workload een verschil oplevert?
Om het leuk te houden, bij mijn weten werken de arcstat e.d. scriptjes helaas niet (out of the box) op ZFS on Linux
Ik heb Final Cut Pro X op mijn MacBook Pro staan, en mijn videobestanden op een disk image (sparsebundle) die ik over het netwerk mount. Deze image staat op mijn ZFS RAID-Z2 set van 6 schijven. Ik merk dat Final Cut niet altijd even snel is, en dat zonder dat de CPU of het netwerk van mijn MBP dichtgetrokken word. Zou een ZIL op een leuke SSD hierbij kunnen helpen?
Of, iets meer gerelateerd aan het topic, hoe kan ik zien (op ZFS on Linux danwel Solaris) of een ZIL in mijn workload een verschil oplevert?
Om het leuk te houden, bij mijn weten werken de arcstat e.d. scriptjes helaas niet (out of the box) op ZFS on Linux
zfs set sync=disabled <filesystem>
Als dat je workload sneller maakt, heb je baat bij een SSD als SLOG (dedicated ZIL).
Maar ik denk eerder aan random reads, dus L2ARC zou nut kunnen hebben. Hoeveel RAM draai je? Jammer dat 32GiB momenteel de praktische limiet is.
Als dat je workload sneller maakt, heb je baat bij een SSD als SLOG (dedicated ZIL).
Maar ik denk eerder aan random reads, dus L2ARC zou nut kunnen hebben. Hoeveel RAM draai je? Jammer dat 32GiB momenteel de praktische limiet is.
Helaas, ik draai op mini ITX dus mijn praktische limiet is 16GB En dat zit er dan ook in...
Verdere specs (voor zover nuttig):
Moederbord: Intel DH77DF
CPU: Intel Xeon E3-1265LV2 (overkill voor enkel ZFS, maar ding is ook bedoeld als virtualisatie server... ooit)
RAM: 2x 8GB DDR3 (Kingston 1333MHz)
HBA: IBM M1015
HDD: 1x Crucial m4 64GB + 6x Hitachi 5K1000
Ik ga eens even spelen met sync=disabled, ik laat nog even weten wat dit oplevert
En dat zit er dan ook in...Verdere specs (voor zover nuttig):
Moederbord: Intel DH77DF
CPU: Intel Xeon E3-1265LV2 (overkill voor enkel ZFS, maar ding is ook bedoeld als virtualisatie server... ooit
)RAM: 2x 8GB DDR3 (Kingston 1333MHz)
HBA: IBM M1015
HDD: 1x Crucial m4 64GB + 6x Hitachi 5K1000
Ik ga eens even spelen met sync=disabled, ik laat nog even weten wat dit oplevert
[ Voor 10% gewijzigd door Xudonax op 04-03-2013 18:42 ]
@CiPHER: Ik geloof dat ik niet de opties heb die jij noemt... Sowieso gaat het bij ZFS on Linux schijnbaar met module parameters, dus bij mijn weten kun je dan heel erg weinig on-the-fly aanpassen
Ik heb de arc_meta_limit ingesteld, en ga zo de machine herstarten om dit toe te passen (kan ook ZFS uit de kernel gooien (rmmod) en weer inladen, maar ik heb wat meer onderhoud te doen). De opties die ik heb die gerelateerd lijken aan de ARC zijn:
Zitten er nog meer dingen in die het tweaken waard zijn?
Owja, en wat ik ben vergeten te zeggen is dat ik nog twee niet al te snelle USB sticks als L2ARC heb, meer voor de grap dan dat het nuttig is. De moeite waard om die eruit te gooien?
zpool status -v tank voor de volledigheid:
Ik heb de arc_meta_limit ingesteld, en ga zo de machine herstarten om dit toe te passen (kan ook ZFS uit de kernel gooien (rmmod) en weer inladen, maar ik heb wat meer onderhoud te doen). De opties die ik heb die gerelateerd lijken aan de ARC zijn:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| parm: zfs_arc_min:Min arc size (ulong) parm: zfs_arc_max:Max arc size (ulong) parm: zfs_arc_meta_limit:Meta limit for arc size (ulong) parm: zfs_arc_meta_prune:Bytes of meta data to prune (int) parm: zfs_arc_grow_retry:Seconds before growing arc size (int) parm: zfs_arc_shrink_shift:log2(fraction of arc to reclaim) (int) parm: zfs_arc_p_min_shift:arc_c shift to calc min/max arc_p (int) parm: l2arc_write_max:Max write bytes per interval (ulong) parm: l2arc_write_boost:Extra write bytes during device warmup (ulong) parm: l2arc_headroom:Number of max device writes to precache (ulong) parm: l2arc_feed_secs:Seconds between L2ARC writing (ulong) parm: l2arc_feed_min_ms:Min feed interval in milliseconds (ulong) parm: l2arc_noprefetch:Skip caching prefetched buffers (int) parm: l2arc_feed_again:Turbo L2ARC warmup (int) parm: l2arc_norw:No reads during writes (int) |
Zitten er nog meer dingen in die het tweaken waard zijn?
Owja, en wat ik ben vergeten te zeggen is dat ik nog twee niet al te snelle USB sticks als L2ARC heb, meer voor de grap dan dat het nuttig is. De moeite waard om die eruit te gooien?
zpool status -v tank voor de volledigheid:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
| pool: tank
state: ONLINE
status: One or more devices has experienced an unrecoverable error. An
attempt was made to correct the error. Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
using 'zpool clear' or replace the device with 'zpool replace'.
see: http://zfsonlinux.org/msg/ZFS-8000-9P
scan: scrub canceled on Mon Mar 4 18:43:07 2013
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
raidz2-0 ONLINE 0 0 0
ata-HGST_HTS541010A9E680_JB100013J4J15B ONLINE 0 0 0
ata-HGST_HTS541010A9E680_JB100013J4HGNB ONLINE 0 0 0
ata-HGST_HTS541010A9E680_JB100013J2RP1A ONLINE 0 0 0
ata-HGST_HTS541010A9E680_JB100013J3TXGB ONLINE 0 0 0
ata-HGST_HTS541010A9E680_JB100013J3ST5B ONLINE 0 0 0
ata-HGST_HTS541010A9E680_JB100013J422JB ONLINE 5 0 0
cache
usb-SanDisk_Cruzer_Fit_4C532000041129106180-0:0 ONLINE 0 0 0
usb-SanDisk_Cruzer_Fit_4C532000050913100011-0:0 ONLINE 0 0 0
errors: No known data errors |
Ik heb wel een /proc/spl/kstat/zfs/arcstats, maar ik zou eerlijk gezegd niet weten wat ik met de inhoud daarvan moet...
De inhoud daarvan is op een schone boot:
Ik ga even twee schijven als mirror toevoegen (aan een nieuwe ZFS pool) en dan zal ik Final Cut Pro nog eens een slinger geven
De inhoud daarvan is op een schone boot:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
| $ cat /proc/spl/kstat/zfs/arcstats 4 1 0x01 77 3696 12687278980 115101194991 name type data hits 4 94640 misses 4 11158 demand_data_hits 4 9816 demand_data_misses 4 175 demand_metadata_hits 4 76322 demand_metadata_misses 4 6791 prefetch_data_hits 4 64 prefetch_data_misses 4 2020 prefetch_metadata_hits 4 8438 prefetch_metadata_misses 4 2172 mru_hits 4 59680 mru_ghost_hits 4 55 mfu_hits 4 26557 mfu_ghost_hits 4 32 deleted 4 8 recycle_miss 4 0 mutex_miss 4 0 evict_skip 4 0 evict_l2_cached 4 0 evict_l2_eligible 4 0 evict_l2_ineligible 4 2048 hash_elements 4 11045 hash_elements_max 4 11045 hash_collisions 4 142 hash_chains 4 140 hash_chain_max 4 2 p 4 4425886208 c 4 8853127168 c_min 4 1890870784 c_max 4 8853127168 size 4 371179744 hdr_size 4 4264416 data_size 4 309645312 other_size 4 57270016 anon_size 4 16384 anon_evict_data 4 0 anon_evict_metadata 4 0 mru_size 4 281745408 mru_evict_data 4 220317184 mru_evict_metadata 4 18842112 mru_ghost_size 4 311296 mru_ghost_evict_data 4 122880 mru_ghost_evict_metadata 4 188416 mfu_size 4 27883520 mfu_evict_data 4 25174528 mfu_evict_metadata 4 656896 mfu_ghost_size 4 94208 mfu_ghost_evict_data 4 8192 mfu_ghost_evict_metadata 4 86016 l2_hits 4 0 l2_misses 4 11141 l2_feeds 4 101 l2_rw_clash 4 0 l2_read_bytes 4 0 l2_write_bytes 4 59421184 l2_writes_sent 4 69 l2_writes_done 4 69 l2_writes_error 4 0 l2_writes_hdr_miss 4 0 l2_evict_lock_retry 4 0 l2_evict_reading 4 0 l2_free_on_write 4 0 l2_abort_lowmem 4 0 l2_cksum_bad 4 0 l2_io_error 4 0 l2_size 4 59357696 l2_hdr_size 4 0 memory_throttle_count 4 0 memory_direct_count 4 0 memory_indirect_count 4 0 arc_no_grow 4 0 arc_tempreserve 4 0 arc_loaned_bytes 4 0 arc_prune 4 0 arc_meta_used 4 125688032 arc_meta_limit 4 3781741568 arc_meta_max 4 124095400 |
Ik ga even twee schijven als mirror toevoegen (aan een nieuwe ZFS pool) en dan zal ik Final Cut Pro nog eens een slinger geven
Dat vond ik dus ook... En als jij zegt dat een scrub de files fixt, waarom bied ZFSguru dan aan om eerst de files te deleten, en dan pas een scrub te starten?
Als wat jij zegt waar is, heb ik voor jan-met-de-korte-achternaam op ZFSguru vertrouwt omdat de webinterface zei, deleten die hap...
Enige 2 dingen die in KVM niet vlekkeloos gingen waren tijd en netwerk. De rest was 100% in orde...
Als ZFS/FreeBSD daar gevoelig voor is, is dat wel het noteren waard. En bovendien vind ik dat nogal slecht... (maar dat is mijn mening...)
EDIT:
nieuws: Linux-kernel 3.9 biedt raid-modi voor btrfs en ssd-cachingmodus
oh boy, concurrentie voor ZFS
EDIT2:
WEL GODVER******
op mijn rootpool doe ik een scrub, et voila... alle corruptie weg....
CiPHER, je wordt bedankt door jouw advies ben ik >100 files kwijt
Als wat jij zegt waar is, heb ik voor jan-met-de-korte-achternaam op ZFSguru vertrouwt omdat de webinterface zei, deleten die hap...
Enige 2 dingen die in KVM niet vlekkeloos gingen waren tijd en netwerk. De rest was 100% in orde...
Als ZFS/FreeBSD daar gevoelig voor is, is dat wel het noteren waard. En bovendien vind ik dat nogal slecht... (maar dat is mijn mening...)
EDIT:
nieuws: Linux-kernel 3.9 biedt raid-modi voor btrfs en ssd-cachingmodus
oh boy, concurrentie voor ZFS
EDIT2:
WEL GODVER******
op mijn rootpool doe ik een scrub, et voila... alle corruptie weg....
CiPHER, je wordt bedankt
door jouw advies ben ik >100 files kwijt
[ Voor 55% gewijzigd door FireDrunk op 04-03-2013 20:17 ]
Even niets...
Innovatie. Mooi toch?:
Dat vond ik dus ook... En als jij zegt dat een scrub de files fixt, waarom bied ZFSguru dan aan om eerst de files te deleten, en dan pas een scrub te starten?
nieuws: Linux-kernel 3.9 biedt raid-modi voor btrfs en ssd-cachingmodus
oh boy, concurrentie voor ZFS
Gewoon een heel grote verzameling snoertjes
Ehm, het verbaast me eigenlijk dat je dit niet had geweten FireDrunk?! Ik ken die melding in ZFSguru niet zo goed, maar volgens mij wordt daar uitgelegd dat de files verwijderd worden. ZFSguru doet dan een rm op die files. Dat doe je alleen als je denkt dat het een verloren zaak is en ervanuit gaat dat je de corruptie niet kunt oplossen.
In jouw geval is iets heel anders aan de hand. Geen disk corruptie en waarschijnlijk ook geen RAM-corruptie, maar alle disks blokkeerden gewoon vanuit het perspectief van ZFS dus allemaal een bad sector op die plek, door een situatie die zich voordoet omdat je KVM virtualisatie gebruikt. Ook de meldingen dat de tijd terug in het verleden is gegaan (calcru: runtime went backwards) lijkt mij niet erg fris voor je guest VM - al weet ik niet hoe erg zoiets is.
Doordat alle data sources vanuit het perspectief van ZFS niet beschikbaar waren, zou ZFS die file als corrupt aanmerken. Dat lijkt mij het meest aannemelijke scenario. Merk hierbij op dat de disks niet detachen en onzichtbaar worden. Wat je zegt over dat FreeBSD slecht tegen timeouts kan verbaast mij dan ook. Juist FreeBSD heeft met progressive soft-timeouts (ada driver) een streepje voor op andere operating systems die een statische timeout gebruiken met retry. Dat is wat FreeBSD gebruikte in de 4.x series.
Maar in elk geval, ik dacht dat je net als ik dacht dat jouw corruptie simpelweg is op te lossen met een scrub. Dan verbaast mij jouw reactie:
Wat jij hebt gedaan (althans dat impliceert je bericht?!) is via ZFSguru de bestanden permanent verwijderen door die grote rode knop te gebruiken - al kan ik me alleen vaag herinneren hoe het eruit zag. Maar in elk geval, dat is niet wat ik je heb aangeraden, toch?
In je zpool status output zie ik 987 data errors. Dus dat suggereert dat je destijds nog niet de bestanden had verwijderd. Ik ging er dus ook gewoon vanuit dat jij ook bezig was met het recoveren van die corrupted files, en het niet als een verloren zaak zag.
Het spijt me heel erg als ik voor dataverlies heb gezorgd, maar tot dusver begrijp ik niet hoe het mis heeft kunnen gaan.
In jouw geval is iets heel anders aan de hand. Geen disk corruptie en waarschijnlijk ook geen RAM-corruptie, maar alle disks blokkeerden gewoon vanuit het perspectief van ZFS dus allemaal een bad sector op die plek, door een situatie die zich voordoet omdat je KVM virtualisatie gebruikt. Ook de meldingen dat de tijd terug in het verleden is gegaan (calcru: runtime went backwards) lijkt mij niet erg fris voor je guest VM - al weet ik niet hoe erg zoiets is.
Doordat alle data sources vanuit het perspectief van ZFS niet beschikbaar waren, zou ZFS die file als corrupt aanmerken. Dat lijkt mij het meest aannemelijke scenario. Merk hierbij op dat de disks niet detachen en onzichtbaar worden. Wat je zegt over dat FreeBSD slecht tegen timeouts kan verbaast mij dan ook. Juist FreeBSD heeft met progressive soft-timeouts (ada driver) een streepje voor op andere operating systems die een statische timeout gebruiken met retry. Dat is wat FreeBSD gebruikte in de 4.x series.
Maar in elk geval, ik dacht dat je net als ik dacht dat jouw corruptie simpelweg is op te lossen met een scrub. Dan verbaast mij jouw reactie:
Ik heb je juist aangeraden om niet vanuit te gaan dat die corruptie permanent is, maar dat het simpelweg op te lossen is als ZFS opnieuw die bestanden aanraakt. Dus of één voor één die corrupted files lezen met cat of dd of wat dan ook, ofwel een scrub starten.CiPHER, je wordt bedankt
Wat jij hebt gedaan (althans dat impliceert je bericht?!) is via ZFSguru de bestanden permanent verwijderen door die grote rode knop te gebruiken - al kan ik me alleen vaag herinneren hoe het eruit zag. Maar in elk geval, dat is niet wat ik je heb aangeraden, toch?
In je zpool status output zie ik 987 data errors. Dus dat suggereert dat je destijds nog niet de bestanden had verwijderd. Ik ging er dus ook gewoon vanuit dat jij ook bezig was met het recoveren van die corrupted files, en het niet als een verloren zaak zag.
Het spijt me heel erg als ik voor dataverlies heb gezorgd, maar tot dusver begrijp ik niet hoe het mis heeft kunnen gaan.
Je hebt ook nog files in /sys/module/zfs/parameters/. Sommigen lijken daarvan te kloppen, maar anderen zoals zfs_arc_* zijn allemaal 0 
@CiPHER, het was ook geen aanval hoor, vandaar de
Ik heb op jou aanraden ZFSguru gebruikt, daarom impliceerde ik dat het door jou kwam. Het blijft inderdaad mijn eigen keuze om op die knop te drukken.
Wat ik dus ABSOLUUT NIET BEGRIJP is dat ZFS kan beweren dat files ECHT HELEMAAL STOEK ZIJN als een simpele scrub alles weer oplost... Dat is mij een raadsel...
Jouw post over het doen van een scrub, kwam NA mijn eerste delete actie Jouw treft geen blaam hoor
Wat ZFSguru dus met die knop doet is dus absoluut *verkeerd*, het doet EERST een rm, dan een scrub starten.
Terwijl het eigenlijk zou moeten controleren of er recentelijk al een scrub gedaan is, en als die echt helemaal klaar is, DAN pas als last resort (of eigenlijk een clean up) de files verwijderen.
De volgorde is dus fout, met (lichtelijk extreme) gevolgen.
Ik heb op jou aanraden ZFSguru gebruikt, daarom impliceerde ik dat het door jou kwam. Het blijft inderdaad mijn eigen keuze om op die knop te drukken.
Wat ik dus ABSOLUUT NIET BEGRIJP is dat ZFS kan beweren dat files ECHT HELEMAAL STOEK ZIJN als een simpele scrub alles weer oplost... Dat is mij een raadsel...
Jouw post over het doen van een scrub, kwam NA mijn eerste delete actie
Jouw treft geen blaam hoor Wat ZFSguru dus met die knop doet is dus absoluut *verkeerd*, het doet EERST een rm, dan een scrub starten.
Terwijl het eigenlijk zou moeten controleren of er recentelijk al een scrub gedaan is, en als die echt helemaal klaar is, DAN pas als last resort (of eigenlijk een clean up) de files verwijderen.
De volgorde is dus fout, met (lichtelijk extreme) gevolgen.
[ Voor 28% gewijzigd door FireDrunk op 04-03-2013 21:51 ]
Even niets...
FireDrunk grapt maar wat, hij heeft namelijk een recente backup en is de files dus niet kwijt.... 
- raid does not fix stupid -
Het kan zijn dat er in dit opzicht wat aan ZFSguru valt te verbeteren. Maar alvorens daar op in te gaan wil ik wel opmerken dat het soort corruptie wat jij kreeg wel heel bijzonder en afwijkend en ongewoon is. Het is veroorzaakt door een interactie tussen je KVM virtualisatie en de ZFSguru guest VM. Althans zo verklaar je zelf en dat biedt een goede verklaring voor hetgeen je meemaakt.
Normaal wordt disk corruptie natuurlijk direct gefixed door van een redundante bron de data te lezen. In jouw geval waren alle disks echter onbeschikbaar door een virtualisatie-issue. Niet echt de schuld van ZFS of FreeBSD denk ik dan als leek op dit gebied. Dat is goed nieuws voor de kans op recovery: want de files waren helemaal niet corrupt. Simpelweg opnieuw ZFS kennis laten maken met de fysieke data op een moment dat KVM zich wel netjes gedraagt zou dan de oplossing bieden.
Dan komen we op ZFSguru. Ik vraag me dan wel af hoe je die melding die je krijgt bij filecorruptie hebt geïnterpreteerd. Want ZFSguru biedt geen kans op recovery. Het is eigenlijk een 'forfeit my data; just clean all the errors'. Ik weet ook niet of die actie een scrub start. Het enige wat ik weet is dat het een combinatie is van rm <corrupte bestanden> en zpool clear. Misschien nog een scrub erachteraan automatisch wat handig kan zijn.
In jouw geval waar er dus kans op recovery was, wil je helemaal niet verwijderen. Ik weet niet hoe je dan op die knop kunt drukken; oen! Nee serieus, ik ken de melding niet en het kan zijn dat hij veel beter verwoord moet worden.
Maar eigenlijk zouden er twee knoppen moeten komen:
1. Try to recover the corrupted files (doe een dd op de corrupte bestanden in background)
2. Forfeit my data and remove all corruption (wat jij hebt gedaan dus)
Normaal wordt disk corruptie natuurlijk direct gefixed door van een redundante bron de data te lezen. In jouw geval waren alle disks echter onbeschikbaar door een virtualisatie-issue. Niet echt de schuld van ZFS of FreeBSD denk ik dan als leek op dit gebied. Dat is goed nieuws voor de kans op recovery: want de files waren helemaal niet corrupt. Simpelweg opnieuw ZFS kennis laten maken met de fysieke data op een moment dat KVM zich wel netjes gedraagt zou dan de oplossing bieden.
Dan komen we op ZFSguru. Ik vraag me dan wel af hoe je die melding die je krijgt bij filecorruptie hebt geïnterpreteerd. Want ZFSguru biedt geen kans op recovery. Het is eigenlijk een 'forfeit my data; just clean all the errors'. Ik weet ook niet of die actie een scrub start. Het enige wat ik weet is dat het een combinatie is van rm <corrupte bestanden> en zpool clear. Misschien nog een scrub erachteraan automatisch wat handig kan zijn.
In jouw geval waar er dus kans op recovery was, wil je helemaal niet verwijderen. Ik weet niet hoe je dan op die knop kunt drukken; oen!
Nee serieus, ik ken de melding niet en het kan zijn dat hij veel beter verwoord moet worden.Maar eigenlijk zouden er twee knoppen moeten komen:
1. Try to recover the corrupted files (doe een dd op de corrupte bestanden in background)
2. Forfeit my data and remove all corruption (wat jij hebt gedaan dus)
zfs set sync=disabled heeft het geheel niet sneller gemaakt, het lijkt eerder langzamer te zijn geworden... Ik heb ondertussen wel een betere oplossing gevonden, ik heb een ZFS pool toegevoegd bestaande uit twee antieke (2008) Hitachi 7K1000.B 3.5" schijven en hier een 954GiB iSCSI LUN op aangemaakt.
Dit is in ieder geval een minder hacky oplossing (IMO) dan een gedeelde disk image, en het is hopelijk ook nog iets sneller aangezien ik geen 2-3 lagen op elkaar stapel (AFP voor toegang tot disk image, disk image mounten en daar vervolgens HFS+ overheen doen). Nu nog kijken of dit ook daadwerkelijk een snelheidswinst oplevert
Dit is in ieder geval een minder hacky oplossing (IMO) dan een gedeelde disk image, en het is hopelijk ook nog iets sneller aangezien ik geen 2-3 lagen op elkaar stapel (AFP voor toegang tot disk image, disk image mounten en daar vervolgens HFS+ overheen doen). Nu nog kijken of dit ook daadwerkelijk een snelheidswinst oplevert
Ik "test" het niet op een meetbare wijze, helaas. Ik merk het aan de reactiesnelheid in Final Cut als ik door de video heen blader (ProRes 4:2:2 Full HD). Ik heb wel even wat testjes gedaan (achteraf) met Blackmagic Disk Speed Test, de resultaten:
sync=disabled, sparseimage: ~90MByte/s schrijven, ~85MByte/s lezen
sync=standard, sparseimage: ~80MByte/s schrijven, ~90MByte/s lezen
sync=disabled, iSCSI: ~110MByte/s schrijven, ~110MByte/s lezen
sync=enabled, iSCSI: ~110MByte/s schrijven, ~110MByte/s lezen
iSCSI is dus in sequentiele access een behoorlijk stuk sneller, hoewel de andere me niet heel erg tegenvallen om eerlijk te zijn Ik heb helaas niet zo 1-2-3 een tooltje dat de random access kan testen. Of in ieder geval, niet iets dat gratis is en op OS X draait
Mijn arcstats na dit geintje:
Daarnaast heb ik ook nog wat ZIL statistieken gevonden, maar ook hiervan heb ik niet echt een idee hoe ik dit moet interpreteren...
@CiPHER: arc_meta_max heb ik in de module opties gelijkgesteld aan de arc_meta_limit, maar ik moet de module nog even herladen. Is dit een slecht idee of moet dat gewoon kunnen?
sync=disabled, sparseimage: ~90MByte/s schrijven, ~85MByte/s lezen
sync=standard, sparseimage: ~80MByte/s schrijven, ~90MByte/s lezen
sync=disabled, iSCSI: ~110MByte/s schrijven, ~110MByte/s lezen
sync=enabled, iSCSI: ~110MByte/s schrijven, ~110MByte/s lezen
iSCSI is dus in sequentiele access een behoorlijk stuk sneller, hoewel de andere me niet heel erg tegenvallen om eerlijk te zijn
Ik heb helaas niet zo 1-2-3 een tooltje dat de random access kan testen. Of in ieder geval, niet iets dat gratis is en op OS X draait Mijn arcstats na dit geintje:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
| 4 1 0x01 77 3696 12687278980 10333668308680 name type data hits 4 27821744 misses 4 872100 demand_data_hits 4 26115007 demand_data_misses 4 33184 demand_metadata_hits 4 1420288 demand_metadata_misses 4 16796 prefetch_data_hits 4 101838 prefetch_data_misses 4 728634 prefetch_metadata_hits 4 184611 prefetch_metadata_misses 4 93486 mru_hits 4 4416769 mru_ghost_hits 4 46099 mfu_hits 4 23202670 mfu_ghost_hits 4 2665 deleted 4 10595029 recycle_miss 4 324072 mutex_miss 4 790727 evict_skip 4 124039844 evict_l2_cached 4 16493201920 evict_l2_eligible 4 172866161664 evict_l2_ineligible 4 16271844864 hash_elements 4 587811 hash_elements_max 4 937833 hash_collisions 4 9492065 hash_chains 4 162375 hash_chain_max 4 11 p 4 5664799 c 4 8102109184 c_min 4 1890870784 c_max 4 8853127168 size 4 8042711392 hdr_size 4 210911792 data_size 4 7693982720 other_size 4 115281952 anon_size 4 120238080 anon_evict_data 4 0 anon_evict_metadata 4 0 mru_size 4 1757336576 mru_evict_data 4 1666678272 mru_evict_metadata 4 59819520 mru_ghost_size 4 6372912640 mru_ghost_evict_data 4 4844281856 mru_ghost_evict_metadata 4 1528630784 mfu_size 4 5816408064 mfu_evict_data 4 4985358848 mfu_evict_metadata 4 793456128 mfu_ghost_size 4 15680512 mfu_ghost_evict_data 4 3673088 mfu_ghost_evict_metadata 4 12007424 l2_hits 4 4042 l2_misses 4 868041 l2_feeds 4 10465 l2_rw_clash 4 3 l2_read_bytes 4 371309568 l2_write_bytes 4 12510755840 l2_writes_sent 4 6147 l2_writes_done 4 6147 l2_writes_error 4 0 l2_writes_hdr_miss 4 4 l2_evict_lock_retry 4 0 l2_evict_reading 4 0 l2_free_on_write 4 37371 l2_abort_lowmem 4 71 l2_cksum_bad 4 0 l2_io_error 4 0 l2_size 4 11887421440 l2_hdr_size 4 23860512 memory_throttle_count 4 0 memory_direct_count 4 321 memory_indirect_count 4 348448 arc_no_grow 4 0 arc_tempreserve 4 0 arc_loaned_bytes 4 0 arc_prune 4 0 arc_meta_used 4 1271882080 arc_meta_limit 4 3781741568 arc_meta_max 4 1417657624 |
Daarnaast heb ik ook nog wat ZIL statistieken gevonden, maar ook hiervan heb ik niet echt een idee hoe ik dit moet interpreteren...
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| 5 1 0x01 13 624 12687445867 10382778847991 name type data zil_commit_count 4 7096 zil_commit_writer_count 4 7096 zil_itx_count 4 562283 zil_itx_indirect_count 4 902 zil_itx_indirect_bytes 4 117320256 zil_itx_copied_count 4 0 zil_itx_copied_bytes 4 0 zil_itx_needcopy_count 4 554890 zil_itx_needcopy_bytes 4 21398069383 zil_itx_metaslab_normal_count 4 0 zil_itx_metaslab_normal_bytes 4 0 zil_itx_metaslab_slog_count 4 203643 zil_itx_metaslab_slog_bytes 4 21543191032 |
@CiPHER: arc_meta_max heb ik in de module opties gelijkgesteld aan de arc_meta_limit, maar ik moet de module nog even herladen. Is dit een slecht idee of moet dat gewoon kunnen?
En die eerste test is met Samba? Zijn heel redelijke snelheden hoor, ik ben bang dat je het niet veel sneller gaat krijgen.:
Ik "test" het niet op een meetbare wijze, helaas. Ik merk het aan de reactiesnelheid in Final Cut als ik door de video heen blader (ProRes 4:2:2 Full HD). Ik heb wel even wat testjes gedaan (achteraf) met Blackmagic Disk Speed Test, de resultaten:
sync=disabled, sparseimage: ~90MByte/s schrijven, ~85MByte/s lezen
sync=standard, sparseimage: ~80MByte/s schrijven, ~90MByte/s lezen
sync=disabled, iSCSI: ~110MByte/s schrijven, ~110MByte/s lezen
sync=enabled, iSCSI: ~110MByte/s schrijven, ~110MByte/s lezen
iSCSI is dus in sequentiele access een behoorlijk stuk sneller, hoewel de andere me niet heel erg tegenvallen om eerlijk te zijn
* Compizfox hoopt eigenlijk op een nieuw, snel open-source file protocol wat zowel onder FreeBSD, Linux als Windows goed wordt ondersteund...
Je hebt natuurlijk SMB (CIFS heet het eigenlijk nu), maar Samba is niet zo'n hele goede implementatie daarvan voor FreeBSD/Linux (reverse-engineered, tja)
Je hebt ook NFS, wat open-source is, maar waar er voor Windows geen snelle implementatie is. (Er is wel een NFS client voor Windows, maar dat is langzamer dan CIFS, helaas)
Gewoon een heel grote verzameling snoertjes
Nee, ik doe niet aan Samba/NFS Ik heb netatalk lopen voor AFP zodat ik niet aan twee kanten met een brakke Samba/CIFS implementatie zit. Het valt me vooral héél erg mee dat ik met iSCSI praktisch aan de limiet van mijn netwerk zit. En helaas kun je een MacBook zo lastig upgraden naar 10GbE (om het nog maar niet over de overige kosten te hebben @_@ Server upgrade, switch upgraden, nieuwe kabels...)
EDIT: Also, als je echt een snel protocol wilt, al eens naar FTP gekeken? Veel sneller dan dat ga je het niet krijgen. Maar ja, het is wél vrij oud...
En, het valt me op dat een scrub op een niet in gebruik zijnde mirror echt ontzettend traag is... Ik doe hier nu nog geen 30MByte/s op mijn 1TB mirror. Mijn stapel laptop schijfjes vinden een scrub wel aardig en doen dan ook vrolijk 215+MByte/s. Of zou iSCSI de mirror héél stiekem toch bezig houden?
Ik heb netatalk lopen voor AFP zodat ik niet aan twee kanten met een brakke Samba/CIFS implementatie zit. Het valt me vooral héél erg mee dat ik met iSCSI praktisch aan de limiet van mijn netwerk zit. En helaas kun je een MacBook zo lastig upgraden naar 10GbE (om het nog maar niet over de overige kosten te hebben @_@ Server upgrade, switch upgraden, nieuwe kabels...)EDIT: Also, als je echt een snel protocol wilt, al eens naar FTP gekeken? Veel sneller dan dat ga je het niet krijgen. Maar ja, het is wél vrij oud...
En, het valt me op dat een scrub op een niet in gebruik zijnde mirror echt ontzettend traag is... Ik doe hier nu nog geen 30MByte/s op mijn 1TB mirror. Mijn stapel laptop schijfjes vinden een scrub wel aardig en doen dan ook vrolijk 215+MByte/s. Of zou iSCSI de mirror héél stiekem toch bezig houden?
[ Voor 35% gewijzigd door Xudonax op 04-03-2013 23:06 ]
@FireDrunk Die getallen zijn van ongeveer 50% "in" de scrub
Maargoed, zolang de scrub maar succesvol afgerond word
Maargoed, zolang de scrub maar succesvol afgerond word
:strip_icc():strip_exif()/u/159609/caffeine_is_the_shit_60x60.shkl.jpg?f=community)
And I begged Angel of the Lord what are these tortured screams? And the angel said unto me; These are the cries of the carrots, the cries of the carrots! You see, Reverend Maynard, Tomorrow is harvest day and to them it is the holocaust
Dat is al iets in ieder geval
Was even bang dat er iets anders naar /dev/null ging
And I begged Angel of the Lord what are these tortured screams? And the angel said unto me; These are the cries of the carrots, the cries of the carrots! You see, Reverend Maynard, Tomorrow is harvest day and to them it is the holocaust
Heeft iemand dit wel eens gehad in ZFSGuru, voor mij de eerste keer:
Via SSH heb ik wel normale waardes:
Foutmeldingen wijzen op een volle / corrupte swap file. Ik kan dan niet meer via de console, ssh of webinterface inloggen. Shares via SMB / iSCSI zijn wel gewoon benaderbaar.
Als ik reboot is er ca. 1 maand geen probleem.
Hardwarematig is er geen probleem, geen SMART, geen geheugen problemen, etc.
Qua swap lees je op internet dat het wordt afgeraden om dat op een ZFS volume te zetten, maar met verder speuren ligt dat aan de implementatie. De implementatie zoals ZFSGuru dat doet, is goed. De ZFSGuru installatie staat op een SDD (swap dus ook). Deel van die SDD wordt ook als L2ARC gebruikt.
Via SSH heb ik wel normale waardes:
Ik heb sowieso af en toe problemen met de huidige installatie, 9.1-003 op een Dell PE2950.
Foutmeldingen wijzen op een volle / corrupte swap file. Ik kan dan niet meer via de console, ssh of webinterface inloggen. Shares via SMB / iSCSI zijn wel gewoon benaderbaar.
Als ik reboot is er ca. 1 maand geen probleem.
Hardwarematig is er geen probleem, geen SMART, geen geheugen problemen, etc.
Qua swap lees je op internet dat het wordt afgeraden om dat op een ZFS volume te zetten, maar met verder speuren ligt dat aan de implementatie. De implementatie zoals ZFSGuru dat doet, is goed. De ZFSGuru installatie staat op een SDD (swap dus ook). Deel van die SDD wordt ook als L2ARC gebruikt.
[ Voor 17% gewijzigd door wjn op 05-03-2013 09:53 ]
/u/170728/owl.png?f=community)
/u/24671/crop55d1ea05b175b.png?f=community)
Na een jaar zonder noemenswaardige problemen, heb ik nu opeens twee keer in een paar dagen last van een time-out(?) probleem:
Volgens dmesg:
Het betreft overigens beide keren dezelfde disk (waarvan het lampje op de HDD-tray blijft branden alsof hij 'in-use' is).
Iemand enig idee wat hier aan de hand kan zijn en of ik me zorgen moet maken?
Hmm, terwijl ik dit zit te typen is het probleem spontaan opgelost en loopt mijn kopieer-actie weer verder zie ik. Misschien een disk die een bad-sector is tegengekomen, of praat ik nu onzin?
Volgens dmesg:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| ahcich5: is 00000000 cs 000003fe ss 000003ff rs 000003ff tfd 40 serr 00000000 cmd 0004c017 ahcich5: Timeout on slot 18 port 0 ahcich5: is 00000000 cs 0ff80000 ss 0ffc0000 rs 0ffc0000 tfd 40 serr 00000000 cmd 0004d217 ahcich5: Timeout on slot 4 port 0 ahcich5: is 00000000 cs 00003fc0 ss 00003ff0 rs 00003ff0 tfd 40 serr 00000000 cmd 0004c517 ahcich5: Timeout on slot 22 port 0 ahcich5: is 00000000 cs fe000000 ss ffc00000 rs ffc00000 tfd 40 serr 00000000 cmd 0004d817 ahcich5: Timeout on slot 8 port 0 ahcich5: is 00000000 cs 0003fe00 ss 0003ff00 rs 0003ff00 tfd 40 serr 00000000 cmd 0004c817 ahcich5: Timeout on slot 26 port 0 ahcich5: is 00000000 cs f800000f ss fc00000f rs fc00000f tfd 40 serr 00000000 cmd 0004da17 ahcich5: Timeout on slot 12 port 0 ahcich5: is 00000000 cs 003fe000 ss 003ff000 rs 003ff000 tfd 40 serr 00000000 cmd 0004cc17 ahcich5: Timeout on slot 30 port 0 ahcich5: is 00000000 cs 800000ff ss c00000ff rs c00000ff tfd 40 serr 00000000 cmd 0004de17 |
Het betreft overigens beide keren dezelfde disk (waarvan het lampje op de HDD-tray blijft branden alsof hij 'in-use' is).
Iemand enig idee wat hier aan de hand kan zijn en of ik me zorgen moet maken?
Hmm, terwijl ik dit zit te typen is het probleem spontaan opgelost en loopt mijn kopieer-actie weer verder zie ik. Misschien een disk die een bad-sector is tegengekomen, of praat ik nu onzin?
Daar heb ik aan gedacht, maar dan snapshot je een 'disk' van een draaiende machine. De meeste operating systems vinden dat niet zo fijn . Als je dan je snapshot terug zet is er alsnog allerlei corruptie omdat je midden in transacties van open files zat. (ZFS weet dat immeers niet zodra je een snapshot maakt). Je zou dan dus de virtuale machine eerst moeten afsluiten, snapshotten (met ZFS) en dan weer opstarten. Dat is niet ideaal.
. Als je dan je snapshot terug zet is er alsnog allerlei corruptie omdat je midden in transacties van open files zat. (ZFS weet dat immeers niet zodra je een snapshot maakt). Je zou dan dus de virtuale machine eerst moeten afsluiten, snapshotten (met ZFS) en dan weer opstarten. Dat is niet ideaal.
/u/342733/wtd_s.png?f=community)
:strip_icc():strip_exif()/u/121740/avatar.jpg?f=community){kind=avatar}
Interessant.
Heb je dan je storage fysiek? Dus los van je ESX Host?
Ik zit enorm te twijfelen of ik 2 losse machines ga bouwen, of 1 ESX Host, en daar FreeNAS in een VM draaien. Als het goed is, is de VMXNET3 NIC werkend te krijgen in FreeNAS, en dan heb je 10Gbit naar je vSwitch. Ik weet alleen niet of de host zelf ook een 'uplink naar de vswitch' kan krijgen van 10Gbit. Weten jullie dit?
Dit lijkt me stukken beter te performen dan een losse machine? Waar je toch wel gelimiteerd bent aan 1Gb, of een veelvoud hiervan dmv etherchannels (of, trunking, in geval van mijn HP switch
).Is de limiteerde factor je netwerk, of eerder de IOPS? (met zeg, 5* 4TB disks).
/u/116403/crop64cfe7aeafeb6_cropped.png?f=community)
HyperBart heeft all-in-one:
[...]
Interessant.
Heb je dan je storage fysiek? Dus los van je ESX Host?
Ik zit enorm te twijfelen of ik 2 losse machines ga bouwen, of 1 ESX Host, en daar FreeNAS in een VM draaien. Als het goed is, is de VMXNET3 NIC werkend te krijgen in FreeNAS, en dan heb je 10Gbit naar je vSwitch. Ik weet alleen niet of de host zelf ook een 'uplink naar de vswitch' kan krijgen van 10Gbit. Weten jullie dit?
Dit lijkt me stukken beter te performen dan een losse machine? Waar je toch wel gelimiteerd bent aan 1Gb, of een veelvoud hiervan dmv etherchannels (of, trunking, in geval van mijn HP switch
Is de limiteerde factor je netwerk, of eerder de IOPS? (met zeg, 5* 4TB disks).
VMXNET3 werkend krijgen onder FreeBSD is vrij simpel. Hoe dit onder FreeNAS moet weet ik niet, maar de nieuwste versie van VMware tools werkt gewoon out-of-the-box op FreeBSD.
Je 'host' is niks onder ESXi? Waarom zou dat ding zelf 10Gb moeten hebben? Een vSwitch is niets meer dan en stukje software waarop hij VM's knoopt.
Als je bedoelt dat je > 1Gb wil halen naar buiten door middel van trunken van poorten dan kan dat inderdaad. MAAR niet met 1-op-1 verbindingen. ESXi ondersteund LACP, maar inherent aan die technologie kan je alleen 1Gb 1-op-1 verbindingen maken en nooit > 1Gb verstoken tussen 1 client en 1 VM.
Wel kan je dus door meerdere verbindingen op te zetten over meerdere IP adressen (zoals met iSCSI kan) een soort concurrency creeeren waardoor je wel over meerdere netwerkaarten gaat.
De iSCSI implementatie in Windows 8 ondersteund wel multipathing.
Even niets...
Gister mijn Areca 1300ix binnen gekregen en in mijn server gehangen. Driver is geinjecteerd en het ding werkt Heb mijn rootpool (2*80GB Intel 320 SSD's) er aan gehangen en geboot.
Daarna een scrub gestart op de rootpool, en ook dat ging allemaal vlekkeloos.
Ook even een 10GB file aangemaakt met DD en weer verwijderd.
Iemand nog meer tests die ik moet doen om zeker te weten dat de controller compatible is met ZFS?
Heb mijn rootpool (2*80GB Intel 320 SSD's) er aan gehangen en geboot.Daarna een scrub gestart op de rootpool, en ook dat ging allemaal vlekkeloos.
Ook even een 10GB file aangemaakt met DD en weer verwijderd.
Iemand nog meer tests die ik moet doen om zeker te weten dat de controller compatible is met ZFS?
Even niets...