Commercial libraries are a pain ...
If we want the more permossive licence offered by callback file system
we have to buy it for 20.000 usd. Then we will have to provide a backbox
that we have no control upon and that will kill our product anytime they
want anf if they decide to stop their commercial activity we will be in
the same situation that with dokanfs but without having the source code
of the black box. If i have to spend 20 000 dollars i would prefere
paying someone to retake dokanfs or to write from scratch a dokanfs
fuselike software make it all shiny and pumpy fantastic and ready to
plug to ceph client.
I would prefere if people have to pay something to get access to
ceph4win that this money goes in ceph main branch pockets... Or as a
gift you donante to ceph 10 dollars you get 2 free registration codes
for ceph4win... or something like that.
If ceph4win as to be comercial then I would prefer delegate the task to
a company like south river technologies and their great product
webdrive. I would mininaly get involved in that project and simply buy
the final product to sell it together with my ceph based product (which
could be a calxeda ceph box or something like that).
I m open anyway to any proposition. But I doubt that callback filesystem
offers us a suitable solution in the way I see ceph4win to be spread and
used... I m maybe wrong. And anything that will be done around ceph4win
will be public documented etc... And licensed the way that if someone
want to build a commercial solution on top of it, that would be a
possibility.
My idea is to giveback somehow to ceph project and at same time forge a
better knowledge in ceph technologies. Because like many in libre world
I think the business is in the services around the software more than on
the software. That the ones writing code should be financed and benefits
from the one selling and giving support of the software at all levels. I
m probably too idealistic. And too optimistic after all I m the one
saying I will do this stuff I have no idea how but well it is
interesting and fun so lets do it.
Regards,
P.S: using commercial backend libraries appart including their own cost
will force you to use commercial IDE like MS VisualStudio because their
library has some kind of drm that only that IDE compiler can use. So
alot of cost and yet there is nothing done. If I had to open a
kickstarter project saying we need 60 000 USD to do ceph4win with that
monney we will buy the right to use and share a commercial copyrighted
library but abandonned punctually to us in public domaine and that we
will eventually produce something out of it. I doubt I will get a dollar.
We still can suggest the idea to Edlos the commercial company that has
the copyright of Callback FS, Or to buy them their product in a blender
way (blender was bought with donation before being put opensource and
public domaine), Or to open source their library. But in commercial
minds opensourcing = death of their technical advantage and death of
their marketing strategy. They will have to invent something more to
retrieve monney from it.
El nov 6, 2013 11:22 p.m., "Ketor D" <d.ketor@xxxxxxxxx
<mailto:d.ketor@xxxxxxxxx>> escribió:
Hi Alphe,
I think you could try Callback Filesystem dev framework. It
is a commerical dev framework and is maintained by Edlos today.
I have communicated with Edlos to get a try code for
development. To dokan, Callback Filesystem has vary document and maybe
more stabilize.
Regards.
On Thu, Nov 7, 2013 at 10:00 AM, Alphe Salas <asalas@xxxxxxxxx
<mailto:asalas@xxxxxxxxx>> wrote:
> Hello ketor thank you for your interest un ceph4win. Since muy
first mail I
> exposed the lacks of dokanfs and that I m far from being a
specialist un
> filesystems.
> I exposed what i like un dokanfs bit I not a fanátic of it. Muy
goal is to
> have something working quickly.
>
> So I am up to any proposición sure the one with the more docs and
support
> will be the best choice. As for right now what I need is
understand what are
> the files involved what are the interfaces functions and what are
the needed
> library dependencies and if they exist ported to windows with
cygwin. And
> all that is retrieved from source code.
>
> Regards.
>
> El nov 6, 2013 10:34 p.m., "Ketor D" <d.ketor@xxxxxxxxx
<mailto:d.ketor@xxxxxxxxx>> escribió:
>
>> Hi Alphe,
>> We are taking an interest in your work on Ceph Client for
Windows
>> with Dokan.As we know, the performance of Dokan is not very
good, and it's
>> abandoned 3 years ago.
>> I have learned and used OpenDedup(SDFS) for a long time.
OpenDedup
>> has a Dokan version. And the author of OpenDedup said
>>
>> The Dokan library is quite flakey and testing should be
performed before
>> putting into production
>>
>> So what do you think about this? And if there is another
solution of
>> fuse-like filesystem dev framwork on Windows?
>>
>> Best Wish!
>>
>>
>>
>> On Thu, Nov 7, 2013 at 5:47 AM, Alphe Salas Michels
<asalas@xxxxxxxxx <mailto:asalas@xxxxxxxxx>>
>> wrote:
>>>
>>> Hello I created the github repository for this project
>>> https://github.com/alphe/Ceph4Win
>>>
>>> Regards,
>>>
>>> signature
>>>
>>> *Alphé Salas*
>>> Ingeniero T.I
>>>
>>> asalas@xxxxxxxxx <mailto:asalas@xxxxxxxxx>
>>> *<http://www.kepler.cl>*
>>>
>>> On 11/05/13 21:00, Sage Weil wrote:
>>>>
>>>> Hi Alphe,
>>>>
>>>> On Tue, 5 Nov 2013, Alphe Salas Michels wrote:
>>>>>
>>>>> signature *Hi, Sage !
>>>>> thank you for you enthousiast reply.
>>>>> I sure want to make the best use of everything or anything
previously
>>>>> done to
>>>>> tend to
>>>>> write ceph cliente for windows.
>>>>>
>>>>> Apart using libre tools for building the future ceph cliente
I am open
>>>>> to
>>>>> anything.
>>>>> I would recommand eclipse CDT or Code::BLocks they are based
on mingwin
>>>>> open
>>>>> and easyly enhanceable.**
>>>>>
>>>>> more free tools can be found here:
>>>>> http://www.freebyte.com/programming/cpp/#cppcompilers
>>>>>
>>>>>
>>>>> I will read libcephfs source code and take some notes about the
>>>>> protocol.
>>>>
>>>> I think you don't need to worry about hte protocol at all, since
>>>> libcephs
>>>> implements it for you (and will capture any future changes).
>>>>
>>>>> I was more going from what I know and trying to track down how
>>>>> mount.ceph work
>>>>> with the parameters passed to it.
>>>>> since it point finally to Kernel/fs/ceph and that I don t really
>>>>> understand
>>>>> how that module work and that it probably points to some other
>>>>> dependencies
>>>>> Reading libcephfs source code could be a big gain of time.
>>>>
>>>> (I would also ignore mount.ceph as everything it does it
specific to
>>>> how Linux mounts work.)
>>>>
>>>>> basically on the protocol what is need are:
>>>>>
>>>>> 1) open and maintain a connection (socket open, auth, etc )
>>>>> 2) retreive a map of directories and disk Quota (disk sizing
Y TB free,
>>>>> Z TB
>>>>> total)
>>>>> 3) procedure to send files / directories in a maner that it
will allow
>>>>> our
>>>>> client to fit ceph transmission protocols
>>>>> (limit bandwith for stability?, limit connection amount?,
limit cpu
>>>>> use?,
>>>>> Cache for preparing data transfer (a FIFO cache)?)
>>>>> 4)Procedure to retreive files / directory from ceph cluster
>>>>> 5) Management copy/move files /Directories, FS stats,
Connection Stats.
>>>>> logging.
>>>>>
>>>>> My idea to progress is to take those main bulletpoint in ceph
protocol
>>>>> based
>>>>> on general ideas of what ceph file system does and start
identifying
>>>>> parts
>>>>> from libcephfs to match those "needs".
>>>>
>>>> Instead, I would look at include/cephfs/libcephfs.h, the
interface that
>>>> libcephfs provides, and try to map that to what the fuse layer
expects.
>>>> There is both a path-based that I suspsect lends itself well
to the
>>>> Windows interface and (very soon now) a handle based API that is
>>>> targetted
>>>> at the Unix-style VFS layers. I'm mostly guessing, though,
since I've
>>>> never seen any low-level fs code in windows before.
>>>>
>>>> In this case, the analogous code for Linux should be
client/fuse_ll.cc
>>>> itself (and not much else), although there will probably be a
few tricks
>>>> necessary to map cleanly onto how the windows interfaces work.
>>>>
>>>> Does that make sense?
>>>>
>>>> Cheers!
>>>> sage
>>>>
>>>>
>>>>> Any suggestion and contributions are welcome.
>>>>>
>>>>>
>>>>> *
>>>>> On 11/05/13 11:23, Sage Weil wrote:
>>>>>>
>>>>>> Hi Alphe,
>>>>>>
>>>>>> On Mon, 4 Nov 2013, Alphe Salas Michels wrote:
>>>>>>>
>>>>>>> Good day developers!
>>>>>>>
>>>>>>> I would like to propose to the one interested work with me to
>>>>>>> develop a
>>>>>>> ceph
>>>>>>> cliente for MS windows world, Basing us on dokanFS.
>>>>>>>
>>>>>>> My company is a ceph enthousiast that use on a dayly basis
ceph and
>>>>>>> that
>>>>>>> need
>>>>>>> both transfer speed and big expendable and cheap storage.
>>>>>>> My company is specialised in data recovery and we want to
participate
>>>>>>> to
>>>>>>> ceph
>>>>>>> effort by bringing a ceph cliente for windows.
>>>>>>
>>>>>> Awesome!
>>>>>>
>>>>>>> Our experience shows us that the best gateway is each
clientes being
>>>>>>> its
>>>>>>> own
>>>>>>> gateway, instead of having a bottle neck server or a cluster of
>>>>>>> bottle
>>>>>>> neck
>>>>>>> servers as gateway (FTP, samba, SFTP,webdav, s3, etc..).
>>>>>>>
>>>>>>> We already did some research in that domain.
>>>>>>>
>>>>>>> Dokan FS is an intent to write an opensource fuse like
cliente for
>>>>>>> MS
>>>>>>> windows.
>>>>>>>
>>>>>>> More information on DOKANFS can be triggered here
>>>>>>> http://dokan-dev.net/en/download/
>>>>>>>
>>>>>>> Positive points of using DOKANFS.
>>>>>>>
>>>>>>> - its opensourced and well licenced mit licence, gpl
licence and lgpl
>>>>>>> licence.
>>>>>>>
>>>>>>> Negative point of using DOKAN FS.
>>>>>>> - unreachable author
>>>>>>> - Poor documentation . Dev comments in japanese.
>>>>>>> - Work in progress so it is unstable and needs to be updated,
>>>>>>> debugged and
>>>>>>> maintained by a MS Windows file system expert developper.
>>>>>>
>>>>>> I am not very familiar with windows storage APIs, but
somebody told me
>>>>>> at once point there were several interfaces against which a
new file
>>>>>> system could be implemented, everything from a full
in-kernel driver
>>>>>> to
>>>>>> something that is explorer-based. Are any of those
suitable? Using a
>>>>>> potentially abandoned fuse-like layer makes me a bit nervous.
>>>>>>
>>>>>> That said,
>>>>>>
>>>>>>>
>>>>>>> I try past year to do a merge from ceph-fuse to dokanfs
>>>>>>> here are what I learnt.
>>>>>>> - Ceph-fuse and related source code is around 60 000 lines
of code.
>>>>>>> - Ceph protocol isn t documented so it is like trying to
draw a map
>>>>>>> of
>>>>>>> america
>>>>>>> using only a sextan and a compass.
>>>>>>>
>>>>>>> Those led me to those conclusions:
>>>>>>> - I can t do it alone.
>>>>>>> - It is easier to draw down the ceph protocol way to work from
>>>>>>> kernel/fs/ceph
>>>>>>> sources and mount.ceph
>>>>>>> - Ceph depending libraries may be unexistant or not up to
date in
>>>>>>> their
>>>>>>> port
>>>>>>> on MS Windows (cygwin)
>>>>>>
>>>>>> I think the most sane path should be to make libcephfs
sufficiently
>>>>>> portable to build on windows (or cygwin). For the bits used
by the
>>>>>> client-side coe, I don't think there should be much in the
way of
>>>>>> dependencies, and the main challenge would be untangling the
build for
>>>>>> the necessary pieces out from the rest of Ceph.
>>>>>>
>>>>>> Have you seen the wip-port portability work that is
currently underway
>>>>>> by
>>>>>> Noah and Alan? That may solve many of the cygwin problems
you are
>>>>>> seeing
>>>>>> today.
>>>>>>
>>>>>>> - MS file system specialist are hard do find in the "open
source
>>>>>>> libre
>>>>>>> world"
>>>>>>> so I will try in the commercial world.
>>>>>>>
>>>>>>> The commercial world has some problems too. They need ceph
protocol
>>>>>>> draft
>>>>>>> to
>>>>>>> implemente it to their own product They will have licencing
>>>>>>> /commercial
>>>>>>> politics that infringe lgpl, and hide that most of the work
is done
>>>>>>> by
>>>>>>> people
>>>>>>> other than them. They will not participate in a financial
way to ceph
>>>>>>> enhancement and growth.
>>>>>>
>>>>>> I don't think reimplementing the client code is an efficient way
>>>>>> forward.
>>>>>> Unless the goal is a pure kernel implementation...but a
significant
>>>>>> ongoing investment in development resources would be needed
for that
>>>>>> going
>>>>>> forward. I suspect that is a challenge for a platform that
does not
>>>>>> typically rally that sort of community effort.
>>>>>>
>>>>>> The easiest thing is of course just to use CIFS and Samba
(which works
>>>>>> today). A fuse-like approach is probably a reasonably
middle ground
>>>>>> (both
>>>>>> in initial effort and maintainability going forward)...
>>>>>>
>>>>>> sage
>>>>>>
>>>>>>
>>>>>
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe
ceph-devel" in
>>> the body of a message to majordomo@xxxxxxxxxxxxxxx
<mailto:majordomo@xxxxxxxxxxxxxxx>
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>>
>
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
