From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 30 12:46:11 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 673FF106566C for ; Mon, 30 Mar 2009 12:46:11 +0000 (UTC) (envelope-from aram.h@mgk.ro) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by mx1.freebsd.org (Postfix) with ESMTP id A79138FC19 for ; Mon, 30 Mar 2009 12:46:10 +0000 (UTC) (envelope-from aram.h@mgk.ro) Received: by fxm11 with SMTP id 11so1856211fxm.43 for ; Mon, 30 Mar 2009 05:46:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.8.84 with SMTP id g20mr1950832bkg.162.1238417169527; Mon, 30 Mar 2009 05:46:09 -0700 (PDT) In-Reply-To: <49D00B16.20507@freebsd.org> References: <49D00B16.20507@freebsd.org> Date: Mon, 30 Mar 2009 15:46:09 +0300 Message-ID: From: Aram Havarneanu To: Tim Kientzle Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: Shared Disk/Transactional/Distributed file system (GSoC Proposal) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 12:46:12 -0000 2009/3/30 Tim Kientzle : > 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