headers
Frank Mayhar | 2 Apr 2007 04:38
Gravatar

NFS4 on FreeBSD?

I have a need (or at least a very strong desire) for kerberized NFS on
FreeBSD, at least the client bits.  I sent email to hackers last week
but I thought I would follow up here.  Is there anyone working on this?
Has there been?  I saw a little bit of chatter about the subject on this
list from October of 2005 but nothing since.

It would be really nice if someone has gotten here before me, or at
least has already started working on it.  Anyone?
--

-- 
Frank Mayhar frank <at> exit.com     http://www.exit.com/
Exit Consulting                 http://www.gpsclock.com/
                                http://www.exit.com/blog/frank/
                                http://www.zazzle.com/fmayhar*
_______________________________________________
freebsd-fs <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "freebsd-fs-unsubscribe <at> freebsd.org"
Permalink | Reply | 4 comments |
headers
Dan Cojocar | 2 Apr 2007 11:35
Picon

Re: gjournal error

On 3/30/07, Pawel Jakub Dawidek <pjd <at> freebsd.org> wrote:
> On Fri, Mar 30, 2007 at 02:54:28PM +0300, Dan Cojocar wrote:
> > Hello all,
> >
> > I noticed this error in my logs:
> >
> > GEOM_JOURNAL: [flush] Error while writting data (error=1)
> > ad1s1d[WRITE(offset=512, length=115200)]
> > fsync: giving up on dirty
> > 0xc435910c: tag devfs, type VCHR
> >    usecount 1, writecount 0, refcount 96 mountedhere 0xc41f9900
> >    flags ()
> >    v_object 0xc1048e10 ref 0 pages 2236
> >     lock type devfs: EXCL (count 1) by thread 0xc3f7d6c0 (pid 27)
> >        dev ad1s1e.journal
> > GEOM_JOURNAL: Cannot suspend file system /extra/large (error=35).
> >
> > This is: FreeBSD 7.0-CURRENT #1: Mon Mar 12 17:55:55 EET 2007
>
> Can you paste output of:
>
>         # bsdlabel /dev/ad1s1
>
> ?
>

Here it is:
bsdlabel /dev/ad1s1
                                                        12:32:40
# /dev/ad1s1:
(Continue reading)

Permalink | Reply | 7 comments |
headers
Jim Rees | 2 Apr 2007 14:00
Picon

Re: NFS4 on FreeBSD?

Kerberized nfs does not necessarily mean v4.  But it is starting to look
like v4 might eventually become widely adopted.  The linux, Sun, and IBM
implementations all work and interoperate.

We did a v4 client and it's in the tree now, but sadly neglected.  It would
take some work to make it usable.  Rick Macklem has a server that works
quite well.  I don't know what would be involved in putting it in the tree.

The big thing missing from our client is security (kerberos).  We have a
later client, available on our web site, that does security but it would
need some work too.

No one is working on this right now as far as I know.

http://www.citi.umich.edu/projects/nfsv4/
_______________________________________________
freebsd-fs <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "freebsd-fs-unsubscribe <at> freebsd.org"
Permalink | Reply | 3 comments |
headers
Frank Mayhar | 2 Apr 2007 15:35
Gravatar

Re: NFS4 on FreeBSD?

On Mon, 2007-04-02 at 07:00 -0500, Jim Rees wrote:
> Kerberized nfs does not necessarily mean v4.  But it is starting to look
> like v4 might eventually become widely adopted.  The linux, Sun, and IBM
> implementations all work and interoperate.

Hmm.  It was my impression that the rpcsec_gss stuff was only for NFS4.
I take it that my impression was wrong?  (I guess I had better double-
check and make sure that it's really NFS4 that is needed, and not
kerberized NFS3.)

> We did a v4 client and it's in the tree now, but sadly neglected.  It would
> take some work to make it usable.  Rick Macklem has a server that works
> quite well.  I don't know what would be involved in putting it in the tree.

Yeah, I'm aware of both the v4 client in the tree and Rick's server.  

> The big thing missing from our client is security (kerberos).  We have a
> later client, available on our web site, that does security but it would
> need some work too.

I take it that the later client is a descendant of the one that is in
the FreeBSD tree?  That might be a place to start.  Has it been used at
all?

> No one is working on this right now as far as I know.

Yeah, that much seems clear.  Sigh.  I guess that means if I want it
I'll have to do it myself...
--

-- 
Frank Mayhar frank <at> exit.com     http://www.exit.com/
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jim Rees | 2 Apr 2007 16:00
Picon

Re: NFS4 on FreeBSD?

Frank Mayhar wrote:

  Hmm.  It was my impression that the rpcsec_gss stuff was only for NFS4.
  I take it that my impression was wrong?  (I guess I had better double-
  check and make sure that it's really NFS4 that is needed, and not
  kerberized NFS3.)

That's correct, but there is an earlier non-gss kerberized v3 protocol.  I
believe at one time there were implementations in bsd and linux, but these
are being removed for lack of interest and to push people to v4.  I can't
find any traces of it in FreeBSD but parts of it are still in OpenBSD.  I
have never used it and don't know if it works.

  I take it that the later client is a descendant of the one that is in
  the FreeBSD tree?  That might be a place to start.  Has it been used at
  all?

It was intended to be portable and at one time ran on Darwin, Open, and
FreeBSD.  It was a very clever design by Marius Eriksen, done here at CITI,
that did most of the rpc work in a user daemon without adding unnecessary
user-to-kernel data copies.  No one is using it now as far as I know.
_______________________________________________
freebsd-fs <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "freebsd-fs-unsubscribe <at> freebsd.org"
Permalink | Reply | 1 comment |
headers
Rick Macklem | 2 Apr 2007 16:23
Picon
Favicon

Re: NFS4 on FreeBSD?


On Mon, 2 Apr 2007, Jim Rees wrote:

> Frank Mayhar wrote:
>
>  Hmm.  It was my impression that the rpcsec_gss stuff was only for NFS4.
>  I take it that my impression was wrong?  (I guess I had better double-
>  check and make sure that it's really NFS4 that is needed, and not
>  kerberized NFS3.)
>
> That's correct, but there is an earlier non-gss kerberized v3 protocol.  I
> believe at one time there were implementations in bsd and linux, but these
> are being removed for lack of interest and to push people to v4.  I can't
> find any traces of it in FreeBSD but parts of it are still in OpenBSD.  I
> have never used it and don't know if it works.

That was ancient code that I did for 4.4BSD and was never adopted by
anyone. When people refer to Kerberized NFSv3 these days, they are
using the same RPCSEC_GSS code that NFSv4 adopted. This is in Solaris10
and I believe that current versions of Linux2.6 might have the v3 support
as well as v4. (As far as I know, the only difference between using
RPCSEC_GSS/krb5 on v4 vs v3 is the mount protocol and, at least Solaris10,
will allow the mount protocol to use AUTH_SYS for a sec=krb5 mount.)

So, if you find a Kerberized NFSv3 it will probably support NFSv4 as well.

rick

_______________________________________________
freebsd-fs <at> freebsd.org mailing list
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pawel Jakub Dawidek | 2 Apr 2007 18:12
Picon
Favicon

Re: gjournal error

On Mon, Apr 02, 2007 at 12:35:10PM +0300, Dan Cojocar wrote:
> On 3/30/07, Pawel Jakub Dawidek <pjd <at> freebsd.org> wrote:
> >On Fri, Mar 30, 2007 at 02:54:28PM +0300, Dan Cojocar wrote:
> >> Hello all,
> >>
> >> I noticed this error in my logs:
> >>
> >> GEOM_JOURNAL: [flush] Error while writting data (error=1)
> >> ad1s1d[WRITE(offset=512, length=115200)]
> >> fsync: giving up on dirty
> >> 0xc435910c: tag devfs, type VCHR
> >>    usecount 1, writecount 0, refcount 96 mountedhere 0xc41f9900
> >>    flags ()
> >>    v_object 0xc1048e10 ref 0 pages 2236
> >>     lock type devfs: EXCL (count 1) by thread 0xc3f7d6c0 (pid 27)
> >>        dev ad1s1e.journal
> >> GEOM_JOURNAL: Cannot suspend file system /extra/large (error=35).
> >>
> >> This is: FreeBSD 7.0-CURRENT #1: Mon Mar 12 17:55:55 EET 2007
> >
> >Can you paste output of:
> >
> >        # bsdlabel /dev/ad1s1
> >
> >?
> >
> 
> Here it is:
> bsdlabel /dev/ad1s1
>                                                        12:32:40
(Continue reading)

Permalink | Reply | 6 comments |
headers
Antony Mawer | 3 Apr 2007 00:37

Re: gjournal error

On 3/04/2007 2:12 AM, Pawel Jakub Dawidek wrote:
> On Mon, Apr 02, 2007 at 12:35:10PM +0300, Dan Cojocar wrote:
...
>> Here it is:
>> bsdlabel /dev/ad1s1
>>                                                        12:32:40
>> # /dev/ad1s1:
>> 8 partitions:
>> #        size   offset    fstype   [fsize bsize bps/cpg]
>>  c: 234440625        0    unused        0     0         # "raw" part,
>> don't edit
>>  d: 20971520        0    4.2BSD     2048 16384 28552
>>  e: 213469105 20971520    4.2BSD     2048 16384 28552
> 
> 'd' partition is wrong, it should start at offset 16. You get EPERM
> (error=1) when someone tries to write to first 16 sectors where metadata
> is stored.

This point relates to a recent thread on -questions, where we were 
discussing the offset of 16 and whether it was still relevant. The issue 
arose because disklabel cannot compute the "hog partition" when using an 
offset of 16 -- it (incorrectly) assumes the starting offset is is 0, 
and as a result the last partition goes past the end of the disk.

http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1660728+0+archive/2007/freebsd-questions/20070401.freebsd-questions

What sort of meta-data is typically stored in these first 16 sectors? Is 
it only of concern if you are using some of the various GEOM modules 
that require meta data storage?
(Continue reading)

Permalink | Reply | 1 comment |
headers
Pawel Jakub Dawidek | 3 Apr 2007 01:19
Picon
Favicon

Re: gjournal error

On Tue, Apr 03, 2007 at 08:37:58AM +1000, Antony Mawer wrote:
> On 3/04/2007 2:12 AM, Pawel Jakub Dawidek wrote:
> >On Mon, Apr 02, 2007 at 12:35:10PM +0300, Dan Cojocar wrote:
> ...
> >>Here it is:
> >>bsdlabel /dev/ad1s1
> >>                                                       12:32:40
> >># /dev/ad1s1:
> >>8 partitions:
> >>#        size   offset    fstype   [fsize bsize bps/cpg]
> >> c: 234440625        0    unused        0     0         # "raw" part,
> >>don't edit
> >> d: 20971520        0    4.2BSD     2048 16384 28552
> >> e: 213469105 20971520    4.2BSD     2048 16384 28552
> >'d' partition is wrong, it should start at offset 16. You get EPERM
> >(error=1) when someone tries to write to first 16 sectors where metadata
> >is stored.
> 
> This point relates to a recent thread on -questions, where we were discussing the offset of 16 and whether
it was still relevant. The issue arose because disklabel cannot 
> compute the "hog partition" when using an offset of 16 -- it (incorrectly) assumes the starting offset is
is 0, and as a result the last partition goes past the end of the 
> disk.
> 
> http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1660728+0+archive/2007/freebsd-questions/20070401.freebsd-questions
> 
> What sort of meta-data is typically stored in these first 16 sectors? [...]

Partition table stored by bsdlabel(8).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dan Cojocar | 3 Apr 2007 09:44
Picon

Re: gjournal error

On 4/2/07, Pawel Jakub Dawidek <pjd <at> freebsd.org> wrote:
> On Mon, Apr 02, 2007 at 12:35:10PM +0300, Dan Cojocar wrote:
> > On 3/30/07, Pawel Jakub Dawidek <pjd <at> freebsd.org> wrote:
> > >On Fri, Mar 30, 2007 at 02:54:28PM +0300, Dan Cojocar wrote:
> > >> Hello all,
> > >>
> > >> I noticed this error in my logs:
> > >>
> > >> GEOM_JOURNAL: [flush] Error while writting data (error=1)
> > >> ad1s1d[WRITE(offset=512, length=115200)]
> > >> fsync: giving up on dirty
> > >> 0xc435910c: tag devfs, type VCHR
> > >>    usecount 1, writecount 0, refcount 96 mountedhere 0xc41f9900
> > >>    flags ()
> > >>    v_object 0xc1048e10 ref 0 pages 2236
> > >>     lock type devfs: EXCL (count 1) by thread 0xc3f7d6c0 (pid 27)
> > >>        dev ad1s1e.journal
> > >> GEOM_JOURNAL: Cannot suspend file system /extra/large (error=35).
> > >>
> > >> This is: FreeBSD 7.0-CURRENT #1: Mon Mar 12 17:55:55 EET 2007
> > >
> > >Can you paste output of:
> > >
> > >        # bsdlabel /dev/ad1s1
> > >
> > >?
> > >
> >
> > Here it is:
> > bsdlabel /dev/ad1s1
(Continue reading)

Permalink | Reply | 3 comments |

Gmane