User: Password:
Subscribe / Log in / New account



Posted Oct 30, 2009 4:30 UTC (Fri) by xoddam (subscriber, #2322)
In reply to: Atomicity by Nicolas.Boulay
Parent article: POSIX v. reality: A position on O_PONIES

Database implementors have many choices for implementing data stores and any transactional semantics that they need.

Databases traditionally use very large files because their implementors have chosen to re-implement filesystem functionality at the low level for performance reasons.

Most often they use their own journalling implementations and fsync(). This is of course legitimate. But using filesystem-level rename to provide atomicity would also be perfectly reasonable.

The size of the renamed and replaced file is an implementation detail only. Rename doesn't impose a requirement to copy large hunks of data only to throw it away. The unit of replacement might be a btree node, for example.

Nothing forces an implementor to use large files for any particular purpose.

(Log in to post comments)

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds