Flushing file writes to disk with 100% reliability
in [Unix Programming]
|
Prev: Learn about proxy sites and how to use them to open blocked sites unlimited downloads from RapidShare and megaupload and increase the speed of the Internet with new sites for free
Next: How reliable are named pipes?
From: Peter Olcott on 21 Apr 2010 14:39 "Joe Beanfish" <joe(a)nospam.duh> wrote in message news:hqnetl$bu8(a)news.thunderstone.com... > On 04/20/10 14:06, Peter Olcott wrote: >> "Joe Beanfish"<joe(a)nospam.duh> wrote in message >> Some drives might not even be smart enough to flush their >> buffers even when UPS kicks in. I guess that you could >> force >> a buffer flush for every drive by simply writing a file >> larger than the buffer. If you make sure that this file >> is >> not fragmented, it might even be fast enough to do this >> after every transaction. >> >> Obviously the best way to do this would be to have a >> drive >> that correctly implements some sort of "Flush Cache" >> command >> such as the ATA command. > > You're missing my point. Reliable power can eliminate the > need to > flush cache thereby saving a lot of hardware specific > headaches and > keeping the speed high. It's not like the cache will sit > unwritten > for days or even hours. An orderly shutdown when the UPS > nears death > is all that's needed. > That may be good enough for my purposes. Some respondents say that is not good enough. I could imagine that this might not be good enough for banking. > OTOH if you're going to be paranoid about every > possibility don't > ignore the possibility of flushing your cache onto a bad > sector that > won't read back. Do you have data redundancy in your plan? That part is easy, RAID handles this.
From: Scott Lurndal on 21 Apr 2010 15:41 "Ersek, Laszlo" <lacos(a)caesar.elte.hu> writes: >On Wed, 21 Apr 2010, Scott Lurndal wrote: > >> Wikipedia? How about calling up [the vendor] and asking their opinion? > >While Wikipedia is oftentimes not much better than folklore, I'm not sure >if the vendor (any vendor) could withstand its urge to provide padded >stats. Secondly, I'm not sure if anybody would talk to me from [big >vendor] if I wanted to buy eg. two pieces of hardware. I guess I'm spoiled - I just returned from the Intel Roadmap Update Meeting (unfortunately, an NDA event). > >My suggestion would be researching tomshardware.com, phoronix.com and >anandtech.com, for the caliber in question. I suspect that the folks for whom the information is most interesting have access to the relevent manufacturers directly. I'd point Peter here: http://en.wikipedia.org/wiki/NonStop as a starting point for some of the difficulties inherent in building a service that doesn't fail (with L5 (i.e. 5 nines) reliability). A PPOE patented some of this technology, and I've four patents myself on handling faults in distributed systems (specifically keeping the process directory consistent). scott
From: robertwessel2 on 21 Apr 2010 17:10 On Apr 21, 1:39 pm, "Peter Olcott" <NoS...(a)OCR4Screen.com> wrote: > "Joe Beanfish" <j...(a)nospam.duh> wrote in message > > news:hqnetl$bu8(a)news.thunderstone.com... > > > > > > > On 04/20/10 14:06, Peter Olcott wrote: > >> "Joe Beanfish"<j...(a)nospam.duh> wrote in message > >> Some drives might not even be smart enough to flush their > >> buffers even when UPS kicks in. I guess that you could > >> force > >> a buffer flush for every drive by simply writing a file > >> larger than the buffer. If you make sure that this file > >> is > >> not fragmented, it might even be fast enough to do this > >> after every transaction. > > >> Obviously the best way to do this would be to have a > >> drive > >> that correctly implements some sort of "Flush Cache" > >> command > >> such as the ATA command. > > > You're missing my point. Reliable power can eliminate the > > need to > > flush cache thereby saving a lot of hardware specific > > headaches and > > keeping the speed high. It's not like the cache will sit > > unwritten > > for days or even hours. An orderly shutdown when the UPS > > nears death > > is all that's needed. > > That may be good enough for my purposes. Some respondents > say that is not good enough. I could imagine that this might > not be good enough for banking. > > > OTOH if you're going to be paranoid about every > > possibility don't > > ignore the possibility of flushing your cache onto a bad > > sector that > > won't read back. Do you have data redundancy in your plan? > > That part is easy, RAID handles this. Depending on your level of paranoia, low end RAID often handles failed writes less well that you might hope. A system failure at an inopportune moment can leave inconsistent data on the RAID blocks in a stripe (simple example: a mirrored pair of drive, the write to the first drive happens, the write tot the second does not - there's no way to tell which version of the sector is actually correct). High end storage arrays tend to include timestamps in the written blocks, and often log updates to a separate device as well, and do read-after- write verification before really letting go of the log info (which is there for after the crash). The point is not that you necessarily need the reliability features of a high end storage array (that depends on your application, of course), but that lost on-drive cache is hardly the only way to lose data in a small array. And if it's that crucial to not lose data, you really need to be looking at a higher level solution. Perhaps some form of multi-site clustering - some (higher end) databases can run in a distributed mode, where the commit of a transaction isn't done until both sites have the change committed. The following is a DB2 oriented (vendor) whitepaper that has a nice discussion of some of the general options. http://www.ibm.com/developerworks/data/library/techarticle/0310melnyk/0310melnyk.html
From: Peter Olcott on 21 Apr 2010 18:19 <robertwessel2(a)yahoo.com> wrote in message news:82f24560-545c-4290-9760-be22bc1c1e9c(a)r18g2000yqd.googlegroups.com... On Apr 21, 1:39 pm, "Peter Olcott" <NoS...(a)OCR4Screen.com> wrote: > "Joe Beanfish" <j...(a)nospam.duh> wrote in message > > That may be good enough for my purposes. Some respondents > say that is not good enough. I could imagine that this > might > not be good enough for banking. > > > OTOH if you're going to be paranoid about every > > possibility don't > > ignore the possibility of flushing your cache onto a bad > > sector that > > won't read back. Do you have data redundancy in your > > plan? > > That part is easy, RAID handles this. --Depending on your level of paranoia, low end RAID often handles failed --writes less well that you might hope. A system failure at an --inopportune moment can leave inconsistent data on the RAID blocks in a --stripe (simple example: a mirrored pair of drive, the write to the --first drive happens, the write tot the second does not - there's no --way to tell which version of the sector is actually correct). High --end storage arrays tend to include timestamps in the written blocks, --and often log updates to a separate device as well, and do read-after- --write verification before really letting go of the log info (which is --there for after the crash). --The point is not that you necessarily need the reliability features of --a high end storage array (that depends on your application, of --course), but that lost on-drive cache is hardly the only way to lose --data in a small array. And if it's that crucial to not lose data, you --really need to be looking at a higher level solution. Perhaps some --form of multi-site clustering - some (higher end) databases can run in --a distributed mode, where the commit of a transaction isn't done until --both sites have the change committed. The following is a DB2 oriented --(vendor) whitepaper that has a nice discussion of some of the general --options. http://www.ibm.com/developerworks/data/library/techarticle/0310melnyk/0310melnyk.html The most cost-effective way for me to greatly increase my reliability is to provide transaction by transaction offsite backup of each transaction. The way that I would do this is to send every monetary transaction to another web application that has the sole purpose of archiving these transactions. I would not need a high end database that can run in distributed mode, I would only need a web application that can append a few bytes to a file with these bytes coming through HTTP.
From: David Schwartz on 21 Apr 2010 18:34
On Apr 21, 3:19 pm, "Peter Olcott" <NoS...(a)OCR4Screen.com> wrote: > I would not need a high end database that can run in > distributed mode, I would only need a web application that > can append a few bytes to a file with these bytes coming > through HTTP. Yep. Just make sure your web server is designed not to send an acknowledgment unless it is sure it has the transaction information. And do not allow the computer providing the service to continue until it has received and validated that acknowledgment. DS |