Date: Sat, 1 Dec 2001 18:04:46 -0500 From: David Jones <dej@inode.org> To: freebsd-fs@freebsd.org Cc: dej@inode.org Subject: SoftUpdates semantics and data integrity Message-ID: <01120118044609.17440@coup.inode.org>
next in thread | raw e-mail | index | archive | help
As I understand it, metadata on a soft updates file system is not flushed= =20 right away, and delays of up to one minute before flushing are possible. = =20 However, soft updates will ensure that the file system will reflect a sta= te=20 that it had at some point in time before a crash. At a former employer, I wrote a database-type application that went to gr= eat=20 pains to achieve atomic transactions, even in the event of a crash. I am= =20 wondering if soft updates changes the things I have to do to achieve such= =20 reliability in the future. Answers to the following are appreciated, for both sync-metadata FFS and = soft=20 updates FFS: 1. What must I do in software to ensure that data written to a file has m= ade=20 it to disk? Is close() sufficient, or must I fsync() as well? Is the da= ta=20 guaranteed to be there after fsync() returns? (It isn't with sync()). 2. What must I do to ensure that a rename() has either succeeded or faile= d? =20 "Succeeded" means "the target name refers to the new file, even if the sy= stem=20 crashes right now". 3. If I do two filesystem operations one after the other, can I be assure= d=20 that the first one will be committed safely to disk when the second compl= etes? I don't care about performance necessarily in these cases; I just want to= be=20 sure that a data transaction is guaranteed to be on the disk come hell or= =20 high water in certain, critical cases. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?01120118044609.17440>