Re: flushing HFS cache to disk (Dave Yost)
Re: flushing HFS cache to disk (Dave Yost)
- Subject: Re: flushing HFS cache to disk (Dave Yost)
- From: Dominic Giampaolo <email@hidden>
- Date: Thu, 1 Dec 2005 16:03:03 -0800
[ sync() being synchronous or not ]
On a journaled HFS+ volume, sync is synchronous because
we flush the in-memory transaction buffer and the last
thing that does is a flush-track-cache command which will
not complete until all the other i/o's are complete.
The behavior of other file systems is "mostly" synchronous.
That is, they can issue async writes but after about 30 or
so they will block on the queue of pending i/o going into
the driver. In the worst case sync() could return with up
to about 30 i/o's pending for a file system (on a local
disk).
Of course if you issue an fsync() on a file descriptor, that
is *always* fully synchronous and will not return until the
data is flushed.
Having said all that, anyone that goes behind the back of
the file system to read on disk data structures while the
file system is still mounted is on thin ice. You can
guarantee that we will break you in future releases. The
functionality requested by the original poster is easily
obtained with the PBCatSearch() interface. If you need
sample code I can send it to you. It's a very fast way to
search for files on an HFS file system.
Someday, I wish for a file system that is really a true database,
with transactional semantics.
User level transactions would be very nice. It's not an
easy problem though and definitely not something one can
easily retrofit on existing file systems.
They have transactional semantics in that each individual
operation is atomic
That's not even true. If you do this:
create-write1-write2-write3-close
and the system crashes, the result must be one of:
....
I suppose you could write the file as a temp file, do a synchronous
flush of the file, then move it into place. This is of course, a
hack on top of an API that was never designed to be transactional.
And you could still end up with a temp file lying around
As you surmise, writing a temp file, calling fsync() and then
doing a rename() is the proper way to handle this.
Of course user-level transactions are still a good thing but
rename() (or the macos 9 style exchangedata()) give you most
of what you need without the complexity of user level
transactions.
--dominic
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden