LWN.net Logo

Better than POSIX?

Better than POSIX?

Posted Mar 17, 2009 17:53 UTC (Tue) by walters (subscriber, #7396)
Parent article: Better than POSIX?

The problem with the POSIX interface (and raw filesystem APIs in general) is that they're too general. Is it designed for Postgres? Is it designed for preference store backends? Is it designed for my IRC client to store conversation logs (with search)? You can't do all of these simultaneously and well.

Basically I think the filesystem should be designed for #1 and #2, and what we really need is better userspace libraries; particularly for desktop applications. If those *libraries* happen to use kernel-specific interfaces for optimization, that makes sense.

For example, I'm pretty sure one could put part of sqlite's atomic commit in the kernel.

The other argument against trying to solve this in the kernel is that very few programs use the raw libc/POSIX interface; they're using the standard C++ library, Java, Python, Qt, GLib/Gio etc. So any changes have to be made at those levels.


(Log in to post comments)

Better than POSIX?

Posted Mar 17, 2009 18:03 UTC (Tue) by quotemstr (subscriber, #45331) [Link]

For example, I'm pretty sure one could put part of sqlite's atomic commit in the kernel.
Your ideas (like most ideas) have been brought up in the past. Down that road you propose lay record-oriented filesystems. There's a reason every major filesystem today works with generic files: the alternative is absolutely horrible.
The other argument against trying to solve this in the kernel is that very few programs use the raw libc/POSIX interface; they're using the standard C++ library, Java, Python, Qt, GLib/Gio etc. So any changes have to be made at those levels.
There interfaces are as generic as the POSIX ones, and putting data integrity logic there will not alleviate any of the concerns that have already been raised. If you want to make file-format-specific optimizations, you have to modify file-format-specific libraries --- and most applications just roll their own. Fixing the problem in the kernel solves all these issues elegantly, and at once.

Better than POSIX?

Posted Mar 17, 2009 18:31 UTC (Tue) by butlerm (subscriber, #13312) [Link]

That SQLite explanation you quoted is an excellent example. It is worth
noting however that high performance databases can commit a durable
transaction as soon as the necessary journal update has made it to
persistent storage. Nothing else needs to be touched.

SQLite on the other hand, appears to do a checkpoint (i.e. finish the
updates to all the actual data files) as part of every commit. That is not
necessary in a good design. There is nothing fundamental about filesystem
or database design that requires anything except the journal to be
synchronously updated on transaction commit. If durability is not
required, not even that.

Better than POSIX?

Posted Mar 26, 2009 16:42 UTC (Thu) by muwlgr (guest, #35359) [Link]

There was nice DBMS, Btrieve from Novell, with similar rollback facilities. Used it under DOC and liked it in the past.

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