On 13 Sep 2014, at 7:01pm, Luuk <luu...@gmail.com> wrote: > On 13-9-2014 19:45, Simon Slavin wrote: > >> What I want is the entire volume as a database. It would be something like >> >> Key Example value >> --- ------------- >> /robots.txt/path / >> /robots.txt/filename robots.txt >> /robots.txt/creationdate whatever >> /robots.txt/filetype text >> /robots.txt/creatorapp /Applications/textwrangler.app >> /robots.txt/content BLOB >> /index.html / >> /index.html/filename /index.html >> /index.html/creationdate whatever >> ... >> >> The actual primary key would be a a two column index, of course. > > My question will than be: > Would the primary index not be the i-node number (in case of ext3/ext4 > filesystem), or the sectornr in case of FAT
Sorry, that still incorporates a sub-database disk format, and that's what I want to avoid. The volume itself should be the equivalent of a SQLite database. Sectors of the volume would be the pages of the SQLite database. The i-node numbers (or sector numbers) would be the pointers inside the SQLite database which normally point to page numbers in the database file. For example, the binary trees mentioned in section 2.3 of <http://www.sqlite.org/fileformat.html> would contain page numbers which are, in this case, sector/inode numbers. They wouldn't be integers stored in the database itself. One big difference between this and how SQLite works right now is that the database would always take up the complete space reserved for the volume, thus making VACUUM do nothing. Presumably some equivalent of VACUUM could be used to defragment tables and indexes, and it would have to be disabled for SSDs. Though with today's storage hardware defragmentation isn't of much benefit. I must admit I'm having trouble getting my head around how to do journaling with this. Another way of arranging the storage would, of course, be with every file a row of the Files table which has one column for each property stored: Columns for the 'Files' table: Path Name CreationDate CreatorApp Type Content / robots.txt 1/1/2012 TextEdit text BLOB / index.html 1/1/2014 Webmaker HTML BLOB Other tables in the database could be used to store other things. Although the freespace and bad block list might be best stored as pseudo-files. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
