Re: immense delayed write to file system (ZFS and UFS2), performance issues
on 27/01/2010 22:26 Tommi Lätti said the following: Seems that the performance is indeed atrocious. I recently (like 2 days ago) had to rescue my zfs pool under opensolaris to spare disks. The performance under OpenSol was what I was expecting, 70MB/s reading and writing at the same time. Now that I'm restoring the stuff back under FreeBSD 8.0-p2 it seems that first the array reads from the source disk and then stops reading and decides to empty the buffer to the destination. There's usually a 2 second pause and after that it goes back to reading. There seems to be something really wrong with this, fbsd zfs implementation seems to be unable to move data between 2 zfs pools writing and reading simultaneously... I think I'll just boot back to opensol and do the transfers there. I've been seeing things like this too. Also, when copying between UFS and ZFS. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: immense delayed write to file system (ZFS and UFS2), performance issues
On Tue, 26 Jan 2010 20:45:10 +0200 Dan Naumov wrote: This discussion made me have a look at my 2tb WD Green disks... So did I. Hm, it's a nice feature: - Model Family: Western Digital RE2-GP family Device Model: WDC WD1000FYPS-01ZKB0 Firmware Version: 02.01B01 User Capacity:1 000 204 886 016 bytes ... 9 Power_On_Hours 0x0032 082 082 000Old_age Always - 13206 193 Load_Cycle_Count0x0032 001 001 000Old_age Always - 1883216 - Seems I'm a winner with my nearly 2M cycles. :-( I use another script to stop that horror at five disks: - #!/bin/sh while true; do for i in `jot 5`; do sudo fdisk -p ada$i /dev/null 21 done sleep 5 done - -- WBR, Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone Internet SP FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: immense delayed write to file system (ZFS and UFS2), performance issues
On 2010-01-27 00:15, Dan Naumov wrote: Can anyone confirm that using the WDIDLE3 utility on the 2TB WD20EADS discs will not cause any issues if these disks are part of a ZFS mirror pool? I do have backups of data, but I would rather not spend the time rebuilding the entire system and restoring enormous amounts of data over a 100mbit network unless I absolutely have to :) Sorry to bump into this thread so late, but for some of my servers I have been using a patch for atacontrol, to turn the APM features of the disk(s) off, for a long time. This is mostly noticable with 2.5 notebook disks, which click like crazy all the time. :) E.g. if you run atacontrol cap $device, and you see in the output that advanced power management is supported, you might be able to stop the disk from spinning down by turning the APM feature off. Patch is at http://www.andric.com/freebsd/atacontrol-apm.diff. This should apply to 8-STABLE, no idea about older branches. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: immense delayed write to file system (ZFS and UFS2), performance issues
Seems that the performance is indeed atrocious. I recently (like 2 days ago) had to rescue my zfs pool under opensolaris to spare disks. The performance under OpenSol was what I was expecting, 70MB/s reading and writing at the same time. Now that I'm restoring the stuff back under FreeBSD 8.0-p2 it seems that first the array reads from the source disk and then stops reading and decides to empty the buffer to the destination. There's usually a 2 second pause and after that it goes back to reading. There seems to be something really wrong with this, fbsd zfs implementation seems to be unable to move data between 2 zfs pools writing and reading simultaneously... I think I'll just boot back to opensol and do the transfers there. -- br, Tommi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: immense delayed write to file system (ZFS and UFS2), performance issues
On Wed, Jan 27, 2010 at 12:25:58PM +0100, Dimitry Andric wrote: On 2010-01-27 00:15, Dan Naumov wrote: Sorry to bump into this thread so late, but for some of my servers I have been using a patch for atacontrol, to turn the APM features of the disk(s) off, for a long time. This is mostly noticable with 2.5 notebook disks, which click like crazy all the time. :) Turning off APM seems to be the LINUX world's solution to this and other similar problems. I got the impression that Windows also does this. -- Adrian Wontroba Save energy: be apathetic. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: immense delayed write to file system (ZFS and UFS2), performance issues
On Tue, 19 Jan 2010 03:24:49 -0800 Jeremy Chadwick free...@jdc.parodius.com wrote about Re: immense delayed write to file system (ZFS and UFS2), performance issues: JC So which drive models above are experiencing a continual increase in JC SMART attribute 193 (Load Cycle Count)? My guess is that some of the JC WD Caviar Green models, and possibly all of the RE2-GP and RE4-GP JC models are experiencing this problem. Just to add some more info: I contacted WD support about the problem with RE4 drives and received a firmware update by email today which is supposed to fix the problem. Did not try it yet, though. I am still busy replacing RE2-disks with updated drives. I came across a very strange thing with zfs. Actually I had the following pool layout: mclane# zpool status pool: tank state: ONLINE scrub: none requested config: NAMESTATE READ WRITE CKSUM tankONLINE 0 0 0 raidz1ONLINE 0 0 0 ad8 ONLINE 0 0 0 ad10ONLINE 0 0 0 ad12ONLINE 0 0 0 spares ad14 AVAIL errors: No known data errors All disks still have the firmware bug, so I want to replace them with disks that I already fixed. I put in a updated drive as ad18 and wanted to replace ad12 to get the drive with the broken firmware out: mclane# zpool replace tank /dev/ad12 /dev/ad18 mclane# zpool status pool: tank state: ONLINE status: One or more devices is currently being resilvered. The pool will continue to function, possibly in a degraded state. action: Wait for the resilver to complete. scrub: resilver in progress for 0h0m, 0.01% done, 52h51m to go config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ad8ONLINE 0 0 0 7.21M resilvered ad10 ONLINE 0 0 0 7.22M resilvered replacing ONLINE 0 0 0 ad12 ONLINE 0 0 0 ad18 ONLINE 0 0 0 10.7M resilvered spares ad14 AVAIL errors: No known data errors However, something must have gone wrong during the resilvering process and it now looks like this: mclane# zpool status pool: tank state: DEGRADED 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://www.sun.com/msg/ZFS-8000-9P scrub: resilver completed after 2h39m with 0 errors on Tue Jan 26 14:00:00 2010 config: NAME STATE READ WRITE CKSUM tank DEGRADED 0 0 0 raidz1 DEGRADED 0 0 0 ad8ONLINE 0 0 0 975M resilvered ad10 ONLINE 0 0 142 974M resilvered replacing DEGRADED 0 7.25M 0 ad12 ONLINE 0 0 0 ad18 REMOVED 0 1 0 79.4M resilvered spares ad14 AVAIL errors: No known data errors What is going on here? ad18 obviously detached during the process. /var/log/messages just gives me Jan 26 11:23:33 mclane kernel: ad18: FAILURE - device detached Additionally ad10 obviously produced chksum errors. What do I do about the degraded replacing process? Can I terminate it somehow and maybe replace ad10 first? Any other hints? cu Gerrit ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: immense delayed write to file system (ZFS and UFS2), performance issues
:I'm experiencing the same thing, except in my case it's most noticeable :when writing to a USB flash drive with a FAT32 filesystem. It slows the :entire system down, even if the data being written is coming from cache :or a memory file system. : :I don't know if it's related. I'm running 8-STABLE from about 4 December. : :Regards, :Aragon I don't know re: the main thread but in regards to writing to a USB flash drive interfering with other operations the most likely cause is that the buffer cache fills up with dirty buffers destined for the (slow) USB drive. This causes other unrelated drive subsystems to block on the buffer cache. There are no easy answers. A poor-man's solution would be to limit dirty buffers in the buffer cache to 80% of the nominal dirty maximum on a per-mount basis so no single mount can kill the buffer cache. (One can't just cut-up the buffer cache as that would leave too few buffers available for each mount to operate efficiently). A per-mount minimum buffer guarantee would also help smooth things out but the value would have to be small (comprise no more than 20% of the buffer cache in aggregate). In the case of UFS the write-behind code is asynchronous, so even though UFS wants to flush the buffers out all that happens in reality when writing to slow media is that the dirty buffers wind up on the I/O queue (which is actually worse then leaving them B_DELWRI in the buffer cache because now the VM pages are all soft-busied). -Matt Matthew Dillon dil...@backplane.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: immense delayed write to file system (ZFS and UFS2), performance issues
On Tue, 19 Jan 2010 10:28:58 +0100 Morgan Wesström freebsd-questi...@pp.dyndns.biz wrote: Garrett Moore wrote: The drives being discussed in my related thread (regarding poor performance) are all WD Green drives. I have used wdidle3 to set all of my drive timeouts to 5 minutes. I'll see what sort of difference this makes for performance. Even if it makes no difference to performance, thank you for pointing it out -- my drives have less than 2,000 hours on them and were all over 90,000 load cycles due to this moronic factory setting. Since changing the timeout, they haven't parked (which is what I would expect). You're welcome. I just feel as bad for you as for everyone else who has bought these obviously Windoze optimized harddrives. Unfortunately neither wdidle3 nor an updated firmware is available or functioning on the latest models in the Green series. At least that's what I've read from other people having this issue. WD only claims they don't support Linux and they probably have never heard of FreeBSD. You might be able to tune the APM settings on the drive using sysutils/ataidle to change the amount of time the drive waits until parking the heads. -- Bruce Cran ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
RE: immense delayed write to file system (ZFS and UFS2), performance issues
You're welcome. I just feel as bad for you as for everyone else who has bought these obviously Windoze optimized harddrives. Unfortunately neither wdidle3 nor an updated firmware is available or functioning on the latest models in the Green series. At least that's what I've read from other people having this issue. WD only claims they don't support Linux and they probably have never heard of FreeBSD. This discussion made me have a look at my 2tb WD Green disks, one of them is from May 2009, looks pretty reasonable : Device Model: WDC WD20EADS-00R6B0 Serial Number:WD-WCAVY0301430 Firmware Version: 01.00A01 9 Power_On_Hours 0x0032 093 093 000Old_age Always - 5253 193 Load_Cycle_Count0x0032 200 200 000Old_age Always - 55 And another is very recent, from December 2009, this does look a bit worrying in comparison: Device Model: WDC WD20EADS-32R6B0 Serial Number:WD-WCAVY1611513 Firmware Version: 01.00A01 9 Power_On_Hours 0x0032 100 100 000Old_age Always - 136 193 Load_Cycle_Count0x0032 199 199 000Old_age Always - 5908 The disks are of exact same model and look to be same firmware. Should I be worried that the newer disk has, in 136 hours reached a higher Load Cycle count twice as big as on the disk thats 5253 hours old? - Sincerely, Dan Naumov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: immense delayed write to file system (ZFS and UFS2), performance issues
On Tue, 26 Jan 2010 20:45:10 +0200 Dan Naumov dan.nau...@gmail.com wrote: The disks are of exact same model and look to be same firmware. Should I be worried that the newer disk has, in 136 hours reached a higher Load Cycle count twice as big as on the disk thats 5253 hours old? There's a similar problem with laptop HDDs and APM settings that cause a high load_cycle_count too. According to https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/59695 and many blog entries, parking the heads frequently can shorten the HDD lifetime. -- Bruce Cran ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: immense delayed write to file system (ZFS and UFS2), performance issues
9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 136 193 Load_Cycle_Count 0x0032 199 199 000 Old_age Always - 5908 The disks are of exact same model and look to be same firmware. Should I be worried that the newer disk has, in 136 hours reached a higher Load Cycle count twice as big as on the disk thats 5253 hours old? Well AFAIK WD certifies that there's no extra risk involved unless you go over 300.000 park cycles. On the other hand, my 9 month 1.5tb green drive has over 200.000 cycles. Maybe check if you can disable the idle timer using WDIDLE3... works for my drives (although it did some strange things to one out of the 6 drives -- decreased reported sector count and the zfs invalidated the pool :/ ). -- br, Tommi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: immense delayed write to file system (ZFS and UFS2), performance issues
Hi-- On Jan 26, 2010, at 10:45 AM, Dan Naumov wrote: 9 Power_On_Hours 0x0032 100 100 000Old_age Always - 136 193 Load_Cycle_Count0x0032 199 199 000Old_age Always - 5908 The disks are of exact same model and look to be same firmware. Should I be worried that the newer disk has, in 136 hours reached a higher Load Cycle count twice as big as on the disk thats 5253 hours old? Yes. Drive actuators are (or used to be) typically rated for at least 50,000 load-cycle counts; at ~1000 events per day, there's about a 50% chance of such a drive dying before two years are up: http://en.wikipedia.org/wiki/Hard_disk_drive#Landing_zones_and_load.2Funload_technology Some models of drives intended for laptops (typically smaller 2.5 form factor w/ single platter) can tolerate many more load-cycles, and newer drives also claim to handle more. Regards, -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: immense delayed write to file system (ZFS and UFS2), performance issues
On Wed, 27 Jan 2010 03:53:20 +0900 Tommi Lätti s...@iki.fi wrote about Re: immense delayed write to file system (ZFS and UFS2), performance issues: TL Well AFAIK WD certifies that there's no extra risk involved unless you TL go over 300.000 park cycles. On the other hand, my 9 month 1.5tb green TL drive has over 200.000 cycles. I think the RE2 drives I have here are certified for 600k cycles. TL Maybe check if you can disable the idle timer using WDIDLE3... works TL for my drives (although it did some strange things to one out of the 6 TL drives -- decreased reported sector count and the zfs invalidated the TL pool :/ ). I can only encourage everyone having this problem to report to WD's support about this. Today I received an update for the firmware of RE4-drives (which I did not try out yet). IMHO, the more people complain about these issues, the higher is the chance that WD will do something about it. cu Gerrit ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
RE: immense delayed write to file system (ZFS and UFS2), performance issues
Can anyone confirm that using the WDIDLE3 utility on the 2TB WD20EADS discs will not cause any issues if these disks are part of a ZFS mirror pool? I do have backups of data, but I would rather not spend the time rebuilding the entire system and restoring enormous amounts of data over a 100mbit network unless I absolutely have to :) - Sincerely, Dan Naumov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: immense delayed write to file system (ZFS and UFS2), performance issues
On Wed, Jan 27, 2010 at 01:15:17AM +0200, Dan Naumov wrote:
Can anyone confirm that using the WDIDLE3 utility on the 2TB WD20EADS
discs will not cause any issues if these disks are part of a ZFS
mirror pool? I do have backups of data, but I would rather not spend
the time rebuilding the entire system and restoring enormous amounts
of data over a 100mbit network unless I absolutely have to :)
How about using the write every 5 seconds python script posted earlier
in this thread by e...@tefre.com? Works nicely for me and stops the load
cycle count increase.
Thank you Erik!
To save searching, here is Erik's script as used here.
#!/usr/local/bin/python
# Author: Erik Stian Tefre e...@tefre.com
#Keeping this python script running prevents Load_Cycle_Count from
#incrementing on my WD15EADS drives by forcing a write every 5 seconds (2
#drive zfs mirror pool, average of 2 load cycles per minute when the
#script is not running):
import time,os
mypool = /tank
# ^^ Change to your pool!
fname = os.path.join(mypool, wd_green_anti_idle.pyfile)
c = 0
f = open(fname, w)
while True:
if c == 100:
f.close()
f = open(fname, w)
c = 0
c += 1
time.sleep(5)
f.write(a)
f.flush()
os.fsync(f.fileno())
You might find this handy too:
#!/bin/sh
# $FreeBSD:$
# PROVIDE: wd_green_anti_idle
# REQUIRE: LOGIN
. /etc/rc.subr
wd_green_anti_idle_enable=${wd_green_anti_idle_enable-NO}
name=wd_green_anti_idle
rcvar=`set_rcvar`
command=/usr/local/stade/bin/wd_green_anti_idle.py
start_cmd=wd_green_anti_idle_start
wd_green_anti_idle_start()
{
if ! checkyesno wd_green_anti_idle_enable ; then
return 0
fi
echo Starting ${name}.
${command}
}
load_rc_config $name
run_rc_command $*
Adjust command name to suit, put in /usr/local/etc/rc.d, add
wd_green_anti_idle_enable=YES to /etc/rc.conf and the script starts
running during startup. A minor bug - it doesn't close down.
--
Adrian Wontroba
A witty saying proves nothing, but saying something pointless gets
people's attention.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: immense delayed write to file system (ZFS and UFS2), performance issues
Adrian Wontroba wrote: : How about using the write every 5 seconds python script posted earlier : in this thread by e...@tefre.com? Works nicely for me and stops the load : cycle count increase. I have a WD2003FYPS sitting in a system, to be used for testing. Bought it just before this thread started, and here's what it looks like right now: 9 Power_On_Hours 0x0032 100 100 000Old_age Always - 508 193 Load_Cycle_Count 0x0032 200 200 000Old_age Always - 2710 This drive is sitting, unused, with no filesystem, and I've performed approximately zero writes to the disk. Having a script kick off and write to a disk will help so long as that disk is writable; if it's being used as a hot spare in a raidz array, it's not going to help much. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
RE: immense delayed write to file system (ZFS and UFS2), performance issues
Thank you, thank you, thank you! Now I neither have to worry about premature death of my disks, nor do I have to endure the loud clicking noises (I have a NAS with these in my living room)! If either of you (or both) want me to Paypal you money for a beer, send me details offlist :) - Sincerely, Dan Naumov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
RE: immense delayed write to file system (ZFS and UFS2), performance issues
I have a WD2003FYPS sitting in a system, to be used for testing. Bought it just before this thread started, and here's what it looks like right now: 9 Power_On_Hours 0x0032 100 100 000Old_age Always - 508 193 Load_Cycle_Count 0x0032 200 200 000Old_age Always - 2710 This drive is sitting, unused, with no filesystem, and I've performed approximately zero writes to the disk. Having a script kick off and write to a disk will help so long as that disk is writable; if it's being used as a hot spare in a raidz array, it's not going to help much. I wouldn't worry in your particular case. A value of 2710 in 508 hours is a rate of 5,33/hour. At this rate, it's going to take you 56285 hours or 2345 days to reach 300,000 and most disks will likely function past 400,000 (over 600,000 all bets are off though). The people who need(ed) to worry were people like me, who were seeing the rate increase at a rate of 43+ per hour. - Sincerely, Dan Naumov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: immense delayed write to file system (ZFS and UFS2), performance issues
Dan Naumov wrote: : This drive is sitting, unused, with no filesystem, and I've performed : approximately zero writes to the disk. : : Having a script kick off and write to a disk will help so long as that : disk is writable; if it's being used as a hot spare in a raidz array, it's : not going to help much. : : I wouldn't worry in your particular case. A value of 2710 in 508 hours : is a rate of 5,33/hour. At this rate, it's going to take you 56285 : hours or 2345 days to reach 300,000 and most disks will likely : function past 400,000 (over 600,000 all bets are off though). The : people who need(ed) to worry were people like me, who were seeing the : rate increase at a rate of 43+ per hour. Which is why I haven't spoken up on the thread -- I'm not terribly worried. Specific cases aside, writing to the FS is a workaround to a rather inconvenient issue. I, too, would like to see if the problem is fixed, not avoided, by using wdidle -- but I suspect I'll have to contact WD myself to get that confirmation. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: immense delayed write to file system (ZFS and UFS2), performance issues
On Tue, Jan 26, 2010 at 07:49:05PM -0500, Damian Gerow wrote: Specific cases aside, writing to the FS is a workaround to a rather inconvenient issue. I, too, would like to see if the problem is fixed, not avoided, by using wdidle -- but I suspect I'll have to contact WD myself to get that confirmation. A convenient workaround indeed. Much easier than running DOS (I assume) firmware twidding programs or firmware updates. As for wdidle - see the tail end of http://www.readynas.com/forum/viewtopic.php?f=24t=32179. Sufficient customer complaints might produce a real firmware fix. One thing I'm sure of - the next time I buy a set of disks for my home fileserver, I'll spend some time on research rather than rushing to join the queue (8-( -- Adrian Wontroba I'd rather just believe that it's done by little elves running around. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: immense delayed write to file system (ZFS and UFS2), performance issues
Here's what I got from one of my 2TB WD green drives. This one is Firmware 01.00A01. Load_Cycle_Count is 26... seems under control. It gets hit with a lot of activity separated by a lot of time (several minutes to several hours), depending on what is going on. The box is used for filesystem testing. Regardless it seems to stay spun-up all the time, or nearly all the time. Neither the BIOS nor the kernel driver is messing with the SUD control on the Silicon Image board it is connected to (other then just turning it on and leaving it that way). If the drive has an intelligent parking function it doesn't seem to be using it much. I haven't specifically disabled any such function. Device Model: WDC WD20EADS-00R6B0 Serial Number:WD-WCAVY0259672 Firmware Version: 01.00A01 User Capacity:2,000,398,934,016 bytes Device is:Not in smartctl database [for details use: -P showall] ATA Version is: 8 ATA Standard is: Exact ATA specification draft version not indicated Local Time is:Tue Jan 26 19:25:48 2010 PST SMART support is: Available - device has SMART capability. SMART support is: Enabled ... ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x002f 200 200 051Pre-fail Always - 0 3 Spin_Up_Time0x0027 212 150 021Pre-fail Always - 6375 4 Start_Stop_Count0x0032 100 100 000Old_age Always - 39 5 Reallocated_Sector_Ct 0x0033 200 200 140Pre-fail Always - 0 7 Seek_Error_Rate 0x002e 200 200 000Old_age Always - 0 9 Power_On_Hours 0x0032 095 095 000Old_age Always - 4252 10 Spin_Retry_Count0x0032 100 253 000Old_age Always - 0 11 Calibration_Retry_Count 0x0032 100 253 000Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000Old_age Always - 37 192 Power-Off_Retract_Count 0x0032 200 200 000Old_age Always - 13 193 Load_Cycle_Count0x0032 200 200 000Old_age Always - 26 194 Temperature_Celsius 0x0022 121 111 000Old_age Always - 31 196 Reallocated_Event_Count 0x0032 200 200 000Old_age Always - 0 197 Current_Pending_Sector 0x0032 200 200 000Old_age Always - 0 198 Offline_Uncorrectable 0x0030 200 200 000Old_age Offline - 0 199 UDMA_CRC_Error_Count0x0032 200 200 000Old_age Always - 0 200 Multi_Zone_Error_Rate 0x0008 200 200 000Old_age Offline - 0 I have a few of these babies strewn around. The others show about the same stats, e.g. this one is used in a production box. Same drive type, same firmware: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 9 Power_On_Hours 0x0032 095 095 000Old_age Always - 4164 12 Power_Cycle_Count 0x0032 100 100 000Old_age Always - 43 193 Load_Cycle_Count0x0032 200 200 000Old_age Always - 26 ... So on the face of it things seem ok with these drives. Presumably WD is working adjustments into the firmware as time goes on. Hopefully they aren't just masking the count in the SMART page to appease techies :-) These particular WDs (2TB Caviar Green's) are slow drives. 5600 rpm, 100MB/sec. But they are also very quiet in operation and seem to be quite power efficient. -Matt Matthew Dillon dil...@backplane.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: immense delayed write to file system (ZFS and UFS2), performance issues
On Tue, 26 Jan 2010 19:12:01 -0500 Damian Gerow dge...@afflictions.org wrote about Re: immense delayed write to file system (ZFS and UFS2), performance issues: DG Adrian Wontroba wrote: DG Having a script kick off and write to a disk will help so long as that DG disk is writable; if it's being used as a hot spare in a raidz array, DG it's not going to help much. For my RE2 and RE4 disks I wrote a script that calls smartctl -a on all disks (one after another) every 5s or so. This also prevents the counter to increase in my setup and you can do it for every disk, no matter if they are in a raid compound or not. I think writing to the disks may also fail the desired effect if you have stripes the writes are spead to (raid 50 or similar zpool setups). Just my 2¢. cu Gerrit ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: immense delayed write to file system (ZFS and UFS2), performance issues
On 01/18/10 22:13, O. Hartmann wrote: Symptome: All boxes have ZFS and UFS2 filesystems. Since two weeks or so, sometimes the I/O performance drops massively when doing 'svn update', 'make world' or even 'make kernel'. It doesn't matter what memory and how many cpu the box has, it get stuck for several seconds and freezing. On the UP box, this is sometimes for 10 - 20 seconds. A very interesting phenomenon is the massively delayed file writing on ZFS filesystems I realise. Editing a file in 'vi' running on one XTerm and having in another Xterminal my shell for compiling this file, it takes sometimes up to 20 seconds to get the file updated after it has been written. It's like having an old, slow NFS connection with long cache delays. These massively delayed file transactions are not necessarely under heavy load, sometimes they occur in a relaxed situation. They seem to occur much more often on the UP box than on the SMP boxes, but this strange phenomenon also occur on the Dell Poweredge II, which has 16GB RAM and summa summarum 16 cores. This phenomenon does occur on ZFS- and UFS2 filesystems as well. It is hardly reproducable. I'm experiencing the same thing, except in my case it's most noticeable when writing to a USB flash drive with a FAT32 filesystem. It slows the entire system down, even if the data being written is coming from cache or a memory file system. I don't know if it's related. I'm running 8-STABLE from about 4 December. Regards, Aragon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: immense delayed write to file system (ZFS and UFS2), performance issues
On Mon, 18 Jan 2010 21:41:53 -0500 Garrett Moore garrettmo...@gmail.com wrote about Re: immense delayed write to file system (ZFS and UFS2), performance issues: GM The drives being discussed in my related thread (regarding poor GM performance) are all WD Green drives. I have used wdidle3 to set all GM of my drive timeouts to 5 minutes. I'll see what sort of difference GM this makes for performance. GM Even if it makes no difference to performance, thank you for pointing GM it out GM -- my drives have less than 2,000 hours on them and were all over GM 90,000 load cycles due to this moronic factory setting. Since changing GM the timeout, they haven't parked (which is what I would expect). Thanks for bringing up this topic here. I have drives showing up close to 80 load cycle counts here. Guess it's time for that fix... :-| cu Gerrit ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: immense delayed write to file system (ZFS and UFS2), performance issues
Garrett Moore wrote: The drives being discussed in my related thread (regarding poor performance) are all WD Green drives. I have used wdidle3 to set all of my drive timeouts to 5 minutes. I'll see what sort of difference this makes for performance. Even if it makes no difference to performance, thank you for pointing it out -- my drives have less than 2,000 hours on them and were all over 90,000 load cycles due to this moronic factory setting. Since changing the timeout, they haven't parked (which is what I would expect). You're welcome. I just feel as bad for you as for everyone else who has bought these obviously Windoze optimized harddrives. Unfortunately neither wdidle3 nor an updated firmware is available or functioning on the latest models in the Green series. At least that's what I've read from other people having this issue. WD only claims they don't support Linux and they probably have never heard of FreeBSD. If anyone successfully has fixed their WD15EADS drives this way I'd be interested in hearing from you. One of my drives has 216,000 load cycles accumulated over 8 months. That's one every 2nd minute... and I was hit by the Seagate 7200.11 fiasco too. Running on Samsungs now :-) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: immense delayed write to file system (ZFS and UFS2), performance issues
2010/1/18 Morgan Wesström freebsd-questi...@pp.dyndns.biz O. Hartmann wrote: I realise a strange behaviour of several FreeBSD 8.0-STABLE/amd64 boxes. All boxes have the most recent STABLE. One box is a UP system, two others SMP boxes, one with a Q6600 4-core, another XEON with 2x 4-cores (Dell Poweredge III). Symptome: All boxes have ZFS and UFS2 filesystems. Since two weeks or so, sometimes the I/O performance drops massively when doing 'svn update', 'make world' or even 'make kernel'. It doesn't matter what memory and how many cpu the box has, it get stuck for several seconds and freezing. On the UP box, this is sometimes for 10 - 20 seconds. A very interesting phenomenon is the massively delayed file writing on ZFS filesystems I realise. Editing a file in 'vi' running on one XTerm and having in another Xterminal my shell for compiling this file, it takes sometimes up to 20 seconds to get the file updated after it has been written. It's like having an old, slow NFS connection with long cache delays. These massively delayed file transactions are not necessarely under heavy load, sometimes they occur in a relaxed situation. They seem to occur much more often on the UP box than on the SMP boxes, but this strange phenomenon also occur on the Dell Poweredge II, which has 16GB RAM and summa summarum 16 cores. This phenomenon does occur on ZFS- and UFS2 filesystems as well. It is hardly reproducable. Is there any known issue? Ragrds, Oliver The disks involved don't happen to be Western Digital Green Power disks, do they? The Intelli-Park function in these disks are wrecking havoc with I/O in Linux-land at least, causing massive stalls and iowait through the roof during the 25-30 seconds it takes for the heads to unload after parking. I have two of these disks sitting on my desk now collecting dust... /Morgan ___ freebsd-questi...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ZFS is copy on write, therefore to optimize the write performance it delays writes for a long as possible, upto a set maximum time. It will then flush to the disks. How long this time is depends on how much free ram you have available. Assuming processes are eating up all your ram I would imagine you are hitting the max limit. I'm not sure exactly what its set to on bsd but I know the default on opensolaris is 30s. I think this explains your delayed writes. Not sure what will cause the lock ups though. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: immense delayed write to file system (ZFS and UFS2), performance issues
Gerrit Kühn wrote: Thanks for bringing up this topic here. I have drives showing up close to 80 load cycle counts here. Guess it's time for that fix... :-| Just note that the utility is officially for WD's Raid Edition GP drives and not for the regular consumer models although some users have reported success on using it on those too. /Morgan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: immense delayed write to file system (ZFS and UFS2), performance issues
On Tue, Jan 19, 2010 at 10:28:58AM +0100, Morgan Wesström wrote: Garrett Moore wrote: The drives being discussed in my related thread (regarding poor performance) are all WD Green drives. I have used wdidle3 to set all of my drive timeouts to 5 minutes. I'll see what sort of difference this makes for performance. Even if it makes no difference to performance, thank you for pointing it out -- my drives have less than 2,000 hours on them and were all over 90,000 load cycles due to this moronic factory setting. Since changing the timeout, they haven't parked (which is what I would expect). You're welcome. I just feel as bad for you as for everyone else who has bought these obviously Windoze optimized harddrives. Unfortunately neither wdidle3 nor an updated firmware is available or functioning on the latest models in the Green series. At least that's what I've read from other people having this issue. WD only claims they don't support Linux and they probably have never heard of FreeBSD. No offence intended by this statement, but: the Green drives are specifically intended for workstations. I don't believe in the whole segregation of drive model thing, but the fact of the matter is, the Green drives are variable-RPM and have numerous firmware-level features which intend for them to be used in workstation environments -- that means not constant I/O or heavy workload. Windows has nothing to do with this. If you want a consumer-edition drive that's better tuned for server work, you should really be looking at the WD Caviar Black series or their RE/RE2 series. I have both the Green and Black drives, and I've done my share of benchmarking. Sustained transfer rates on the Black models exceed that of the Greens by almost 20-25MB/sec. Average seek times are slightly lower, and I/O concurrency is handled much better. The Black drives also have a feature called TLER[1], which can be toggled using a utility from Western Digital. Those using these drives in a RAID or ZFS array will be very interested in disabling this feature to ensure quick timeouts from the drive in the case of I/O errors. Other manufacturers have the same feature, just called something else (ex. Samsung's is called CCTL). Now, admittedly WD doesn't give this utility out any more (which is silly), and some people have reported that recent-day (circa mid-to-late 2009) Black drives refuse to let you toggle TLER. The latter claim is absurd -- I purchased 4 Black drives (2 with manufacturing dates of October 2009, and 2 with September 2009) and all of them let me toggle TLER without any problem. Keep in mind you your SATA controller has to be set to non-AHCI mode (sometimes called Enhanced mode) or Compatibility mode (e.g. IDE emulation) for the utility work. If you have qualms/concerns/issues with Western Digital drives or their mentality behind their drives, simply don't buy them. Really. People often ask me (and others) what brand of hard disk is good? and I always tell them the same thing: there's no correct answer. Everyone has their own experience with different vendors, models, etc. [1]: http://en.wikipedia.org/wiki/Time-Limited_Error_Recovery If anyone successfully has fixed their WD15EADS drives this way I'd be interested in hearing from you. One of my drives has 216,000 load cycles accumulated over 8 months. That's one every 2nd minute... and I was hit by the Seagate 7200.11 fiasco too. Running on Samsungs now :-) Aren't Samsung's drives known for firmware bugs/quirks? The documentation associated with smartmontools discusses this quite a bit. This is one reason why I stay away from them. Fujitsu is another vendor I want absolutely nothing to do with (very high failure rates in addition to bad sectors with their SCSI-3 disks at my workplace). -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: immense delayed write to file system (ZFS and UFS2), performance issues
On Tue, 19 Jan 2010 01:57:36 -0800 Jeremy Chadwick free...@jdc.parodius.com wrote about Re: immense delayed write to file system (ZFS and UFS2), performance issues: JC If you want a consumer-edition drive that's better tuned for server JC work, you should really be looking at the WD Caviar Black series or JC their RE/RE2 series. That's exactly what I did. I have WD-RE2 drives here that show exactly this problem (RE2/GP)! The model number is WD1000FYPS-01ZKB0. cu Gerrit ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: immense delayed write to file system (ZFS and UFS2), performance issues
Jeremy Chadwick wrote: No offence intended by this statement, but: the Green drives are specifically intended for workstations. I don't believe in the whole segregation of drive model thing, but the fact of the matter is, the Green drives are variable-RPM and have numerous firmware-level features which intend for them to be used in workstation environments -- that means not constant I/O or heavy workload. Windows has nothing to do with this. No offence taken. You are one of the few highly regarded contributors to this list and I always appreciate the information you share. My comment about Windows was based on the fact that Windows-users don't experience this behaviour. The 8 second Intelli-Park timeout is most probably tuned to the Windows kernel flush period but I can't say for sure. But obviously the load/unload cycle isn't triggered nearly as often on that OS. I just feel frustrated that once again a manufacturer simply ignore the users who chose to run something else on their computers than the products from Redmond. In my case I have several decades worth of experience and knowledge and I have no problem grasping the various technical features and their usefullness. The problem is that I as a consumer have no way of knowing that a feature like this would be incompatible in my environment despite my experience. In my search to track this problem down I sidetracked several times in both filesystem and kernel internals until I finally stumbled over the Intelli-Park feature. It hadn't even crossed my mind that the problem could be related to a hardware feature and that bothers me immensely... but I'll deal with it eventually ;) Aren't Samsung's drives known for firmware bugs/quirks? The documentation associated with smartmontools discusses this quite a bit. This is one reason why I stay away from them. Fujitsu is another vendor I want absolutely nothing to do with (very high failure rates in addition to bad sectors with their SCSI-3 disks at my workplace). I think both you and I know by now that every harddrive manufacturer have their problems with certain models at some point. What surprises me is the total lack of understanding from the manufacturers, most recently the firmware issue of Seagates 7200.11 series where they simply try to ignore the problem. The only professional response I've seen during my career is IBM's replacement of their Deathstar drives many years ago. I accept and understand that a manufacturer now and then makes a bad product but it's how they deal with the situation when it occurs, that decides whether I will ever buy their products again. With Samsung I've completed the full circle and if I run into a problem with them and they don't take their responsibility, well, then I'm not sure what to buy next time. Maybe I should go for Maxtor again... ;-) Regards Morgan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: immense delayed write to file system (ZFS and UFS2), performance issues
On Tue, Jan 19, 2010 at 11:07:24AM +0100, Gerrit Kühn wrote: On Tue, 19 Jan 2010 01:57:36 -0800 Jeremy Chadwick free...@jdc.parodius.com wrote about Re: immense delayed write to file system (ZFS and UFS2), performance issues: JC If you want a consumer-edition drive that's better tuned for server JC work, you should really be looking at the WD Caviar Black series or JC their RE/RE2 series. That's exactly what I did. I have WD-RE2 drives here that show exactly this problem (RE2/GP)! The model number is WD1000FYPS-01ZKB0. I should have been more specific. WD makes RE-series drives which don't have GP applied to them; those are what I was referring to. Here's the current list of Western Digital SATA models out there, sans some earlier revisions. All below drives are 3.5, SATA300, and have their SATA power/signal ports placed to permit hot-swapping in drive carriers unless otherwise noted. Enterprise high-performance class === WD3000GLFS - WD VelociRatpor, 300GB, 16MB, 10Krpm, no-hotswap WD1500HLFS - WD VelociRaptor, 150GB, 16MB, 10Krpm WD3000HLFS - WD VelociRaptor, 300GB, 16MB, 10Krpm WD1500BLFS - WD VelociRaptor, 150GB, 16MB, 10Krpm, 2.5 bare WD3000BLFS - WD VelociRaptor, 300GB, 16MB, 10Krpm, 2.5 bare Enterprise business-critical class WD2502ABYS - WD RE3, 250GB, 16MB, 7200rpm WD3202ABYS - WD RE3, 320GB, 16MB, 7200rpm WD5002ABYS - WD RE3, 500GB, 16MB, 7200rpm WD1002FBYS - WD RE3, 1TB, 32MB, 7200rpm WD7502ABYS - WD RE3, 750GB, 32MB, 7200rpm WD2003FYYS - WD RE4, 2TB, 64MB, 7200rpm Enterprise energy-saving class WD5000ABPS - WD RE2-GP, 500GB, 16MB, variable rpm WD7500AYPS - WD RE2-GP, 750GB, 16MB, variable rpm WD1000FYPS - WD RE2-GP, 1TB, 16MB, variable rpm WD2002FYPS - WD RE4-GP, 2TB, 64MB, variable rpm Desktop class === WD800AAJS - WD Caviar Blue, 80GB, 8MB, 7200rpm WD1600AAJS - WD Caviar Blue, 160GB, 8MB, 7200rpm WD2500AAJS - WD Caviar Blue, 250GB, 8MB, 7200rpm WD3200AAJS - WD Caviar Blue, 320GB, 8MB, 7200rpm WD2500AAKS - WD Caviar Blue, 250GB, 16MB, 7200rpm WD3200AAKS - WD Caviar Blue, 320GB, 16MB, 7200rpm WD5000AAKS - WD Caviar Blue, 500GB, 16MB, 7200rpm WD6400AAKS - WD Caviar Blue, 640GB, 16MB, 7200rpm WD5000AACS - WD Caviar Green, 500GB, 16MB, variable rpm WD6400AACS - WD Caviar Green, 640GB, 16MB, variable rpm WD7500AACS - WD Caviar Green, 750GB, 16MB, variable rpm WD10EACS - WD Caviar Green, 1TB, 16MB, variable rpm WD5000AADS - WD Caviar Green, 500GB, 32MB, variable rpm WD6400AADS - WD Caviar Green, 640GB, 32MB, variable rpm WD7500AADS - WD Caviar Green, 750GB, 32MB, variable rpm WD10EADS - WD Caviar Green, 1TB, 32MB, variable rpm WD15EADS - WD Caviar Green, 1.5TB, 32MB, variable rpm WD20EADS - WD Caviar Green, 2TB, 32MB, variable rpm WD6400AARS - WD Caviar Green, 640GB, 64MB, variable rpm WD8000AARS - WD Caviar Green, 800GB, 64MB, variable rpm WD10EARS - WD Caviar Green, 1TB, 64MB, variable rpm WD15EARS - WD Caviar Green, 1.5TB, 64MB, variable rpm WD20EARS - WD Caviar Green, 2TB, 64MB, variable rpm WD5001AALS - WD Caviar Black, 500GB, 32MB, 7200rpm WD6401AALS - WD Caviar Black, 640GB, 32MB, 7200rpm WD7501AALS - WD Caviar Black, 750GB, 32MB, 7200rpm WD1001FALS - WD Caviar Black, 1TB, 32MB, 7200rpm WD2001FAAS - WD Caviar Black, 2TB, 64MB, 7200rpm So which drive models above are experiencing a continual increase in SMART attribute 193 (Load Cycle Count)? My guess is that some of the WD Caviar Green models, and possibly all of the RE2-GP and RE4-GP models are experiencing this problem. I say some with regards to WD Caviar Green since I have some which do not appear to exhibit the heads/actuator arm moved into the landing/park zone. I'm at work right now, but when I get home I can verify what models I've used which didn't experience this problem, as well as what the manufacturing date and F/W revisions are. I should note I don't have said Green drives in use (I use WD1001FALS drives now). -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: immense delayed write to file system (ZFS and UFS2), performance issues
On Tue, 19 Jan 2010 03:24:49 -0800 Jeremy Chadwick free...@jdc.parodius.com wrote about Re: immense delayed write to file system (ZFS and UFS2), performance issues: JC JC If you want a consumer-edition drive that's better tuned for JC JC server work, you should really be looking at the WD Caviar Black JC JC series or their RE/RE2 series. JC That's exactly what I did. I have WD-RE2 drives here that show JC exactly this problem (RE2/GP)! The model number is WD1000FYPS-01ZKB0. JC I should have been more specific. WD makes RE-series drives which JC don't have GP applied to them; those are what I was referring to. Well, when I bought these drives I was not aware of this issue. Buying a drive intended for 24/7 use in RAID configurations is basically the right idea, I think. From what was written about the GP feature back then I could not anticipate such problems. I would have liked to buy the 2TB drives without GP lately, but they have lead times into April here. So I went for the GP model, which now shows the same problem as the 1TB drive... :-( JC WD1000FYPS - WD RE2-GP, 1TB, 16MB, variable rpm JC WD2002FYPS - WD RE4-GP, 2TB, 64MB, variable rpm JC So which drive models above are experiencing a continual increase in JC SMART attribute 193 (Load Cycle Count)? My guess is that some of the JC WD Caviar Green models, and possibly all of the RE2-GP and RE4-GP JC models are experiencing this problem. I can confirm that the two models above show this problem. Furthermore I can confirm that at least in my setup here this drive type works fine: WD5001ABYS I have some of the RE3 drives sitting around here and will probably try them later. Can anyone here report anything about the fixed firmware from http://support.wdc.com/product/download.asp?groupid=609sid=113lang=en? Does this remedy the problem for the 1TB RE2 drive? JC I say some with regards to WD Caviar Green since I have some which do JC not appear to exhibit the heads/actuator arm moved into the JC landing/park zone. I'm at work right now, but when I get home I can JC verify what models I've used which didn't experience this problem, as JC well as what the manufacturing date and F/W revisions are. I should JC note I don't have said Green drives in use (I use WD1001FALS drives JC now). Thanks for sharing this information. cu Gerrit ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: immense delayed write to file system (ZFS and UFS2), performance issues
On Tue, Jan 19, 2010 at 09:16:41AM +0100, Gerrit K?hn wrote: Thanks for bringing up this topic here. I have drives showing up close to 80 load cycle counts here. Guess it's time for that fix... :-| Device Model: WDC WD10EACS-00ZJB0 Firmware Version: 01.01B01 Serial Number:WD-WCAS [...] 9 Power_On_Hours 17046 193 Load_Cycle_Count 1045512 The above drive is in a raidz of three. The other two drives from that batch have already failed. :( In another system: Device Model: WDC WD10EACS-00D6B0 Firmware Version: 01.01A01 Serial Number:WD-WCAU [...] 9 Power_On_Hours 13111 193 Load_Cycle_Count 7 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: immense delayed write to file system (ZFS and UFS2), performance issues
Emil Mikulic wrote: On Tue, Jan 19, 2010 at 09:16:41AM +0100, Gerrit K?hn wrote: Thanks for bringing up this topic here. I have drives showing up close to 80 load cycle counts here. Guess it's time for that fix... :-| Device Model: WDC WD10EACS-00ZJB0 Firmware Version: 01.01B01 Serial Number:WD-WCAS [...] 9 Power_On_Hours 17046 193 Load_Cycle_Count 1045512 The above drive is in a raidz of three. The other two drives from that batch have already failed. :( Did you RMA the failing drives? Did WD comment the Load_Cycle_Count? /Morgan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: immense delayed write to file system (ZFS and UFS2), performance issues
On Tue, Jan 19, 2010 at 03:24:49AM -0800, Jeremy Chadwick wrote: WD2001FAAS - WD Caviar Black, 2TB, 64MB, 7200rpm Do you mean WD2001FASS? I can't find a WD2001FAAS. Thanks, Gary ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: immense delayed write to file system (ZFS and UFS2), performance issues
On Tue, Jan 19, 2010 at 10:44:59AM -0500, Gary Palmer wrote: On Tue, Jan 19, 2010 at 03:24:49AM -0800, Jeremy Chadwick wrote: WD2001FAAS - WD Caviar Black, 2TB, 64MB, 7200rpm Do you mean WD2001FASS? I can't find a WD2001FAAS. Yup, typo -- bound to be at least one given the amount of data I typed in. :-) Good catch! -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: immense delayed write to file system (ZFS and UFS2), performance issues
Hi, it seems that I'm not experiencing this at all... Jeremy Chadwick wrote: WD10EACS - WD Caviar Green, 1TB, 16MB, variable rpm have one (external HDD, always powered on) Model = WDC WD10EAVS-00D7B1 Firmware Version = 01.01A01 Power_On_Hours 5757 Power_Cycle_Count 75 Load_Cycle_Count127 WD10EADS - WD Caviar Green, 1TB, 32MB, variable rpm have four, got them in Sep/09. one is RMAed right now because it had defective sectors in Dec/09 (surprisingly the first WDC I encountered problems so far). All four are used as a RAID-5 configured with my 3ware 9500-4LP. I don't know if the controller requests data from the drives in a very short period of time. I'm MRTGing some SMART attributes which should at least query the drive every minute. The ata idle feature is not supported at all trough the 3ware controllers. For the remaining 3 drives: Model = WDC WD10EADS-00L5B1 Firmware Version = 01.01A01 Power_On_Hours 2538 Power_Cycle_Count 140 Load_Cycle_Count141 Power_On_Hours 2526 Power_Cycle_Count 133 Load_Cycle_Count134 Power_On_Hours 2490 Power_Cycle_Count 126 Load_Cycle_Count128 So - I'm not experiencing this problem at all but I feel that the drives are reacting more slowly than my previous WD2500KS-00MJB0 are. changing a directory and then typing ls takes some time until the result is displayed... I can live with that but it doesn't feel good And - it is not really something I would call fast - but it saves power :) The 3ware RAID-5 over 4 disks (using the EAVS from above as replacement right now until WDC sends a new drive back): Version 1.96 --Sequential Output-- --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- MachineSize K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP nudel.salatschue 6G89 99 76321 38 29285 21 249 99 111225 33 201.7 13 Latency 106ms 247ms1155ms 63744us 145ms 382ms Version 1.96 --Sequential Create-- Random Create nudel.salatschuesse -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 571 6 + +++ 1095 8 617 6 + +++ 611 5 Latency 523ms 61us 125ms 103ms 87us 159ms -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: immense delayed write to file system (ZFS and UFS2), performance issues
On Tue, 19 Jan 2010, Gerrit Kühn wrote: On Tue, 19 Jan 2010 03:24:49 -0800 Jeremy Chadwick free...@jdc.parodius.com wrote about Re: immense delayed write to file system (ZFS and UFS2), performance issues: JC JC If you want a consumer-edition drive that's better tuned for JC JC server work, you should really be looking at the WD Caviar Black JC JC series or their RE/RE2 series. JC That's exactly what I did. I have WD-RE2 drives here that show JC exactly this problem (RE2/GP)! The model number is WD1000FYPS-01ZKB0. JC I should have been more specific. WD makes RE-series drives which JC don't have GP applied to them; those are what I was referring to. Well, when I bought these drives I was not aware of this issue. Buying a drive intended for 24/7 use in RAID configurations is basically the right idea, I think. From what was written about the GP feature back then I could not anticipate such problems. I would have liked to buy the 2TB drives without GP lately, but they have lead times into April here. So I went for the GP model, which now shows the same problem as the 1TB drive... :-( JC WD1000FYPS - WD RE2-GP, 1TB, 16MB, variable rpm JC WD2002FYPS - WD RE4-GP, 2TB, 64MB, variable rpm JC So which drive models above are experiencing a continual increase in JC SMART attribute 193 (Load Cycle Count)? My guess is that some of the JC WD Caviar Green models, and possibly all of the RE2-GP and RE4-GP JC models are experiencing this problem. I can confirm that the two models above show this problem. Furthermore I can confirm that at least in my setup here this drive type works fine: WD5001ABYS I have some of the RE3 drives sitting around here and will probably try them later. I specifically bought RE3 drives recently because of the whole fiasco regarding raid compatibility. I paid about $20 each more for these in the interest of things just working, since I saw some debate about whether or not the TLER setting can be flipped on the non-RAID drives. FWIW, 4 1TB RE3's in a zfs raidz (an excerpt from bonnie++, block read/write 8G on 4G RAM): Write Read K/sec K/sec 123207 142749 Both zfs and these drives kind of surprised me, that seems pretty good for software raid with parity... Seagate is currently on my blacklist after we had a large number of them fail a year or two in the past year or two. I've had good luck so far with WD RE2 and RE3 drives. I'll probably give seagate another shot in a year or two. C Can anyone here report anything about the fixed firmware from http://support.wdc.com/product/download.asp?groupid=609sid=113lang=en? Does this remedy the problem for the 1TB RE2 drive? JC I say some with regards to WD Caviar Green since I have some which do JC not appear to exhibit the heads/actuator arm moved into the JC landing/park zone. I'm at work right now, but when I get home I can JC verify what models I've used which didn't experience this problem, as JC well as what the manufacturing date and F/W revisions are. I should JC note I don't have said Green drives in use (I use WD1001FALS drives JC now). Thanks for sharing this information. cu Gerrit ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: immense delayed write to file system (ZFS and UFS2), performance issues
Morgan Wesström wrote: Garrett Moore wrote: The drives being discussed in my related thread (regarding poor performance) are all WD Green drives. I have used wdidle3 to set all of my drive timeouts to 5 minutes. I'll see what sort of difference this makes for performance. Even if it makes no difference to performance, thank you for pointing it out -- my drives have less than 2,000 hours on them and were all over 90,000 load cycles due to this moronic factory setting. Since changing the timeout, they haven't parked (which is what I would expect). You're welcome. I just feel as bad for you as for everyone else who has bought these obviously Windoze optimized harddrives. Unfortunately neither wdidle3 nor an updated firmware is available or functioning on the latest models in the Green series. At least that's what I've read from other people having this issue. WD only claims they don't support Linux and they probably have never heard of FreeBSD. If anyone successfully has fixed their WD15EADS drives this way I'd be interested in hearing from you. One of my drives has 216,000 load cycles accumulated over 8 months. That's one every 2nd minute... and I was hit by the Seagate 7200.11 fiasco too. Running on Samsungs now :-) Keeping this python script running prevents Load_Cycle_Count from incrementing on my WD15EADS drives by forcing a write every 5 seconds (2 drive zfs mirror pool, average of 2 load cycles per minute when the script is not running): import time,os mypool = /zfspool # ^^ Change to your pool! fname = os.path.join(mypool, wd_green_anti_idle.pyfile) c = 0 f = open(fname, w) while True: if c == 100: f.close() f = open(fname, w) c = 0 c += 1 time.sleep(5) f.write(a) f.flush() os.fsync(f.fileno()) -- Erik ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: immense delayed write to file system (ZFS and UFS2), performance issues
2010/1/19 Daniel O'Connor docon...@gsoft.com.au On Tue, 19 Jan 2010, Morgan Wesström wrote: The disks involved don't happen to be Western Digital Green Power disks, do they? The Intelli-Park function in these disks are wrecking havoc with I/O in Linux-land at least, causing massive stalls and iowait through the roof during the 25-30 seconds it takes for the heads to unload after parking. I have two of these disks sitting on my desk now collecting dust... There's this.. http://www.silentpcreview.com/Terabyte_Drive_Fix and you can get the tool at.. http://home.arcor.de/ghostadmin/wdidle3_1_00.zip I am planning to try this out tonight.. I just put my WD5000AACS (it has the same problem) in my Windows PC and did a SMART drive quick self-test with the WD utility (Data Lifeguard Diagnostic for Windows). I also tried this Idle Mode Updade Utility but it did not attach to my drive. So i put it back to my FreeBSD box (8.0-Stable) and recognized that I am not able to decrypt it anymore with geli. It keeps telling: # geli attach -k /etc/keys/keyfile /dev/ada0 geli: Cannot read metadata from /dev/ada0: Invalid argument. A geli backup command failed with geli: MD5 hash mismatch: not a geli provider? I think Windows has messed up something on my disk, but a fdisk dump looks still the same as before: # fdisk /dev/ada0 *** Working on device /dev/ada0 *** parameters extracted from in-core disklabel are: cylinders=969021 heads=16 sectors/track=63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=969021 heads=16 sectors/track=63 (1008 blks/cyl) fdisk: invalid fdisk partition table found Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 976773105 (476939 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 316/ head 15/ sector 63 The data for partition 2 is: UNUSED The data for partition 3 is: UNUSED The data for partition 4 is: UNUSED Are there any things I could try or is all my data gone? Thanks in advance ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: immense delayed write to file system (ZFS and UFS2), performance issues
On 01/18/10 21:34, � wrote: O. Hartmann wrote: I realise a strange behaviour of several FreeBSD 8.0-STABLE/amd64 boxes. All boxes have the most recent STABLE. One box is a UP system, two others SMP boxes, one with a Q6600 4-core, another XEON with 2x 4-cores (Dell Poweredge III). Symptome: All boxes have ZFS and UFS2 filesystems. Since two weeks or so, sometimes the I/O performance drops massively when doing 'svn update', 'make world' or even 'make kernel'. It doesn't matter what memory and how many cpu the box has, it get stuck for several seconds and freezing. On the UP box, this is sometimes for 10 - 20 seconds. A very interesting phenomenon is the massively delayed file writing on ZFS filesystems I realise. Editing a file in 'vi' running on one XTerm and having in another Xterminal my shell for compiling this file, it takes sometimes up to 20 seconds to get the file updated after it has been written. It's like having an old, slow NFS connection with long cache delays. These massively delayed file transactions are not necessarely under heavy load, sometimes they occur in a relaxed situation. They seem to occur much more often on the UP box than on the SMP boxes, but this strange phenomenon also occur on the Dell Poweredge II, which has 16GB RAM and summa summarum 16 cores. This phenomenon does occur on ZFS- and UFS2 filesystems as well. It is hardly reproducable. Is there any known issue? Ragrds, Oliver The disks involved don't happen to be Western Digital Green Power disks, do they? The Intelli-Park function in these disks are wrecking havoc with I/O in Linux-land at least, causing massive stalls and iowait through the roof during the 25-30 seconds it takes for the heads to unload after parking. I have two of these disks sitting on my desk now collecting dust... /Morgan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org The disks in question are indeed WD on one box, but they are all Caviar Black and they performed well months ago with the very same hardware and an earlier FreeBSD 8 version. The other boxes in questions do have a set of mixed type, Seagate, WD, Samsung (mostly Samsung F1 types). We do not use 'Green' drives, due to every box acts as a server and we found green-disks, even from WD, too slow. Oliver ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: immense delayed write to file system (ZFS and UFS2), performance issues
On 01/19/10 10:09, krad wrote: 2010/1/18 Morgan Wesstr�mfreebsd-questi...@pp.dyndns.biz O. Hartmann wrote: I realise a strange behaviour of several FreeBSD 8.0-STABLE/amd64 boxes. All boxes have the most recent STABLE. One box is a UP system, two others SMP boxes, one with a Q6600 4-core, another XEON with 2x 4-cores (Dell Poweredge III). Symptome: All boxes have ZFS and UFS2 filesystems. Since two weeks or so, sometimes the I/O performance drops massively when doing 'svn update', 'make world' or even 'make kernel'. It doesn't matter what memory and how many cpu the box has, it get stuck for several seconds and freezing. On the UP box, this is sometimes for 10 - 20 seconds. A very interesting phenomenon is the massively delayed file writing on ZFS filesystems I realise. Editing a file in 'vi' running on one XTerm and having in another Xterminal my shell for compiling this file, it takes sometimes up to 20 seconds to get the file updated after it has been written. It's like having an old, slow NFS connection with long cache delays. These massively delayed file transactions are not necessarely under heavy load, sometimes they occur in a relaxed situation. They seem to occur much more often on the UP box than on the SMP boxes, but this strange phenomenon also occur on the Dell Poweredge II, which has 16GB RAM and summa summarum 16 cores. This phenomenon does occur on ZFS- and UFS2 filesystems as well. It is hardly reproducable. Is there any known issue? Ragrds, Oliver The disks involved don't happen to be Western Digital Green Power disks, do they? The Intelli-Park function in these disks are wrecking havoc with I/O in Linux-land at least, causing massive stalls and iowait through the roof during the 25-30 seconds it takes for the heads to unload after parking. I have two of these disks sitting on my desk now collecting dust... /Morgan ___ freebsd-questi...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ZFS is copy on write, therefore to optimize the write performance it delays writes for a long as possible, upto a set maximum time. It will then flush to the disks. How long this time is depends on how much free ram you have available. Assuming processes are eating up all your ram I would imagine you are hitting the max limit. I'm not sure exactly what its set to on bsd but I know the default on opensolaris is 30s. I think this explains your delayed writes. Not sure what will cause the lock ups though. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org This could end in a bad situation, where one process writes a files, say with some arbitrary stuff and another successing process is intended to read this file. even if the processes are run serial, those 'delays' could break the chain! The delay situation in a development environment is harsh, but in other circumstances it could develop very bad. I see this strange behaviour now for several weeks, something essential has changed in the code, I guess. On UP boxes the situation is worse sometimes, on SMp boxes with lots of RAM ( 8 and 16 GB and 4 or 8 CPU cores) it is still bad. I have a server that acts as a 'rsync' backup system gathering data from satellite servers from time to time. Since this problem of slowness occured, this 4-core 8 gig RAM box crawls for minutes. Even when X11 is disabled working on console is 'bumpy': terminal out slows down, mouse pointer jumps etc.As I wrote, the same on a 8 core/16 gig box, but not that harsh. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: immense delayed write to file system (ZFS and UFS2), performance issues
--On Wednesday, January 20, 2010 1:16 AM +0100 O. Hartmann ohart...@mail.zedat.fu-berlin.de wrote: This could end in a bad situation, where one process writes a files, say with some arbitrary stuff and another successing process is intended to read this file. even if the processes are run serial, those 'delays' could break the chain! The delay situation in a development environment is harsh, but in other circumstances it could develop very bad. The read occurs from the write cache. Thus the reader would see the writers data (given the usual POSIX semantics). ZFS delayed writes are handled by the cache/ZIL layers, reads and writes go through these layers. The ZIL is normally written very quickly. ZFS actually (through the ZIL) has better journalling and recovery semantics than most journalling filesystems. I see this strange behaviour now for several weeks, something essential has changed in the code, I guess. On UP boxes the situation is worse sometimes, on SMp boxes with lots of RAM ( 8 and 16 GB and 4 or 8 CPU cores) it is still bad. I have a server that acts as a 'rsync' backup system gathering data from satellite servers from time to time. Since this problem of slowness occured, this 4-core 8 gig RAM box crawls for minutes. Even when X11 is disabled working on console is 'bumpy': terminal out slows down, mouse pointer jumps etc.As I wrote, the same on a 8 core/16 gig box, but not that harsh. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: immense delayed write to file system (ZFS and UFS2), performance issues
On Mon, Jan 18, 2010 at 09:13:52PM +0100, O. Hartmann wrote: I realise a strange behaviour of several FreeBSD 8.0-STABLE/amd64 boxes. All boxes have the most recent STABLE. One box is a UP system, two others SMP boxes, one with a Q6600 4-core, another XEON with 2x 4-cores (Dell Poweredge III). Symptome: All boxes have ZFS and UFS2 filesystems. Since two weeks or so, sometimes the I/O performance drops massively when doing 'svn update', 'make world' or even 'make kernel'. It doesn't matter what memory and how many cpu the box has, it get stuck for several seconds and freezing. On the UP box, this is sometimes for 10 - 20 seconds. A very interesting phenomenon is the massively delayed file writing on ZFS filesystems I realise. Editing a file in 'vi' running on one XTerm and having in another Xterminal my shell for compiling this file, it takes sometimes up to 20 seconds to get the file updated after it has been written. It's like having an old, slow NFS connection with long cache delays. These massively delayed file transactions are not necessarely under heavy load, sometimes they occur in a relaxed situation. They seem to occur much more often on the UP box than on the SMP boxes, but this strange phenomenon also occur on the Dell Poweredge II, which has 16GB RAM and summa summarum 16 cores. This phenomenon does occur on ZFS- and UFS2 filesystems as well. It is hardly reproducable. Possibly this is an extreme example of what Garrett Moore et al have been discussing recently? http://lists.freebsd.org/pipermail/freebsd-stable/2010-January/053845.html You might try the force-swap-out approach here to find out if what you're seeing is identical: http://lists.freebsd.org/pipermail/freebsd-stable/2010-January/053949.html -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: immense delayed write to file system (ZFS and UFS2), performance issues
O. Hartmann wrote: I realise a strange behaviour of several FreeBSD 8.0-STABLE/amd64 boxes. All boxes have the most recent STABLE. One box is a UP system, two others SMP boxes, one with a Q6600 4-core, another XEON with 2x 4-cores (Dell Poweredge III). Symptome: All boxes have ZFS and UFS2 filesystems. Since two weeks or so, sometimes the I/O performance drops massively when doing 'svn update', 'make world' or even 'make kernel'. It doesn't matter what memory and how many cpu the box has, it get stuck for several seconds and freezing. On the UP box, this is sometimes for 10 - 20 seconds. A very interesting phenomenon is the massively delayed file writing on ZFS filesystems I realise. Editing a file in 'vi' running on one XTerm and having in another Xterminal my shell for compiling this file, it takes sometimes up to 20 seconds to get the file updated after it has been written. It's like having an old, slow NFS connection with long cache delays. These massively delayed file transactions are not necessarely under heavy load, sometimes they occur in a relaxed situation. They seem to occur much more often on the UP box than on the SMP boxes, but this strange phenomenon also occur on the Dell Poweredge II, which has 16GB RAM and summa summarum 16 cores. This phenomenon does occur on ZFS- and UFS2 filesystems as well. It is hardly reproducable. Is there any known issue? Ragrds, Oliver The disks involved don't happen to be Western Digital Green Power disks, do they? The Intelli-Park function in these disks are wrecking havoc with I/O in Linux-land at least, causing massive stalls and iowait through the roof during the 25-30 seconds it takes for the heads to unload after parking. I have two of these disks sitting on my desk now collecting dust... /Morgan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: immense delayed write to file system (ZFS and UFS2), performance issues
On Tue, 19 Jan 2010, Morgan Wesström wrote: The disks involved don't happen to be Western Digital Green Power disks, do they? The Intelli-Park function in these disks are wrecking havoc with I/O in Linux-land at least, causing massive stalls and iowait through the roof during the 25-30 seconds it takes for the heads to unload after parking. I have two of these disks sitting on my desk now collecting dust... There's this.. http://www.silentpcreview.com/Terabyte_Drive_Fix and you can get the tool at.. http://home.arcor.de/ghostadmin/wdidle3_1_00.zip I am planning to try this out tonight.. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
Re: immense delayed write to file system (ZFS and UFS2), performance issues
The drives being discussed in my related thread (regarding poor performance) are all WD Green drives. I have used wdidle3 to set all of my drive timeouts to 5 minutes. I'll see what sort of difference this makes for performance. Even if it makes no difference to performance, thank you for pointing it out -- my drives have less than 2,000 hours on them and were all over 90,000 load cycles due to this moronic factory setting. Since changing the timeout, they haven't parked (which is what I would expect). On Mon, Jan 18, 2010 at 9:20 PM, Daniel O'Connor docon...@gsoft.com.auwrote: On Tue, 19 Jan 2010, Morgan Wesström wrote: The disks involved don't happen to be Western Digital Green Power disks, do they? The Intelli-Park function in these disks are wrecking havoc with I/O in Linux-land at least, causing massive stalls and iowait through the roof during the 25-30 seconds it takes for the heads to unload after parking. I have two of these disks sitting on my desk now collecting dust... There's this.. http://www.silentpcreview.com/Terabyte_Drive_Fix and you can get the tool at.. http://home.arcor.de/ghostadmin/wdidle3_1_00.zip I am planning to try this out tonight.. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: immense delayed write to file system (ZFS and UFS2), performance issues
On Tue, 19 Jan 2010, Garrett Moore wrote: The drives being discussed in my related thread (regarding poor performance) are all WD Green drives. I have used wdidle3 to set all of my drive timeouts to 5 minutes. I'll see what sort of difference this makes for performance. Even if it makes no difference to performance, thank you for pointing it out -- my drives have less than 2,000 hours on them and were all over 90,000 load cycles due to this moronic factory setting. Since changing the timeout, they haven't parked (which is what I would expect). Mine had 65k or so, except one which only had 66.. Very odd! -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
