On 23.12.2010 23:22, Ted Ts'o wrote:
On Fri, Dec 24, 2010 at 08:51:26AM +1100, Neil Brown wrote:
You are asking for something that doesn't exist, which is why no-one can tell
you want the answer is.
Basically, file systems are not databases, and databases are not file
systems. There seems to be an unfortunate tendency for application
programmers to want to use file systems as databases, and they suffer
as a result.
wrong, no suffer, quite contrary, take an approach like done with sqlite
[...]
You may *say* that you don't care which version of the file you get
after a rename, but only that one or the other is valid, but what if
some other program reads from the file, gets the second file, and
sends out a network message saying the rename was successful, but then
a crash happens and the rename is undone? There's a reason why
databases block reads of a modified row until the transaction is
completed or rolled back.
where is the suffer then to use database semantics?
[...]
Or use a real database, and don't try to assume you will get database
semantics when you try to write to multiple small files.
wrong, do Atomicity + CID
[...]
But for the crazy kids who want to write several hundred small files
when an GNOME or KDE application exits (one file for the X coordinate
for the window, another file for the Y coordinate, another file for
the height of the window, another file for the width of the window,
etc....) --- cut it out. That way just lies insanity; use something
like sqlite instead and batch all of your updates into a single atomic
update.
what now? see above! where is the unfortunate tendency and suffer?
Or don't use crappy proprietary drivers that will crash your
system at arbitrary (and commonplace) times.
- Ted
Christian Stroetmann
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
