[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Distinct transactions


On Thu, Jun 14, 2001 at 09:21:20AM -0400, Charlie Woloszynski wrote:
> I have been asked to set up a Linux box that can be power-cycled at any
> time and it should not fail to reboot.  EXT3 seems like the basis for such
> a box, and we have set up a RedHat 6.2 box with the new kernel and we have
> ext3 working.  We have set up ext3 to journal both metadata and data
> changes (and we are willing to accept the reduced disk throughput).
> From what I can see, I can expect EXT3 to make sure that the logging data
> flowing into the box will either be appended to the file or not, but I am
> not sure at what level will the filesystem changes be 'chunked' into
> transactions.  Is there some direct mapping of system calls to
> 'transactions' on the file system that we can assume?

First of all, if you are extending existing files, then the
"data=ordered" journaling mode will give you the same atomicity
guarantees as "data=journaled", without the performance penalty of
writing everything twice.  

Secondly, nearly every transaction is atomic on disk in ext3.
Truncates can span more than one transaction, but ext3 recovery after
a crash will complete any partial truncate which happened to be split
over transactions.

Only large writes will ever be split over transactions.  Now, in older
versions of ext3, the definition of "large" was slightly broken, but
in 0.0.7a only transactions which take up more than 64 blocks in the
log should ever be broken up.  That's hard to translate exactly into
the size of a write(): it depends on how fragmented the written data
is, and whether or not quotas are enabled.  But any write below about
16k is going to be completely atomic on ext3 with data journaling, and
any append of that size will be atomic even with ordered journaling.  

> We are proposing:
> (1) copy the config file to some new file.
> (2) modify the new file and close it.
> (3) move the existing config file to a backup file
> (4) move the modified file to replace the original file
> Are we right in assuming that these actions retain their sequentiality with
> journaling?


> That is, can we be sure that if (3) occurred in the
> filesystem, that (2) must have been completed?

Yes.  data=ordered and data=journal should both satisfy your
constraints in this case.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]