[Mysqlfs-general] Patch to mysqlfs-0.2 to break file data into records of 4k chunks

[Lester H. <hig...@10...>]

I did the attached work before finding and reading this:

https://sourceforge.net/mailarchive/forum.php?thread_id=30561843&forum_id=50318

which may make some of this work less relevant, but I don't think so, as I
see that data is still stored ina blob (via schema.sql) on the head of the
trunk in the CVS repository on sourceforge.net.

My patch does seem to provide exceptional performance enhancements in my
test cases, and is actually not a complicated set of patches.  The premise
is simple, instead of storing the file data in a longblob in the fs table,
I created a related table, fs_file_blocks, that holds the data in blocks
of no more than 4k chunks, with a tabledef as follows:

  mysql> desc fs_file_blocks;
  +-------+--------------+------+-----+---------+-------+
  | Field | Type         | Null | Key | Default | Extra |
  +-------+--------------+------+-----+---------+-------+
  | path  | varchar(255) | YES  | MUL | NULL    |       |
  | seq   | int(11)      |      |     | 0       |       |
  | data  | blob         | YES  |     | NULL    |       |
  +-------+--------------+------+-----+---------+-------+
  3 rows in set (0.00 sec)


The chunk size (4k) is defined in mysqlfs.h, as #define FS_BLOCK_SIZE

I can find no firm documentation telling me that FUSE writes in 4k blocks,
but my testing seems to indicate that it does.  If that can vary, then
FS_BLOCK_SIZE should be pulled from the FUSE API instead of constant.

My testing of this code shows better than a 10-fold increase in write
speed, and that improvement is more pronounced on larger files.  It also
shows a 3-fold increase in read speed.

This patch adds no features to mysqlfs, so things like chown(), etc. are
"not yet implemented" just as they were.

Sincerely,

--
Lester Hightower