:fill(white):strip_exif()/i/2003943496.jpeg?f=thumbmini)
:strip_exif()/i/1321263566.png?f=thumbmini)
Denk dat je met zdb in de weer moet als je het wilt proberen, hoeveel tijd wil je er nog aan besteden om te kijken of je je pool kan terugvinden?Compizfox schreef op zondag 15 september 2013 @ 17:08:
[...]
EDIT: No joy. Ben bang dat ik m'n pool gewoon kwijt ben. Of is er nog een mogelijkheid? Valt me eigenlijk wel een klein beetje van ZFS tegen dat dit niet te recoveren is, wetende dat alle data gewoon nog aanwezig is.
Ik stel het op prijs als iemand kan bevestigen dat mijn pool écht onherstelbaar weg is, dan kan ik namelijk zonder te twijfelen verder en maak ik nieuwe pools aan.
:strip_icc():strip_exif()/u/286431/crop680f6b95743ca_cropped.jpg?f=community)
Tja, de gebruiker is voor een systeem vaak het grootste risiko.
Volgende keer wat meer tijd nemen
Ik weet niet of je ze hebt, maar wellicht kan je wat snapshots opruimen.
wat is het pad van je share?
doe eens een 'zfs list' en 'df -h'
Iemand nog tips om de Samba-performance te verbeteren?
Als ik lees vanaf de share krijg ik eigenlijk altijd een stabiele 40 MB/s. Als ik schrijf naar de share begint ie op 240 MB/s (wut?), blijft dan een aantal seconden op 115 MB/s hangen (close enough), maar blijft na een tijdje altijd op zo'n 60-70 MB/s steken.
Dat moet beter kunnen, toch? M'n pool zou het makkelijk aan moeten kunnen (heb 283 MB/s read, 220 MB/s write volgens ZFSGuru benchmark) en met iperf haal ik de volle 1 Gb/s (==125 MB/s).
Hoe kom ik erachter waar de bottleneck zit?
Als ik lees vanaf de share gebruikte smbd gemiddeld zo'n 10% CPU en zit ie de hele tijd op de state select. Tijdens het schrijven naar de share verbruikt smbd iets meer (~20% CPU) en wisselt hij voornamelijk tussen de states RUN en sbwait. Mocht dat nuttige info zijn
Qua performance tweaks heb ik dit in m'n smb.conf staan:
Als ik lees vanaf de share krijg ik eigenlijk altijd een stabiele 40 MB/s. Als ik schrijf naar de share begint ie op 240 MB/s (wut?), blijft dan een aantal seconden op 115 MB/s hangen (close enough), maar blijft na een tijdje altijd op zo'n 60-70 MB/s steken.
Dat moet beter kunnen, toch? M'n pool zou het makkelijk aan moeten kunnen (heb 283 MB/s read, 220 MB/s write volgens ZFSGuru benchmark) en met iperf haal ik de volle 1 Gb/s (==125 MB/s).
Hoe kom ik erachter waar de bottleneck zit?
Als ik lees vanaf de share gebruikte smbd gemiddeld zo'n 10% CPU en zit ie de hele tijd op de state select. Tijdens het schrijven naar de share verbruikt smbd iets meer (~20% CPU) en wisselt hij voornamelijk tussen de states RUN en sbwait. Mocht dat nuttige info zijn
Qua performance tweaks heb ik dit in m'n smb.conf staan:
code:
1
2
3
4
5
6
7
8
9
10
11
12
| # Performance tweaks
read raw = yes
write raw = yes
use sendfile = yes
max log size = 50
log level = 1
socket options = IPTOS_LOWDELAY TCP_NODELAY SO_KEEPALIVE
# asynchronous I/O (improves performance on multiqueue I/O)
aio read size = 1
aio write size = 1
aio write behind = true |
Gewoon een heel grote verzameling snoertjes
:strip_icc():strip_exif()/u/88058/strandballengifts1032_200.jpg?f=community)
Ik geloof dat ZFS on Linux samen met een SSD cache goede resultaten begint te leveren 
Het zat naar alle waarschijnlijkheid niet meer in RAM, aangezien mijn ARC op slechts 2GB staat ingesteld (standaard setting met ZoL). Wel is de meetmethode lekker nutteloos, dit is namelijk een Windows Vista VM waarbij alle IO via VirtIO gebeurd. Ik moet wel zeggen dat de VM een héél stuk soepeler aanvoelt na de switch van IDE naar VirtIO voor de schijven
Pool status:
Ik moet alleen wél bekennen dat ik compressie aan heb staan, en dat dit waarschijnlijk een heel stuk helpt met het behalen van snelheden die boven de limieten van SATA3 en mijn schijven liggen
Het zat naar alle waarschijnlijkheid niet meer in RAM, aangezien mijn ARC op slechts 2GB staat ingesteld (standaard setting met ZoL). Wel is de meetmethode lekker nutteloos, dit is namelijk een Windows Vista VM waarbij alle IO via VirtIO gebeurd. Ik moet wel zeggen dat de VM een héél stuk soepeler aanvoelt na de switch van IDE naar VirtIO voor de schijven Pool status:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
| # zpool status tank
pool: tank
state: ONLINE
scan: scrub canceled on Tue Sep 17 18:50:16 2013
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
raidz2-0 ONLINE 0 0 0
ata-HGST_HTS541010A9E680_JB100013J2RP1A ONLINE 0 0 0
ata-HGST_HTS541010A9E680_JB100013J3ST5B ONLINE 0 0 0
ata-HGST_HTS541010A9E680_JB100013J3TXGB ONLINE 0 0 0
ata-HGST_HTS541010A9E680_JB40001MGG3MJC ONLINE 0 0 0
ata-HGST_HTS541010A9E680_JB100013J4HGNB ONLINE 0 0 0
ata-HGST_HTS541010A9E680_JB100013J4J15B ONLINE 0 0 0
logs
ata-INTEL_SSDSA2CW120G3_CVPR126608BS120LGN-part1 ONLINE 0 0 0
cache
ata-INTEL_SSDSA2CW120G3_CVPR126608BS120LGN-part2 ONLINE 0 0 0
errors: No known data errors |
Ik moet alleen wél bekennen dat ik compressie aan heb staan, en dat dit waarschijnlijk een heel stuk helpt met het behalen van snelheden die boven de limieten van SATA3 en mijn schijven liggen
code:
1
2
3
4
| # zfs get compression,compressratio tank/vm_images NAME PROPERTY VALUE SOURCE tank/vm_images compression lzjb local tank/vm_images compressratio 1.50x - |
[ Voor 11% gewijzigd door Xudonax op 17-09-2013 22:20 ]
Thx, dit heeft al iets geholpen, ik kan nu lezen met een redelijk stabiele 66 MB/s. Maar vind nog steeds dat het hoger moet kunnen
Zijn er überhaupt mensen hier die beter presterende Samba-setups hebben? Zo ja, hoe hoog en met welke tweaks?
[ Voor 18% gewijzigd door Compizfox op 17-09-2013 23:06 ]
Gewoon een heel grote verzameling snoertjes
:strip_icc():strip_exif()/u/96747/gnu_linux_poster_60.jpg?f=community)
"You smell that, son? What sir? Napalm, I love the smell of napalm in the mornin!" || Children of Bodom fan!
:strip_exif()/u/70909/BlueKachina_60x60.gif?f=community)
/u/203831/ts2.PNG?f=community)
CiPHER: schrijf even een mooi verhaal op nieuws: Nieuwe organisatie wil ontwikkeling zfs-bestandssysteem sturen waarom mensen ZFS moeten nemen
Ik vond het ook wel een dappere zet. Misschien een gedistribueerde ZFS cluster over een stap RaspberryPi's met automatische failover en nog meer fancy shit:
[...]
RaspberryPi, OMFG, dat gaat nooit performen
:strip_icc():strip_exif()/u/6607/klootviool2.jpg?f=community)
Alle ZFS ontwikkelaars van de verschillende open systemen hadden elkaar natuurlijk allang gevonden (zie ZFS feature flags), maar het is mooi dat ze nu officieel samenwerken. Dit is zeer gunstig voor de toekomst van open source ZFS. Het zou nog mooier zijn als Oracle uiteindelijk samen ging werken met OpenZFS, maar dat zie ik niet gebeuren
/u/286685/crop58fcf863c48a5.png?f=community)
Ik weet niet of dit interessant voor je is, maar ik gebruik gewoon samba (niet de in ZFS ingebouwde samba) en die werkt zeer vlot. Grote bestanden (50GB) leest hij aan 81MB/s, met pieken tot 86MB/s, schrijven doet hij aan 110MB/s, zowat de volledige ethernet snelheid hier. Deze samba config heeft niets van tuning of dergelijke, dus je kan dit ook even snel proberen om te zien wat dat geeftThx, dit heeft al iets geholpen, ik kan nu lezen met een redelijk stabiele 66 MB/s. Maar vind nog steeds dat het hoger moet kunnen
Zijn er überhaupt mensen hier die beter presterende Samba-setups hebben? Zo ja, hoe hoog en met welke tweaks?
"Religion is an insult to human dignity. With or without it you would have good people doing good things and evil people doing evil things. But for good people to do evil things, that takes religion." - Steven Weinberg
Mijn excuses daarvoor, zal me ergens slecht ingelezen hebben dan 
maar de gevraagde resultaten heb je
maar de gevraagde resultaten heb je
:strip_exif()/u/58130/reimudanceresized.gif?f=community)
Beste mensen,
Ik wil graag mijn server/NAS vervangen en wil deze keer ZFS gebruiken omdat mijn huidige server soms last heeft van bitrot
Daarom wil ik graag een systeem dat ECC geheugen ondersteunt (Intel Celeron G1610, Intel Server Board S1200KPR of Asus P8B-X en Kingston unbuffered ECC RAM 2x8GB).
Nu heb ik een systeem met 3x1TB in RAID5 waar Ubuntu server 11.04 op draait. Dit wil ik vervangen door 3x3TB (Seagate Barracuda ST3000DM001) in RAIDZ en dan een 4TB schijf (offsite) als backup.
Ik heb gelezen dat ZFS on Linux stabiel is, dus als ik weer linux op mijn server wil draaien dan is dat mogelijk, maar is dat wel verstandig? Ik wil een goed, stabiel systeem waar ik op kan vertrouwen en als dat betekent dat ik het beste FreeBSD/NAS/whatever kan draaien dan wil ik dat serieus overwegen, ook al heb ik er geen ervaring mee.
Ik wil graag mijn server/NAS vervangen en wil deze keer ZFS gebruiken omdat mijn huidige server soms last heeft van bitrot
Daarom wil ik graag een systeem dat ECC geheugen ondersteunt (Intel Celeron G1610, Intel Server Board S1200KPR of Asus P8B-X en Kingston unbuffered ECC RAM 2x8GB).Nu heb ik een systeem met 3x1TB in RAID5 waar Ubuntu server 11.04 op draait. Dit wil ik vervangen door 3x3TB (Seagate Barracuda ST3000DM001) in RAIDZ en dan een 4TB schijf (offsite) als backup.
Ik heb gelezen dat ZFS on Linux stabiel is, dus als ik weer linux op mijn server wil draaien dan is dat mogelijk, maar is dat wel verstandig? Ik wil een goed, stabiel systeem waar ik op kan vertrouwen en als dat betekent dat ik het beste FreeBSD/NAS/whatever kan draaien dan wil ik dat serieus overwegen, ook al heb ik er geen ervaring mee.
ZFS on Linux is wel stabiel (van horen zeggen, geen first-hand ervaring mee), maar als je bereid bent je wat te verdiepen in FreeBSD kan ik je dat zeker aanraden.
De ZFS-implementatie in FreeBSD is wat volwassener dan in Linux en je hebt als voordeel dat er distro's als ZFSGuru bestaan (met een fijne webinterface voor ZFS).
Ik zie verder ook geen nadeel als je de server niet hoeft te gebruiken voor dingen die niet of moeilijk op FreeBSD draaien. FreeBSD als OS wordt over het algemeen ook als stabieler beschouwd dan Linux
Gewoon een heel grote verzameling snoertjes
Dat weet ik, en dat ontken ik ook niet. Het enige wat ik zeg is dat ZFS al gewoon langer in FreeBSD zit en dat het daarom 'volwassener' is. Ik heb nooit beweerd dat ZFS on Linux niet stabiel is of zo.
Voorbeeldje: FreeBSD is één van de weinige OS'sen die ZFS-support in de bootloader heeft zitten. Je kunt dus booten vanaf een RAIDZ-pool. Probeer dat maar eens onder Linux
Voorbeeldje: FreeBSD is één van de weinige OS'sen die ZFS-support in de bootloader heeft zitten. Je kunt dus booten vanaf een RAIDZ-pool. Probeer dat maar eens onder Linux
Gewoon een heel grote verzameling snoertjes
U vraagt, wij draaien::
Voorbeeldje: FreeBSD is één van de weinige OS'sen die ZFS-support in de bootloader heeft zitten. Je kunt dus booten vanaf een RAIDZ-pool. Probeer dat maar eens onder Linux
https://github.com/zfsonl...ative-ZFS-Root-Filesystem
Het is misschien niet zo bekend, maar dat bestaat al geruime tijd.
"Religion is an insult to human dignity. With or without it you would have good people doing good things and evil people doing evil things. But for good people to do evil things, that takes religion." - Steven Weinberg
:strip_exif()/u/279020/ava_mini.gif?f=community)
Bedankt voor de tips en ervaringen Ik hoef niet te booten van de RAIDZ array want ik heb ook een 120GB 2.5" hardeschijf waar ik van boot. Dan bestel ik binnenkort mijn nieuwe systeem en zal dan mijn ervaringen hier posten.
Ik hoef niet te booten van de RAIDZ array want ik heb ook een 120GB 2.5" hardeschijf waar ik van boot. Dan bestel ik binnenkort mijn nieuwe systeem en zal dan mijn ervaringen hier posten.
:strip_exif()/u/396800/D-_3427da0a9c293b63f2a66dea2e642102.gif?f=community)
Daar ben ik na lange tijd weer, want tja, een werkende NAS kijk je niet naar om
Begin augustus bleek in mijn RAIDZ zpool een van de schijven 1 Current_Pending_Sector te hebben. Deze week liep dit op van 11 begin deze week tot 13 vandaag. Vandaag was mijn pool degraded en inderdaad, de betreffende schijf bleek offline. Na een hoop geneuzel toch de pool weer kunnen importeren (dit duurde heel lang) en draait alles weer.
De vraag is echter. Moet ik me zorgen gaan maken en schijven gaan vervangen of kan het een simpele kabelfout of iets dergelijks zijn geweest? Ik had namelijk begrepen Current_Pending_Sector normaal gesproken maar onschuldig is.
Begin augustus bleek in mijn RAIDZ zpool een van de schijven 1 Current_Pending_Sector te hebben. Deze week liep dit op van 11 begin deze week tot 13 vandaag. Vandaag was mijn pool degraded en inderdaad, de betreffende schijf bleek offline. Na een hoop geneuzel toch de pool weer kunnen importeren (dit duurde heel lang) en draait alles weer.
De vraag is echter. Moet ik me zorgen gaan maken en schijven gaan vervangen of kan het een simpele kabelfout of iets dergelijks zijn geweest? Ik had namelijk begrepen Current_Pending_Sector normaal gesproken maar onschuldig is.
Sinds de 2 dagen regel reageer ik hier niet meer
Current Pending Sectors is bij lage niet groeiende aantallen inderdaad niet zo erg, maar het is wel een indicatie van slijtage. Als ze voorkomen als de schijf nog maar jong is, kan het betekenen dat er iets tijdens productie fout gegaan, is bij oudere schijven is het 'gewoon' slijtage.
De stat is dus zeker wel belangrijk om in de gaten te houden.
(Als je technisch inhoudelijk wil weten wat betekend, stel ik voor dat je Wikipedia er even op naslaat)
De stat is dus zeker wel belangrijk om in de gaten te houden.
(Als je technisch inhoudelijk wil weten wat betekend, stel ik voor dat je Wikipedia er even op naslaat
)
Even niets...
Oh, ik gebruik ZFSGuru en die maakt op elke schijf een freebsd-boot slice aan. Waar daar precies het nu van is snap ik dan niet helemaal
Gewoon een heel grote verzameling snoertjes
/u/98763/MysticSpiritBlack.JPG?f=community)
/u/362236/logo.JPG?f=community){kind=logo}
Nee, wel nice-to-have. Maar is inderdaad, zoals je zelf al aangeeft, duurder.
Kijk even 2 pagina's terug, daar stelde iemand exact dezelfde vraag
Compizfox in "Het grote ZFS topic"
Ja, dat klopt volledig. Het beste gebruik je gewoon je onboard SATA-controller, dat werkt het beste aangezien die AFAIK altijd AHCI-compliant zijn.
Je kunt eventueel zelf één pool (array) spannen over meerdere controllers.
[ Voor 16% gewijzigd door Compizfox op 20-09-2013 17:52 ]
Gewoon een heel grote verzameling snoertjes
:strip_exif()/u/351207/JKDZ2.gif?f=community)
Reallocated sector count is het aantal sectoren dat slecht/niet meer te lezen was en welke vervangen zijn door reserve sectoren. Als je nog garantie hebt en het daadwerkelijk zo snel omhoog gaat zou ik eens kijken naar de omgevingsfactoren, zeker omdat je ook een schijf hebt die pas 6 dagen oud is... Heeft de kast bijvoorbeeld een (flinke) dreun gehad waardoor er problemen kunnen zijn ontstaan?
Als je niets dergelijks kunt vinden en de teller blijft oplopen dan zou ik eens contact opnemen met de shop om de schijf te vervangen. Ik heb hetzelfde gehad met één van mijn 6 schijven, deze vloog ook omhoog van 0 naar ~500 reallocated sectors in een periode van krap een week. Deze kon ik gewoon terugsturen naar de shop (op eigen kosten, dat wel, maargoed ) en deze werd binnen een week netjes vervangen.
Als je niets dergelijks kunt vinden en de teller blijft oplopen dan zou ik eens contact opnemen met de shop om de schijf te vervangen. Ik heb hetzelfde gehad met één van mijn 6 schijven, deze vloog ook omhoog van 0 naar ~500 reallocated sectors in een periode van krap een week. Deze kon ik gewoon terugsturen naar de shop (op eigen kosten, dat wel, maargoed
) en deze werd binnen een week netjes vervangen.
Help!
Vanmiddag is m'n server even uitgeweest (nette shutdown), maar nu blijkt m'n pool degraded.
Volgens ZFSGuru is er een disk weg.
"One or more devices has been removed by the administrator.
Sufficient replicas exist for the pool to continue functioning in a
degraded state."
Disk gewoon overleden; of kan er nog iets anders aan de hand zijn?
Met dit soort fouten:
Shit, na een power cycle zijn al m'n VMs op de datastore inaccessible; datastore ook overleden?
Vanmiddag is m'n server even uitgeweest (nette shutdown), maar nu blijkt m'n pool degraded.
Volgens ZFSGuru is er een disk weg.
"One or more devices has been removed by the administrator.
Sufficient replicas exist for the pool to continue functioning in a
degraded state."
Disk gewoon overleden; of kan er nog iets anders aan de hand zijn?
Met dit soort fouten:
code:
1
2
3
4
5
| ahcich2: AHCI reset: device not ready after 31000ms (tfd = 00000080) ahcich2: Timeout on slot 24 port 0 ahcich2: is 00000000 cs 01000000 ss 00000000 rs 01000000 tfd 80 serr 001a0000 ahcich0: Timeout on slot 22 port 0 ahcich0: is 00000000 cs 00400000 ss 00000000 rs 00400000 tfd 50 serr 00000000 |
Shit, na een power cycle zijn al m'n VMs op de datastore inaccessible; datastore ook overleden?
[ Voor 38% gewijzigd door RudolfR op 21-09-2013 19:55 ]
Dat zijn ATA timeouts, die kun je krijgen doordat je schijf bezig is met ECC bijvoorbeeld. Even de PC in de BIOS aanlaten staan voor een tijdje, dan heb je kans dat hij na een paar minuten/uren weer reageert. Om wat voor schijven gaat het eigenlijk?:
Help!
Vanmiddag is m'n server even uitgeweest (nette shutdown), maar nu blijkt m'n pool degraded.
Volgens ZFSGuru is er een disk weg.
"One or more devices has been removed by the administrator.
Sufficient replicas exist for the pool to continue functioning in a
degraded state."
Disk gewoon overleden; of kan er nog iets anders aan de hand zijn?
Met dit soort fouten:
code:
Shit, na een power cycle zijn al m'n VMs op de datastore inaccessible; datastore ook overleden?
Gewoon een heel grote verzameling snoertjes
Bedankt voor de suggesties; zal kijken of ik ze in een andere machine kan hangen.
De controller is de Panther Point AHCI controller van m'n moederbord.
Verwacht ik geen problemen mee, zal 'ns kijken of ik daar wat mee kan rommelen.
ESXi-host had al best een tijdje aangestaan voordat ik m'n VMs vanmiddag aanzette.
Dus die tijd heeft de schijf wel gehad, denk ik.
Dat die datastore niet meewerkt is eigenlijk nog veel erger. Daar heb ik geen backup van.
- Fixed. 
Connector zat lossig.
Een van de disks zat op een SATA600 poort. Dus ik heb e.e.a herschikt; en nu zit die ene disk bij de andere 2 op de SATA300.
Disk wordt nu gewoon gevonden. En de pool is online. Resilver in progress.
Kan het SATA600 deel van de controller overlijden? Bord is nog geen jaar oud; dus dat valt misschien wel onder de garantie? Hoe controleer ik of het echt stuk is?
S.M.A.R.T. van de disk in kwestie; dat de Load Cycle Count (489667) aan de hoge kant is, is een bekend probleem met deze disks. APM is ingesteld op 254.
De controller is de Panther Point AHCI controller van m'n moederbord.
Verwacht ik geen problemen mee, zal 'ns kijken of ik daar wat mee kan rommelen.
| 3 | Samsung SpinPoint M8 HN-M101MBB, 1TB | € 61,45 | € 184,35 |
ESXi-host had al best een tijdje aangestaan voordat ik m'n VMs vanmiddag aanzette.
Dus die tijd heeft de schijf wel gehad, denk ik.
Dat die datastore niet meewerkt is eigenlijk nog veel erger. Daar heb ik geen backup van.
- Fixed. Connector zat lossig.Een van de disks zat op een SATA600 poort. Dus ik heb e.e.a herschikt; en nu zit die ene disk bij de andere 2 op de SATA300.
Disk wordt nu gewoon gevonden. En de pool is online. Resilver in progress.
Kan het SATA600 deel van de controller overlijden? Bord is nog geen jaar oud; dus dat valt misschien wel onder de garantie? Hoe controleer ik of het echt stuk is?
S.M.A.R.T. van de disk in kwestie; dat de Load Cycle Count (489667) aan de hoge kant is, is een bekend probleem met deze disks. APM is ingesteld op 254.
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
| # SMART attribute Flag Current Worst Thresh Failed RAW value 1 Raw_Read_Error_Rate 0x002f 100 100 051 - 15 2 Throughput_Performance 0x0026 252 252 000 - 0 3 Spin_Up_Time 0x0023 089 089 025 - 3462 4 Start_Stop_Count 0x0032 100 100 000 - 564 5 Reallocated_Sector_Ct 0x0033 252 252 010 - 0 7 Seek_Error_Rate 0x002e 252 252 051 - 0 8 Seek_Time_Performance 0x0024 252 252 015 - 0 9 Power_On_Hours 0x0032 100 100 000 - 12449 10 Spin_Retry_Count 0x0032 252 252 051 - 0 11 Calibration_Retry_Count 0x0032 100 100 000 - 305 12 Power_Cycle_Count 0x0032 100 100 000 - 86 181 Program_Fail_Cnt_Total 0x0022 098 098 000 - 62317280 191 G-Sense_Error_Rate 0x0022 252 252 000 - 0 192 Power-Off_Retract_Count 0x0022 252 252 000 - 0 194 Temperature_Celsius 0x0002 064 064 000 - 26 (Min/Max 17/40) 195 Hardware_ECC_Recovered 0x003a 100 100 000 - 0 196 Reallocated_Event_Count 0x0032 252 252 000 - 0 197 Current_Pending_Sector 0x0032 252 252 000 - 0 198 Offline_Uncorrectable 0x0030 252 252 000 - 0 199 UDMA_CRC_Error_Count 0x0036 200 200 000 - 0 200 Multi_Zone_Error_Rate 0x002a 100 100 000 - 0 223 Load_Retry_Count 0x0032 100 100 000 - 305 225 Load_Cycle_Count 0x0032 052 052 000 - 489667 |
[ Voor 56% gewijzigd door RudolfR op 22-09-2013 09:48 ]
/u/102334/avatar_mini.png?f=community){kind=avatar}
/u/87795/voetje.png?f=community)
:strip_exif()/u/62088/sp_jh2.gif?f=community)
Ik snap er weinig van. Gisteren de schijf met de fouten vervangen door een nieuwe. Tijdens het proces van vervangen liep de teller van de Current Pending Sector op tot 151. Nadat de schijf succesvol was vervangen was even een zero-write gedaan op die falende schijf. De teller van de Current Pending Sector is weer 0, máár de Reallocated Sector Ct is ook 0 gebleven 
. Weet iemand hoe dit kan?
. Weet iemand hoe dit kan?
Sinds de 2 dagen regel reageer ik hier niet meer
Dan waren die sectoren dus niet slecht als ik de uitleg hierboven goed gebruikt.:
Ik snap er weinig van. Gisteren de schijf met de fouten vervangen door een nieuwe. Tijdens het proces van vervangen liep de tellen van de Current Pending Sector op tot 151. Nadat de schijf succesvol vervangen was even een zero-write gedaan op die falende schijf. De teller van de Current Pending Sector is weer 0, máár de Reallocated Sector Ct is ook 0 gebleven
/u/231803/ramdisk2.png?f=community)
Als je er geforceerd 0 naar schrijft, boeit het niet meer welke data er op stond, en schrijft je disk gewoon de data eroverheen.:
Ik snap er weinig van. Gisteren de schijf met de fouten vervangen door een nieuwe. Tijdens het proces van vervangen liep de teller van de Current Pending Sector op tot 151. Nadat de schijf succesvol was vervangen was even een zero-write gedaan op die falende schijf. De teller van de Current Pending Sector is weer 0, máár de Reallocated Sector Ct is ook 0 gebleven
Schijven kunnen last hebben van bitrot, dat wil zeggen dat na een hele tijd een 1-tje een 0-tje kan worden omdat het magnetisch veld te laag word.
Als je die sector uitleest en hij kan het niet met zekerheid zeggen, krijg je een Bad Sector. Je disk gaat dan proberen de sector te relocaten (binnen een afzienbare tijd).
Als je zelf in de tussentijd schrijft naar die sector kan het zo zijn dat hij op de oude sector gewoon nieuwe data plempt en de sector dus niet heeft hoeven te vervangen.
Je sector is dus nu blijkbaar weer goed omdat het magnetisch veld er opnieuw opgezet is.
Wel vind ik het vaag dat de sector niet meteen is gerelocate toen er problemen mee waren.
Even niets...
Ja, even de goede workgroup instellen bij de Samba instellingen. (en de hostname wijzigen natuurlijk )
)
[ Voor 24% gewijzigd door FireDrunk op 23-09-2013 15:57 ]
Even niets...
Ik ben overgestapt van ZFSguru naar Ubuntu. Ubuntu is dus m'n server en niet m'n client. Excuus dat ik dit niet duidelijk had vermeld.:
Ja, even de goede workgroup instellen bij de Samba instellingen. (en de hostname wijzigen natuurlijk
Dat begreep ik, en mijn antwoord geld nog steeds
Samba gaat pas zijn hostname broadcasten als hij in de goede werkgroep zit, anders blijft het ip only.
Samba gaat pas zijn hostname broadcasten als hij in de goede werkgroep zit, anders blijft het ip only.
[ Voor 50% gewijzigd door FireDrunk op 23-09-2013 16:10 ]
Even niets...
Ja, maar het is een enorme tegenvaller. (Zie mijn posts op deze pagina van het Zuinige ESXi Server topic):
[...]
Update, ESXi 5.5 is gisteren uitgekomen
[ Voor 4% gewijzigd door Compizfox op 23-09-2013 16:33 ]
Gewoon een heel grote verzameling snoertjes
:strip_exif()/u/17028/ico_sphere.gif?f=community)