Re: How to know when file data has been flushed into disk?

["linux-os \(Dick Johnson\)" <linux-os@analogic.com>]

On Fri, 7 Apr 2006, Xin Zhao wrote:

> Thanks for your reply.
>
> That make sense. But at least ext3 needs to know when all data has
> been flushed so that it can commit the meta data. Question is how can
> ext3 knows that? The data flushing is done by flush daemon. There go
> to be some way to notify ext3 that data is flushed. Where  is this
> part of code in ext3 module?
>
> Xin
>
> On 4/7/06, Douglas McNaught <doug@mcnaught.org> wrote:
>> "Xin Zhao" <uszhaoxin@gmail.com> writes:
>>
>>> 3. Does sys_close() have to  be blocked until all data and metadata
>>> are committed? If not, sys_close() may give application an illusion
>>> that the file is successfully written, which can cause the application
>>> to take subsequent operation. However, data flush could be failed. In
>>> this case, file system seems to mislead the application. Is this true?
>>> If so, any solutions?
>>
>> The fsync() call is the way to make sure written data has hit the
>> disk.  close() doesn't guarantee that.
>>
>> -Doug
>>

In principle, you __never__ know that the data got to the
disk platter(s). Any database that thinks differently is
broken by design. You need transaction processing to be
assured that you have all the (correct) data available
in the database. Transaction processing provides atomic
stepping stones so that, in the event of a failure, the
transactions can be rolled back to the last complete one
and then restarted.

The simplest example is the use of a number of journal
files, each containing a record of the previous
transactions and enough information to roll-back the
database to the point at which these files were saved.
These files are checksummed and saved in order. In the
event of a crash, these files are read until the latest
of the readable ones has a correct checksum. The database
manager uses the information in the file to roll-back
the main database to the exact content at the time the
journal file was saved.

Once the database is restarted, any previous journal
files can be deleted as well as the bad ones that followed.
However, the journal file that was used to restart the
database is never deleted until it has been superseded
by another that worked in a database restart. That way,
there is always a way to get back to a clean database.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.15.4 on an i686 machine (5589.42 BogoMips).
Warning : 98.36% of all statistics are fiction, book release in April.
_
\x1a\x04

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.