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 right away, and delays of up to one minute before flushing are possible. However, soft updates will ensure that the file system will reflect a state that it had at some point in time before a crash. At a former employer, I wrote a database-type application that went to great pains to achieve atomic transactions, even in the event of a crash. I am wondering if soft updates changes the things I have to do to achieve such reliability in the future. Answers to the following are appreciated, for both sync-metadata FFS and soft updates FFS: 1. What must I do in software to ensure that data written to a file has made it to disk? Is close() sufficient, or must I fsync() as well? Is the data 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 failed? "Succeeded" means "the target name refers to the new file, even if the system crashes right now". 3. If I do two filesystem operations one after the other, can I be assured that the first one will be committed safely to disk when the second completes? I don't care about performance necessarily in these cases; I just want to be sure that a data transaction is guaranteed to be on the disk come hell or 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>