Re: Disk I/O problem in 4.3-BETA
First off, some disk caches are getting 10megs, that's a lot of potnetial seeking after loosing power depending on the cache contents... I've heard that most modern drives reserve a contiguous area of the disk the size of the cache near where the heads park to dump any cache contents on power outage. This avoids most if not all seeking. When the disk powers up again, the reserve track is read and the transactions are written to the correct locations. Any disk that does this should be safe to use with write caching enabled. As some one who has spent some time working with disk drive manufactures in the far past all sorts of work is done to make sure that the write cache is not a failure mechanism for lost data. Some of the designs include things like using the spindle motor as a generator and the inertia of the platters to drive it to insure the drive has adaquate power for a long enough period to flush any cached data. Other things done are in non-segmented write caches is to only cache write data for the current track (this is actually where the write cache does most of its good) and always flush it before doing any seek. Only broken WC designs loose data in a power out sitation. There are many broken designs out there. There are also many that work perfectly. The general tell tell on this is what state the WCE bit is in when the drive comes from the factory. Those manufactures who have good designs tend to ship with WCE on, those that tend to loose data always ship with WCE off. With the wonderful breakthroughs in supercapacitors it should now be possible to have some very large caches. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Disk I/O problem in 4.3-BETA
Alfred Perlstein: * Kevin Oberman [EMAIL PROTECTED] [010312 13:46] wrote: How serious is the possible corruption issue, anyway. The loss in performance is pretty drastic although it may be that dd is an especially bad case, but I really don't like to corrupt my disks, either. If basically running with blind write caching turned on is akin to running your filesystem in async mode. This is because write caching gives the drive license to lie about completing a write, the various ordering of writes are effectively bypassed. If you crash without these dependancies actually written to the disk, when you come back up you have a good chance of losing large portions of your filesystem. I'd say this is a bit too pessimistic. There is a fundamental difference between softupdates and ATA write-cacheing: Softupdates holds the async data in main RAM while ATA write-cacheing already has it in the (cache memory of the) disk device. Obviously a power outage would affect both situations in a similar way. But during just an operating system crash (assuming power stays up), one should be better off with ATA write-cacheing, as the disk should be able to dump the data from the cache chips to the physical medium. With softupdates async data is just lost. Generally I'd say it's not a bad idea to have write caching on the disk enabled - assuming that it is decently implemented. BTW, don't SCSI disks use write cacheing as well? :-) Just my 2, Helge To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Disk I/O problem in 4.3-BETA
* Helge Oldach [EMAIL PROTECTED] [010313 00:48] wrote: Alfred Perlstein: * Kevin Oberman [EMAIL PROTECTED] [010312 13:46] wrote: How serious is the possible corruption issue, anyway. The loss in performance is pretty drastic although it may be that dd is an especially bad case, but I really don't like to corrupt my disks, either. If basically running with blind write caching turned on is akin to running your filesystem in async mode. This is because write caching gives the drive license to lie about completing a write, the various ordering of writes are effectively bypassed. If you crash without these dependancies actually written to the disk, when you come back up you have a good chance of losing large portions of your filesystem. I'd say this is a bit too pessimistic. There is a fundamental difference between softupdates and ATA write-cacheing: Softupdates holds the async data in main RAM while ATA write-cacheing already has it in the (cache memory of the) disk device. Obviously a power outage would affect both situations in a similar way. But during just an operating system crash (assuming power stays up), one should be better off with ATA write-cacheing, as the disk should be able to dump the data from the cache chips to the physical medium. With softupdates async data is just lost. Generally I'd say it's not a bad idea to have write caching on the disk enabled - assuming that it is decently implemented. BTW, don't SCSI disks use write cacheing as well? :-) I'm pretty sure you're wrong. I'm not 100% certain, but many people working with embedded systems have explained to me that it's no longer safe to assume that write cached data will be sync'd to the disk's media at crash time. First off, some disk caches are getting 10megs, that's a lot of potnetial seeking after loosing power depending on the cache contents... (Also, Matt Dillon wrote how some disks can hold data in the write cache for indefinite amounts of time) Basically, from what's been explained to me, modern disks only retain enough charge/momentum to park (retract) the disk heads when a power outtage occurs, not to write out the cache contents. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Disk I/O problem in 4.3-BETA
Alfred Perlstein: * Helge Oldach [EMAIL PROTECTED] [010313 00:48] wrote: Alfred Perlstein: If basically running with blind write caching turned on is akin to running your filesystem in async mode. This is because write caching gives the drive license to lie about completing a write, the various ordering of writes are effectively bypassed. If you crash without these dependancies actually written to the disk, when you come back up you have a good chance of losing large portions of your filesystem. I'd say this is a bit too pessimistic. There is a fundamental difference between softupdates and ATA write-cacheing: Softupdates holds the async data in main RAM while ATA write-cacheing already has it in the (cache memory of the) disk device. Obviously a power outage would affect both situations in a similar way. But during just an operating system crash (assuming power stays up), one should be better off with ATA write-cacheing, as the disk should be able to dump the data from the cache chips to the physical medium. With softupdates async data is just lost. Generally I'd say it's not a bad idea to have write caching on the disk enabled - assuming that it is decently implemented. BTW, don't SCSI disks use write cacheing as well? :-) I'm pretty sure you're wrong. I think you misunderstood my argument. Agreed, there is practically no difference in the damage done to softupdates versus write-cacheing during a power outage. But there should be a difference when the OS dies away while power stays up. The OS dying away means that the disk has lots of time to spill out the cached data to the physical medium as it's no longer banged at high data rates by the host. So at least in theory we should be better off in this situation. I'm not 100% certain, but many people working with embedded systems have explained to me that it's no longer safe to assume that write cached data will be sync'd to the disk's media at crash time. That may be correct. But then this breaks my naive understanding of "write caching"... And again: Isn't write-cacheing turned on on SCSI disks? :-) Helge To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Disk I/O problem in 4.3-BETA
Helge Oldach [EMAIL PROTECTED] types: Generally I'd say it's not a bad idea to have write caching on the disk enabled - assuming that it is decently implemented. BTW, don't SCSI disks use write cacheing as well? :-) Yes, they do. And it's recommended that you turn it off if you turn on softupdates. The driver doesn't do it for you, though. I'd be interested to know details about why softupdates makes it more critical to have write caching off. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Disk I/O problem in 4.3-BETA
* Helge Oldach [EMAIL PROTECTED] [010313 01:07] wrote: Alfred Perlstein: * Helge Oldach [EMAIL PROTECTED] [010313 00:48] wrote: Alfred Perlstein: If basically running with blind write caching turned on is akin to running your filesystem in async mode. This is because write caching gives the drive license to lie about completing a write, the various ordering of writes are effectively bypassed. If you crash without these dependancies actually written to the disk, when you come back up you have a good chance of losing large portions of your filesystem. I'd say this is a bit too pessimistic. There is a fundamental difference between softupdates and ATA write-cacheing: Softupdates holds the async data in main RAM while ATA write-cacheing already has it in the (cache memory of the) disk device. Obviously a power outage would affect both situations in a similar way. But during just an operating system crash (assuming power stays up), one should be better off with ATA write-cacheing, as the disk should be able to dump the data from the cache chips to the physical medium. With softupdates async data is just lost. Generally I'd say it's not a bad idea to have write caching on the disk enabled - assuming that it is decently implemented. BTW, don't SCSI disks use write cacheing as well? :-) I'm pretty sure you're wrong. I think you misunderstood my argument. Agreed, there is practically no difference in the damage done to softupdates versus write-cacheing during a power outage. huh? I'm confused about "softupdates versus write-cacheing". But there should be a difference when the OS dies away while power stays up. The OS dying away means that the disk has lots of time to spill out the cached data to the physical medium as it's no longer banged at high data rates by the host. So at least in theory we should be better off in this situation. No we shouldn't! Either way we should have a consistant filesystem. I'm not 100% certain, but many people working with embedded systems have explained to me that it's no longer safe to assume that write cached data will be sync'd to the disk's media at crash time. That may be correct. But then this breaks my naive understanding of "write caching"... And again: Isn't write-cacheing turned on on SCSI disks? :-) It's suggested that it be turned off, see Justin's answers to my previous questions. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Disk I/O problem in 4.3-BETA
* Mike Meyer [EMAIL PROTECTED] [010313 01:10] wrote: Helge Oldach [EMAIL PROTECTED] types: Generally I'd say it's not a bad idea to have write caching on the disk enabled - assuming that it is decently implemented. BTW, don't SCSI disks use write cacheing as well? :-) Yes, they do. And it's recommended that you turn it off if you turn on softupdates. The driver doesn't do it for you, though. Oh great... Perhaps the disk guru's can add some notes to the sfotupdates docco about this? Or did I just miss this? I'd be interested to know details about why softupdates makes it more critical to have write caching off. It's always critical to have write caching turned off to ensure filesystem consistancy during an outtage. Having write caching on is like having the disk ignore _any_ filesystem's attempt to do softupdates/logging/delayed-order-writes because the disk _lies_ to the OS about when a write is safely on the disk. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Disk I/O problem in 4.3-BETA
Pete French writes: All very interesting, but a small point has been forgotten hasnt it ? The way I read this thread is that until recentlly write-caching was enabled by default and has now been disabled (hence the original obseravtion of disc performance dropping). I havent noticed that FreeBSD has a bad reputation for loss of data in the event of am power outage, and my own experience backs this up. As so many people appear to have been running it this way by default until now you might have though that if it were a serious problem in reality then people would have noticed by now ? Well, I am an ex-Linux user who got fed up with Linux trashing my disk 3 times one week. Each time (kernel panics) the damage was bad enough fsck (e2fsck?) deleted a lot of critical files making a wipe/reinstall the fastest way back to a running system. This was shortly after the release of FreeBSD 2.0.0. Remember it well because that is when I became a FreeBSD user. Hmm, probably 6 years ago this month. Have watched Linux from "outside" since then. Noticed I was not the only one losing data. From what I've seen the Linux solution was not to to fix a faulty design but to hack it until it doesn't lose as much. Linux was/is very proud of their ext2fs speed. Clearly at the expense of reliability. Oddly enough that machine got 600k Bytes/sec thruput on Linux, but 900k Bytes/sec on FreeBSD 2.0.0-RELEASE. 240 MB Western Digital IDE drive. IMO the most reliable settings are the correct thing to do in spite of simpleminded magazine authors who will "do a shootout" of Linux vs. FreeBSD using only the stock settings. -- David Kelly N4HHE, [EMAIL PROTECTED] = The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
