Menu
▾
▴
mysqlfs-general — General discussion list for MySQLfs users and developers.
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(7) |
Oct
|
Nov
(3) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
|
Feb
|
Mar
(10) |
Apr
(24) |
May
|
Jun
|
Jul
|
Aug
(18) |
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
(13) |
Apr
(7) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
|
|
From: Michal L. <mi...@lo...> - 2007-03-20 12:31:32
|
> On Monday 19 March 2007 22:20:03 Michal Ludvig wrote: > >> Hi Stef, > >> that's weird, I did quite a lot of tests and it all worked for me. I'll >> try to reproduce the bug and get back to you. Hi Stef, I can confirm, I got file corruption as well. It seems to corrupt files bigger than roughly 1MB. Strange I haven't noticed this bug during development (ehm, looks like our QA procedure is somewhat weak ;-) I'll look at it later this week and eventually put out a new release. Thanks for the report and sorry for the troubles. Michal |
|
From: Stef B. <st...@bo...> - 2007-03-20 07:58:24
|
On Monday 19 March 2007 22:20:03 Michal Ludvig wrote: > Hi Stef, > > that's weird, I did quite a lot of tests and it all worked for me. I'll > try to reproduce the bug and get back to you. > > What MySQLfs version, Distribution, Linux version, MySQL version and gcc > version did you use? Hello, a summary of what I'm using: gcc --version gcc (GCC) 4.0.3 distribution: LinuxFromScratch version 6.2 (look at www.linuxfromscratch.org) Kernel: 2.6.18.5 on a pentium4 system with hypertreading Mysql version 5.0.21 Fuse version 2.6.2 Mysqlfs version 0.3.1 Hope this helps. Looking forward to your reaction. Stef Bon |
|
From: Michal L. <mi...@lo...> - 2007-03-19 21:20:18
|
Hi Stef, that's weird, I did quite a lot of tests and it all worked for me. I'll try to reproduce the bug and get back to you. What MySQLfs version, Distribution, Linux version, MySQL version and gcc version did you use? Michal Stef Bon wrote: > Hello all, > > first I want to say that I'm very happy with mysqlfs. It gives me the > opportunity to make backups to a database. > > But I ran into troubles when I wanted to try it. The description you'll find > at: > > https://sourceforge.net/tracker/index.php?func=detail&aid=1681567&group_id=129981&atid=716425 > > (bugid:1681567) > > Can someone look at it? > > Kind regards, > > > Stef Bon > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Mysqlfs-general mailing list > Mys...@li... > https://lists.sourceforge.net/lists/listinfo/mysqlfs-general |
|
From: Stef B. <st...@bo...> - 2007-03-19 20:26:51
|
Hello all, first I want to say that I'm very happy with mysqlfs. It gives me the opportunity to make backups to a database. But I ran into troubles when I wanted to try it. The description you'll find at: https://sourceforge.net/tracker/index.php?func=detail&aid=1681567&group_id=129981&atid=716425 (bugid:1681567) Can someone look at it? Kind regards, Stef Bon |
|
From: Frederik D. <fre...@da...> - 2006-11-29 14:10:11
|
On Wednesday 29 November 2006 14:19, Frederik Dannemare wrote:
[ snip ]
> Debian package changelog:
Just made yet another changelog entry:
mysqlfs (0.3.1-7) unstable; urgency=low
* Add the keyword PRIMARY to line 67 in schema.sql,
otherwise MySQL 5.1.11beta-1 will complain during
table creation (but only when the NDB Cluster storage
engine is used, it seems - MyISAM doesn't complain).
See http://bugs.mysql.com/bug.php?id=6546 for related info.
-- Frederik Dannemare <fre...@da...> Wed, 29 Nov 2006
14:30:52 +0100
Ergo, a small diff:
--- mysqlfs-0.3.1.orig/schema.sql
+++ mysqlfs-0.3.1/schema.sql
@@ -64,7 +64,7 @@
`parent` int(10) unsigned default NULL,
`name` varchar(255) NOT NULL,
UNIQUE KEY `name` (`name`,`parent`),
- KEY `inode` (`inode`),
+ PRIMARY KEY `inode` (`inode`),
KEY `parent` (`parent`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
/*!40103 SET TIME_ZONE=@OLD_TIME_ZONE */;
B/R,
Frederik Dannemare
|
|
From: Frederik D. <fre...@da...> - 2006-11-29 13:19:32
|
Hi,
first of all, a great many thanks for this wonderful piece of software.
Now to my question: How should FUSE options be passed
when mysqlfs is executed?
In particular, I'm interested in allowing other users to see/use the
mounted filesystem. Thus, I'm trying to do it like this:
mysqlfs -ohost=localhost -ouser=mysqlfs -opassword= -odatabase=mysqlfs /var/lib/mysqlfs/fs -oallow_other
* Opening logfile 'mysqlfs.log': OK
fuse: invalid argument `allow_other'
mysqlfs -ohost=localhost -ouser=mysqlfs -opassword= -odatabase=mysqlfs /var/lib/mysqlfs/fs -onoprivate
* Opening logfile 'mysqlfs.log': OK
fuse: invalid argument `noprivate'
Hints are welcome.
B/R,
Frederik Dannemare
P.S.: I have created a Debian package of MySQLfs, also including a
minimalistic manpage and an init script. I'm already officiel Debian
maintainer of a few other packages, and I was thinking of getting
MySQLfs into Debian as well. Feedback is welcome.
Content of package:
$ dpkg --contents ../mysqlfs_0.3.1-6_i386.deb
drwxr-xr-x root/root 0 2006-11-29 11:39 ./
drwxr-xr-x root/root 0 2006-11-29 11:39 ./usr/
drwxr-xr-x root/root 0 2006-11-29 11:39 ./usr/bin/
-rwxr-xr-x root/root 26584 2006-11-29 11:39 ./usr/bin/mysqlfs
drwxr-xr-x root/root 0 2006-11-29 11:39 ./usr/share/
drwxr-xr-x root/root 0 2006-11-29 11:39 ./usr/share/doc/
drwxr-xr-x root/root 0 2006-11-29 11:39 ./usr/share/doc/mysqlfs/
-rw-r--r-- root/root 1674 2006-10-03 00:06 ./usr/share/doc/mysqlfs/changelog.gz
-rw-r--r-- root/root 404 2006-10-03 00:34 ./usr/share/doc/mysqlfs/NEWS.gz
-rw-r--r-- root/root 721 2006-09-17 13:41 ./usr/share/doc/mysqlfs/TODO
-rw-r--r-- root/root 1344 2006-11-21 21:49 ./usr/share/doc/mysqlfs/README.Debian
-rw-r--r-- root/root 634 2006-11-15 10:17 ./usr/share/doc/mysqlfs/copyright
drwxr-xr-x root/root 0 2006-11-29 11:39 ./usr/share/doc/mysqlfs/examples/
-rw-r--r-- root/root 2741 2006-09-23 10:59 ./usr/share/doc/mysqlfs/examples/schema.sql
-rw-r--r-- root/root 716 2006-11-29 11:35 ./usr/share/doc/mysqlfs/changelog.Debian.gz
drwxr-xr-x root/root 0 2006-11-29 11:39 ./usr/share/man/
drwxr-xr-x root/root 0 2006-11-29 11:39 ./usr/share/man/man1/
-rw-r--r-- root/root 659 2006-11-16 13:29 ./usr/share/man/man1/mysqlfs.1.gz
drwxr-xr-x root/root 0 2006-11-29 11:39 ./var/
drwxr-xr-x root/root 0 2006-11-29 11:39 ./var/lib/
drwxr-xr-x root/root 0 2006-11-29 11:39 ./var/lib/mysqlfs/
drwxr-xr-x root/root 0 2006-11-29 11:39 ./var/lib/mysqlfs/fs/
drwxr-xr-x root/root 0 2006-11-29 11:39 ./etc/
drwxr-xr-x root/root 0 2006-11-29 11:39 ./etc/default/
-rw-r--r-- root/root 445 2006-11-21 11:08 ./etc/default/mysqlfs
drwxr-xr-x root/root 0 2006-11-29 11:39 ./etc/init.d/
-rwxr-xr-x root/root 2874 2006-11-29 11:34 ./etc/init.d/mysqlfs
Debian package changelog:
mysqlfs (0.3.1-6) unstable; urgency=low
* Clean up pid file on stop.
* Add dependency on fuse-utils.
-- Frederik Dannemare <fre...@da...> Wed, 29 Nov 2006 11:34:28 +0100
mysqlfs (0.3.1-5) unstable; urgency=low
* Add extra checks with regards to determining whether mysqlfs has stopped
completely or not when calling the init script with 'stop'. If something
is wrong, the user will receive informative output.
-- Frederik Dannemare <fre...@da...> Tue, 21 Nov 2006 21:27:37 +0100
mysqlfs (0.3.1-4) unstable; urgency=low
* Add schema.sql to debian/examples.
* Modify README.Debian (for easier copy'n'paste with
regards to creating the MySQL db) and remove unnecessary
text regarding stuff that the init script now handles.
* Try to find a somewhat solid way of getting the correct PID
of mysqlfs and make use of this PID value in the init script.
-- Frederik Dannemare <fre...@da...> Tue, 21 Nov 2006 16:50:35 +0100
mysqlfs (0.3.1-3) unstable; urgency=low
* Cosmetic changes (including a typo fix) to man page.
* Add init script and accompanying /etc/default/mysqlfs file.
* Add var/lib/mysqlfs/fs and etc/default to debian/dirs.
-- Frederik Dannemare <fre...@da...> Wed, 15 Nov 2006 20:40:34 +0100
mysqlfs (0.3.1-2) unstable; urgency=low
* Change the description in debian/control slightly.
-- Frederik Dannemare <fre...@da...> Wed, 15 Nov 2006 11:56:20 +0100
mysqlfs (0.3.1-1) unstable; urgency=low
* Initial release.
* Add minimalistic manpage.
* Add README.Debian with post-install instructions.
-- Frederik Dannemare <fre...@da...> Wed, 15 Nov 2006 10:00:40 +0100
|
|
From: Rodrigo B. <rod...@da...> - 2006-11-02 03:48:10
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Environment description: - CentOS 4.4 - Toshiba Tecra A2 notebook * Intel(R) Celeron(R) M processor 1500MHz * MemTotal: 758640 kB - gcc (GCC) 3.4.6 20060404 (Red Hat 3.4.6-3) - mysql Ver 14.12 Distrib 5.0.22, for redhat-linux-gnu (i686) using readline 5.0 - fuse 2.5.3 - System under normal use during tests to add randomness Note: usage pattern was comparable during all tests - Max Swapspace used during test: aprox. 4M Reference values (ext3 filesystem): - Test RPM package build times (custom exim 4.43 package): real 4m43.743s user 2m48.880s sys 0m12.810s mysqlfs values: - Test RPM package build times (custom exim 4.43 package): real 16m55.843s user 2m44.973s sys 0m16.201s - Bonnie++ Total Errors Encontered: 0 (Very nice indeed) Conclusion: Mysqlfs is working very well now. Unfortunately, speed is still a major issue. Best Regards, - -- Rodrigo Barbosa "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFSWpdpdyWzQ5b5ckRAsv1AJ9Dza0ck8tOWN9SUrtoj7M2CWvOngCdH4/+ 7JpcY/TMTXHfMuSvdgLhY9c= =rlFC -----END PGP SIGNATURE----- |
|
From: Michal L. <mi...@lo...> - 2006-09-29 23:12:19
|
Troy Ayers wrote:
> When compiling mysqlfs version 0.3 I see in my config.log:
>
> configure:18717: checking for mysql_init in -lmysqlclient
> configure:18747: gcc -o conftest -L/usr/local/lib -I/usr/local/include
> -Wall -Werror -I/usr/include/mysql -g -pipe -m32 -march=i3
> 86 -mtune=pentium4 -L/usr/local/lib -L/usr/lib/mysql -lmysqlclient_r
> -lz -lpthread -lcrypt -lnsl -lm -lpthread conftest.c -lmysq
> lclient -lpthread >&5
> /usr/lib/mysql/libmysqlclient.a(my_compress.o)(.text+0x57): In function
> `my_compress_alloc':
> : undefined reference to `compress'
> /usr/lib/mysql/libmysqlclient.a(my_compress.o)(.text+0x143): In function
> `my_uncompress':
> : undefined reference to `uncompress'
>
> But of course compress/uncompress is supported (libz right?):
> # ldd /usr/lib/libmysqlclient.so | grep libz
> libz.so.1 => /usr/lib/libz.so.1 (0x00475000)
I don't have RHEL installed but perhaps zlib-devel package could solve
it? If not I'll install CentOS 4 somewhere and try to reproduce. But
that would take some time.
BTW On my SuSE box I have these symbols in libz:
$ nm /usr/lib/libz.a | grep compress
compress.o:
000000f0 T compress
00000020 T compress2
00000000 T compressBound
00000000 T uncompress
U compressBound
00000ac0 t compress_block
and mysql-devel depends on zlib-devel so I got the dependency satisfied.
Michal
|
|
From: Troy A. <dsp...@wc...> - 2006-09-29 16:21:26
|
When compiling mysqlfs version 0.3 I see in my config.log:
configure:18717: checking for mysql_init in -lmysqlclient
configure:18747: gcc -o conftest -L/usr/local/lib -I/usr/local/include
-Wall -Werror -I/usr/include/mysql -g -pipe -m32 -march=i3
86 -mtune=pentium4 -L/usr/local/lib -L/usr/lib/mysql -lmysqlclient_r
-lz -lpthread -lcrypt -lnsl -lm -lpthread conftest.c -lmysq
lclient -lpthread >&5
/usr/lib/mysql/libmysqlclient.a(my_compress.o)(.text+0x57): In function
`my_compress_alloc':
: undefined reference to `compress'
/usr/lib/mysql/libmysqlclient.a(my_compress.o)(.text+0x143): In function
`my_uncompress':
: undefined reference to `uncompress'
collect2: ld returned 1 exit status
configure:18753: $? = 1
configure: failed program was:
| /* confdefs.h. */
|
| #define PACKAGE_NAME "mysqlfs"
<snip>
| }
configure:18778: result: no
configure:18788: error: Please install mysqlclient library first.
## ---------------- ##
But of course compress/uncompress is supported (libz right?):
# ldd /usr/lib/libmysqlclient.so | grep libz
libz.so.1 => /usr/lib/libz.so.1 (0x00475000)
#gcc -v
Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.3/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-java-awt=gtk
--host=i386-redhat-linux
Thread model: posix
gcc version 3.4.3 20041212 (Red Hat 3.4.3-9.EL4)
-Troy
|
|
From: Michal L. <mi...@lo...> - 2006-09-29 12:41:23
|
Hi Lester, > 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: That looks like a pretty good idea. However the codebase and DB schema changed *a lot* since mysqlfs-0.2. Could you forward port your changes to 0.3 please? We don't use the full path as a key anymore instead we use inodes. But that shouldn't make a big difference for you. I also suggest to pull the current sources from the anonymous CVS and send us the output of "cvs diff -up" once you're done with porting. A good test of mysqlfs stability proved to be compilation of some nontrivial package (I use openssl-0.9.8 myself as that does some pretty nasty things ;-) so you can try that as well to see how your changes behave in a real life. I'm looking forward to see your patch in the next mysqlfs release! Michal |
|
From: Lester H. <hig...@10...> - 2006-09-26 14:48:28
|
Recently, I have investigated FUSE as an option for implementing something like I proposed to this list in April, 2005 (instead of inotify). Just yesterday, I submitted some patches to the mysqlfs-general mailing list that improve mysqlfs a bit. With a little more work (which I may or may not do), using mysqlfs (a FUSE filesystem) and mysql replication, one can achieve a real-time, one-to-many, over-the-network replicated filesystem. That can be done with mysqlfs today, particularly with my patches in place, but limitations still exist (at this time), like no support for sparse files, open()/seek()/read() or open()/seek()/write() operations. At present, you have to read and write files contiguously, from beginning to end (that is true with or without my patches). My patches to mysqlfs-0.2 (that I posted yesterday) primarily address performance and mysql mirror-ability. Mysqlfs certainly has its place, and I am very glad to see that it exists, but the reason that I may not finish my mysqlfs work is that SQL servers are just not designed to store filesystems, and I am convinced that no amount of hacking is ever going to make FUSE+mysqld give performance even close to that of a real, on-disk file system. Further, and mostly based on my mysqlfs work, I am also now fully convinced that I can author a FUSE filesystem that realizes my original proposition from 18 months ago. My new concept is this: 1) Mount a filesystem, say /dev/vg0/vol0, on /mnt/.vol0_do_not_touch/ 2) Mount the FUSE fs, like: /sbin/rsyncfs -odbhost=host -odbuser=user \ -odbpasswd=passwd -odb=db -ofstarget=/mnt/.vol0_do_not_touch /mnt/vol0 3) Work only in /mnt/vol0, which will do all the filesystem operations to the fstarget dir, and also place records into the DB (build a queue) of paths that change. 4) Have a separate process that rsyncs to the target machine(s) only the files in the changed queue (and drains that queue), eliminating the need to find/transfer/evaluate large lists of unchanged files. My rsyncfs command line example above demonstrates an external database, like mysql or postgres, but the more I think about this the more I am leaning towards using an embedded database, like SQLite, and insisting that the rsyncing process also live on the master host, and pushes changes out to the slaves. A networked database could allow one to reverse that model, but the embedded database seems attractive to me. Opinions? This design can be stretched further, depending on your use case. For example, if you knew your FS was "mostly idle" the rsyncing process could only sync changed paths that have been idle more than 60 secs, to avoid rsyncing a given file (that seldom changes) more than once during a time when a user may be making rapid changes to it, but just for a short time. The rsyncer process could warn if a file has been in queue longer than a certain time, and is still hot (actively changing), or just sync it. My reason for writing this email is to solicit comments from the list. My post from April of last year received quite a few responses, but not an overwhelming number. We have started to upgrade servers to rsync 2.6.8, and are finding good performance improvements (reduced load) from it, and that fact lessons (but does not eliminate) our need for rsyncfs. Steve Bonds (CCed) seemed to be most in need of something like the rsyncfs that I proposed last year, and so I specifically CCed him to see if that interest still exists. There is also the chance that someone else has solved this problem in a way that I do not know about. That is another reason for this email -- I don't want to spend time coding rsyncfs if a solution that will work for us already exists. Thanks in advance for any feedback. -- Lester Hightower > On 4/12/05, Lester Hightower wrote: > > > [...snip...] > > The actual replication happens in user-land with rsync as the transport. > > I think rsync will have to be tweaked a little to make this work, but > > given all the features already in rsync I don't think this will be a big > > deal. I envision an rsync running on Host A like: > > > > # rsync --constant --from0 --files-from-fifo=/vol/0/chglog.fifo ... > > > > that will be communicating with an "rsync --constant ..." on the other > > end. The --constant flag is my way of stating that both rsyncs should > > become daemons and plan to "constantly" exchange syncing information until > > killed -- that is, this is a "constant" rsync, not just one run. > > [...snip...] On Wed, 13 Apr 2005, Steve Bonds wrote: > Lester: > > Something like this is very high on my list of products I wish I had. > I frequently use rsync to replicate data on a near real-time basis. > My biggest pain point here is replicating filesystems with many > (millions) of small files. The time rsync spends traversing these > directories is immense. > > There have been discussions in the past of making an rsync that would > replicate the contents of a raw device directly, saving the time spent > checking each small file: > > http://lists.samba.org/archive/rsync/2002-August/003545.html > http://lists.samba.org/archive/rsync/2003-October/007466.html > > It seems that the consensus from the list at those times is that rsync > is not the best utility for this since it's designed to transfer many > files rather than just one really big "file" (the contents of the > device.) > > Despite the fact that the above discussions are almost 18 months ago, > I have seen no sign of the rsync-a-device utility. If it exists, this > might be the solution to what you propose-- and it would work on more > than Linux. > > To achieve your goal with this proposed utility you would simply do > something like this: > > + for each device > ++ make a snapshot if your LVM supports it > ++ transfer the diffs to the remote device > + go back and do it all again > > If the appropriate permissions were in place this could be done > entirely in user-mode, which is a great advantage for portability. As > you touched on in your original message, knowing what's changed since > the last run would be very helpful in reducing the amount of data that > needs to be read on the source side. In my experience, sequential > reads like this, even on large devices, don't take a huge amount of > time compared with accessing large numbers of files. If there were > only a few files on a mostly-empty volume the performance difference > would be more substantial. ;-) > > Another thought to eliminate the kernel dependency is to combine the > inode-walk done by the "dump" utility with the rsync algorithm to > reduce the file data transferred. The inode walk would be > filesystem-specific, but could be done in user space using existing > interfaces. > > -- Steve |
|
From: Lester H. <hig...@10...> - 2006-09-25 17:29:32
|
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 |
|
From: Michal L. <mi...@lo...> - 2006-09-17 11:20:28
|
Hi all,
one of the final steps on the way to mysqlfs-0.3 has been just
committed: the completely rewritten pool.c that isn't limited in a
number of concurrently open connections anymore. Instead of a fixed-size
array I use a dynamic list now with some optimizations to avoid frequent
malloc()s.
Works for me but please test it anyway ;-)
And yes, the mailing lists now work!
Here's the ChangeLog:
2006-09-17 Michal Ludvig <mi...@lo...>
* pool.c: Rewritten from scratch. It doesn't have a limit
on open connections anymore and instead creates new ones
on request. Returned connections are not immediately
closed, instead put into a LIFO-type stack and reused
later. Maximum number of connections idling on the stack
can be set as well as the initial number of connections
opened on start.
This rewrite triggered search-and-replace changes
in mysqlfs.c (no more MYSQL_CONN type). Instead I return
the connection itself (MYSQL*) though typed as (void*) -
probably not the best choice. The intent was to
prepare for support of other DBs. It works for now but
I'll likely improve this later ;-)
Michal
|
|
From: Michal L. <mi...@lo...> - 2006-09-17 10:39:51
|
Hi guys,
> just let me know when you have something commited so I can
> give it some nice testing.
Earlier today I have committed a huge patchset (and a few followups)
that turn mysqlfs into a pretty good shape. Needless to say the DB
schema changed again - however no migration tools are provided as I
don't believe anyone has any valuable data on it yet ;-)
I'm quite confident the code as of now is ready for releasing as
mysqlfs-0.3 however some testing from others will be helpful. I was able
to compile openssl-0.9.8b from tarball on the filesystem. It took good
45 minutes but compiled without problems ;-)
Some known issues:
- no permissions checking - everything is allowed
- connection pooling needs some improvements because when it runs out of
connections it triggers a hard error (not good)
This is from ChangeLog:
2006-09-13 Michal Ludvig <mi...@lo...>
* Splitted table fs into a separate table for directory
tree and a table for inodes. This triggered radical
changes to most parts of the source. However now it's
possible to have hardlinks, delayed unlink and some other
sweeties difficult or impossible to implement with
the previous scheme.
* open() stores inode number in fi->fh and read(), write()
release() and some other functions use that instead
of translating path name to inode every time.
* Updated schema.sql for the new DB layout. No transition
tools from the previous schema are provided because I don't
believe anyone has any valuable data in their FS ;-) If you
do, tar them up, upgrade and untar back again.
* Started migrating the FS logic to mysqlfs.c. In the future
query.c will only have query primitives and we'll perhaps
have query.c files for other DBs as well (Oracle,
PostgreSQL, ...)
* Increased default connection pool to 25 conns.
* Added some plans to TODO list.
* Implemented link(), chown().
* Fixed truncate().
Enjoy and report any reproducible problems ;-)
Michal
|
