Zumastor Google Group

Re: RHEL5 2.6.18 support?

2008-09-04T13:42:08Z

I tried the -X option but it made minimal difference.

Okay cool. Like I said the way it works suits my needs very well but
the performance is still too poor for production use. I still don't
fully understand why the snapshot device is writing around x4 times
more data to it per second than is being written to the origin device.

Re: RHEL5 2.6.18 support?

2008-09-03T02:40:17Z

Hi Daire,
You can try the "--experimentail|-X" option of 'ddsnap server' command
and see if it helps the perfornace. You need the current trunk code to use
that
option. I don't think we add the support to enable this option in zumastor
yet. So you need to change the /bin/zumastor code your self.
We havent done a lot of performance testing with 2.6.18 kernel, so

Re: RHEL5 2.6.18 support?

2008-09-01T11:13:04Z

Jiaying,

I finally got some time to do some testing and benchmarking. All in
all the zumastor scripts and associated cronjobs seem to be fairly
stable at actually making and rotating the snapshots. I added a few
lines of code to the zumastor cronjob to correctly setup Lustre
snapshot filesystems and that also seem to work well. The main problem

Re: Python protype rewrite of Zumastor bash script

2008-08-31T00:34:12Z

I don't have a strong opinion either way. I think they're both fine. At some
point I suspect someone will want a C version for putting this on an
embedded system, but I don't think that's the current biggest concern.

Re: Python protype rewrite of Zumastor bash script

2008-08-30T21:19:00Z

Right. I regard creating a library as premature, and the question of
which language to rewrite the Zumastor commands in should not be tied
to which language a future library should be written in (which will no
doubt be C).
Truth be told: I detest both C++ and Python. And C. And I love them
all too. I don't let my emotions get in the way of deciding which to

Re: Python protype rewrite of Zumastor bash script

2008-08-30T19:28:23Z

I didn't bring up the idea of having a library. As I recall you did, but
there was some discussion of what language to do it in. Jeff threw in that
if you're going to write a library it should be done in C.
With the exception I noted, he's right. If you're going to have a library,
the point is to open that functionality up to other programs... but if you

Re: Python protype rewrite of Zumastor bash script

2008-08-30T03:29:57Z

Let's try to get this headed in a concrete direction. How about giving
me a couple of C prototypes for functionality you would like to have
available to you in a C library.
You will want to consider how your library will implement the interface:
by sending messages over a socket using the ddsnapd messaging protocol.

Re: Python protype rewrite of Zumastor bash script

2008-08-29T23:46:40Z

Well, library interfaces should always be in C. There are sometimes
convincing reasons to write a lib in C++, but you have to provide a C
interface. This isn't very simple, so I don't recommend doing it without a
reason. But, for example, I do this in concordance (libconcord specifically).

Re: Python protype rewrite of Zumastor bash script

2008-08-29T02:36:06Z

Moral of the story, don't use swig. Here is an example of a proper way
to write
bindings to a C library:
[link]

Nathaniel converted the existing augeas python bindings to that in ~2
hours to
teach me how it was done. Now your swig complaint is completely

Re: Python protype rewrite of Zumastor bash script

2008-08-23T22:34:37Z

My thinking exactly. When development starts to slow down (because
members start to run out of ideas for new major functionality) then
tracking the python prototype gets much easier. For the moment, only
the filesystem structure and command line syntax really matters. When
it comes time to make real libraries that could change and it could be

Re: Python protype rewrite of Zumastor bash script

2008-08-23T21:10:54Z

Agreed
Problem is not "translating" Python to C++ *this time* but keeping the
C++ "port" up-to-date, and the new bugs introduced (or maybe fixed!)
when porting to C++. Automatic translators like Shed Skin (
[link] ) might help but, fortunately,
machines cannot do our job, thus some manual work would be needed.

Re: Python protype rewrite of Zumastor bash script

2008-08-23T20:14:10Z

Point. There are a few other negatives for Python for me as well:
performance sucks by up to a factor of 200 vs C++ unless the app uses
something else for its low level operations, then you have to consider
the grossness of swig-generated code etc. Scoping rules in Python are
just plain wrong. Compile to native works, but the binaries are pretty

Re: Python protype rewrite of Zumastor bash script

2008-08-23T13:07:13Z

The only thing I don't like about using Python instead of C++ (apart
from me being a Ruby guy :-) is the memory footprint. NAS appliances
are usually tight on RAM (IIRC Linksys NSS4000 and 6000 series only
have 32 MB of RAM).

Python protype rewrite of Zumastor bash script

2008-08-23T07:53:25Z

There are as many opinions about programming languages as there are
programmers. But I think everybody agrees that Bash is the wrong
language for Zumastor to be written in. It was great for a quick
prototype - I wrote the original in three days, including figuring
out how it should work and the format of the database. After two

Re: Snaplist package

2008-08-18T15:30:50Z

Ok. Here is the final version with support for Zumastor local, NetApp, CIFS
and ZFS snapshots mechanisms + improved comments a bit + added couple of
sentences for design architecture.
On Sun, Aug 17, 2008 at 12:53 PM, Mladen Djordjevic <