Date: Thu, 1 May 2014 00:20:49 +0200 From: Rainer Duffner <rainer@ultra-secure.de> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: FreeBSD Filesystems <freebsd-fs@freebsd.org> Subject: Re: RFC: using ceph as a backend for an NFSv4.1 pNFS server Message-ID: <C82C001C-2049-45B0-AF5A-EFD38F0E3DEE@ultra-secure.de> In-Reply-To: <507714298.1684844.1398541651089.JavaMail.root@uoguelph.ca> References: <507714298.1684844.1398541651089.JavaMail.root@uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
Am 26.04.2014 um 21:47 schrieb Rick Macklem <rmacklem@uoguelph.ca>: > Hi, > > The non-pNFS v4.1 server in the projects area is just about ready > for head, I think. However, without pNFS, NFSv4.1 isn't all that > interesting. The problem is that doing a pNFS server is a non-trivial > exercise. I am now somewhat familiar with pNFS (from doing the client > side), but have no expertise w.r.t. cluster file systems, etc. > > For those not familiar with pNFS, the basic idea is that the NFSv4.1 > server becomes a metadata server (MDS) and hands out what are called > layouts and devinfo, so that the client can access data server(s) (DS) > to read/write the file. There are RFCs that define both block/volume > (using iSCSI or similar) and object (using something called ODS2). > > Although I suspect there are many ways to do a pNFS server, I think > that building it on top of a cluster file system may be the simplest. > > So, this leads me to... > At a glance (just the web pages, I haven't looked at the source), > it appears that ceph might be useful as a backend to a pNFS server. The guys at RedHat probably also believe in its usefulness: http://www.redhat.com/about/news/press-archive/2014/4/red-hat-to-acquire-inktank-provider-of-ceph I’m not sure if this will make it harder to port or easier. ;-) Maybe this is something the FreeBSD Foundation should support? Of course, someone who can actually pull-off the port (and maintain it) has to come forward first… That’s actually one of the things I consider the worst outcome: a one-off porting effort that isn’t maintained and can’t really be used in production.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C82C001C-2049-45B0-AF5A-EFD38F0E3DEE>