Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 30 Mar 2009 15:46:09 +0300
From:      Aram Havarneanu <aram.h@mgk.ro>
To:        Tim Kientzle <kientzle@freebsd.org>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: Shared Disk/Transactional/Distributed file system (GSoC Proposal)
Message-ID:  <be00cc30903300546n4e50d66bkd97da22be8a38673@mail.gmail.com>
In-Reply-To: <49D00B16.20507@freebsd.org>
References:  <be00cc30903291529v4862b53bs93414a86bad77430@mail.gmail.com> <49D00B16.20507@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
2009/3/30 Tim Kientzle <kientzle@freebsd.org>:
> Aram Havarneanu wrote:
>>
>> I have been giving some thought lately on some ideas I would like to
>> do for Google Summer of Code. I haven't posted my application yet, as
>> I hope to get some feedback first.
>
> An interesting idea, but it sounds much too
> ambitious for a six-week summer project.
>

You are right of course, this could not be done in the required time.

> There are a couple of proposals on the FreeBSD
> Summer of Code site [...]

Oh yes, I read them all, it's just that I had this idea for some time,
and I wished to implement it one way or another on some system that I
like.

> Of course, a lot depends on your particular
> background. =A0You didn't say how much work of
> this sort you'd done in the past.
>

Well, I didn't do file system work in the past, if that's what you are
asking. I started programming about 8-9 years ago, and I mostly did
low-level C stuff ever since. Started with DOS, quickly got rid of
that problem, moved to Linux where I learned most of what I know about
UNIX userland stuff, didn't like Linux for kernel work for reasons I
won't detail here, moved to Windows, did various stuff both in the
userland and in the kernel, started doing stuff in Windows for money
(like 2 years ago), started doing stuff in Solaris, BSD and recently
Mac OS X. I always found kernel programming much challenging then
userland stuff and I never really cared about the really high level
programming stuff. Writing assembly code to make hardware work is
something that I enjoy, writing GUI applications is something I hope
I'll never do again.

Actually I would prefer to do some driver work to improve hardware
support in FreeBSD instead of all this file system thing, but I'd need
hardware I don't have, so that's out of the question.

I would like to do that EFI boot project, because that's something I
would want for myself, but I only have 1 EFI machine and I can't
afford to do development work on it because I need it for something
else.

Regarding the original problem, I propose a much simple implementation
using ZFS. Database people want transactional (asynchronous) record
oriented I/O. Well... probably depends on what database people you
ask, because some would say synchronous I/O is imperative (that is why
there is ZIL in the ZFS stack, isn't it?) and others will say the
opposite thing. Anyway, you can always do SYNC I/O if you need it or
want to, so I see the ASYNC I/O feature as plus, because some people
will benefit and the others won't be affected.

So, as I was saying, using ZFS makes the problem much simpler because
ZFS already has transactional capabilities (layers around DMU) and ZFS
does all the storage management for free (in the pooled storage
layer). All you need to do is to write something in the Interface
Layer. The current interfaces are ZPL, the POSIX layer hooked in the
VFS, ZVOL and /dev/zfs. Only ZPL is used by the general public.

What I propose is a new interface (akin to ZPL in some respects) but
not hooked in the VFS (well, some degree of POSIX I/O maybe would
help). This would export some syscalls for use by database consumers.
I hope I could model the thing after OpenVMS APIs.

What do you think of this idea?

Thanks,

--=20
Aram H=E3v=E3rneanu



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?be00cc30903300546n4e50d66bkd97da22be8a38673>