Re: "Flushing" a rename?
Re: "Flushing" a rename?
- Subject: Re: "Flushing" a rename?
- From: Jens Alfke <email@hidden>
- Date: Tue, 13 May 2008 16:30:48 -0700
On 13 May '08, at 3:36 PM, James Bucanek wrote:
I know that flushing an open file fork (FSFlushFork) guarantees that
all of the file data, and all directory records associated with that
file, have all been written to disk before the call returns.
I'm not familiar with exactly how the CarbonCore <Files.h> calls map
onto system calls. I would guess that FSFlushFork calls fsync. In that
case, what it's doing is flushing all writes to the kernel, and from
there to the disk controller. But that's not the same as actually
writing to the disk platters.
The disk controller has a several-megabyte internal buffer, and when
it's told to write sectors, they end up in the buffer for a little
while before they get written, so that the drive can optimize its seek
pattern. During that little while, if the kernel panics, or the system
loses power, or the USB/FireWire cable is yanked, those sector-level
writes are lost.
To be absolutely sure that a write has gone through to persistent
storage, you have to call fcntl with the F_FULLFSYNC opcode. This
tells the disk controller to flush its buffers, and blocks until the
flush finishes. Unfortunately, there are two problems with this:
(1) During the flush, the disk controller will not perform any other
activity, so all I/O to that disk is blocked. The sync can take a good
fraction of a second, so calling this too often can wreak havoc with
processes reading or writing in real-time (iTunes, Final Cut, Logic,
etc.) and can visibly stall or slow down other tasks too.
(2) Not all disk controllers actually flush when told to. Ignoring the
flush can speed up benchmark performance. But it also makes the
F_FULLFSYNC a no-op, so on such a disk you have absolutely no way of
knowing whether the bits have landed yet or not. (I don't know if
there's a way to detect such controllers. I do not believe Apple ships
any drives with such controllers, but with a 3rd-party drive you never
know.)
Note that this isn't something that needs to happen very often (a
few times a day).
In that case doing an F_FULLFSYNC should be fine.
—Jens
Disclaimer: I am not a filesystem guru; I've had to pick up this
knowledge during several years of working with sqlite databases and
trying to avoid file corruption upon poorly-timed kernel panics or
power loss.Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden