On Sat, 13 Sep 2014 01:07:59 +0100 Simon Slavin <slav...@bigfraud.org> wrote:
> > Implement a block-transaction store on the device > > itself: no inodes, no directories, just writeable blocks managed in > > transactions. Build your DBMS on that. > > That would be ... erm ... perhaps a new disk volume format. Where > the blocks of the volume were pages of a SQLite database. Yes. It can be done in userspace; Sybase calls it a "device". Better, surely, would be a kernel-side implementation, living alongside FFS, ext4, etc., except *not* providing Posix filesystem services. As Richard pointed out, if the tranlog is in the "file" and the "file" has observable size, then the "file" grows by the size of the tranlog. In Sybase, the tranlog is a table in a "device", the size of which was preallocated in a disk partition. It's a different model. As I said, the filesystem affords conveniences to user and programmer both. > > I asked your question: why not add transactions to FFS? > > > > His answer: that's the province of a database. > > A file system is a database. It accepts data from a user. It stores > it away for later retrieval. It allows it to be searched in various > ways more convenient than just reading it from beginning to end every > time. I used "database" because that was his word. Whether or not a filesystem is a database depends on the definition. I would say that the files are data, but the filesystem is not a DBMS, partly for reasons you mention. Do the files nonetheless constitute a database? I would say no, because they don't meet that treshhold. Among other things, the filesystem offers no key: no way to identify the entities it stores. If you say the offset into the file is the key, OK, but then the "entity" is a byte, which is a pretty primitive database if you ask me. I really think enriching the filesystem is not the way to go. I saw a presentation not long ago on running Postgres on ZFS. ZFS, you may know, has snapshots and transactions. Now watch as the filesystem journals writes to the transaction log, and takes snapshots of the non-quiescent database files. I didn't know whether to laugh or cry. --jkl _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
