On 4/10/2012 7:32 PM, Calvin Owens wrote:
On 04/09/2012 07:34 PM, David Quigley wrote:
On 04/09/2012 20:27, Calvin Owens wrote:
On 04/05/2012 10:17 PM, Myklebust, Trond wrote:
On Thu, 2012-04-05 at 19:03 -0500, Calvin Owens wrote:
Hello all,
I'm interested in implementing the draft specification for NFS v4.2
as a
Google Summer of Code project. That includes server-side copying,
sparse
files, and carrying fadvise() calls through to the server, among other
things.
The current document can be found here:
http://tools.ietf.org/html/draft-ietf-nfsv4-minorversion2-07
Is this something that you need to be done? If so, I'd very much
like to
be involved. :)
Hi Calvin,
Labelled NFS is likely to be merged into 3.5 (if Dave Q finds the time
to port his existing code).
Copy offload already exists in prototype form. The main remaining issue
is working out the user syscall interface, which really requires
getting
all the interested filesystem maintainers to agree (we've started on
doing that).
If you'd like to contribute, then I'd suggest looking into SEEK (for
providing lseek(SEEK_HOLE/SEEK_DATA) support. There is also the hole
punching/space reservation, that should fit nicely into the fallocate()
system call.
Yes, that sounds good. I'll start looking into that.
The efficient sparse file read and fadvise support might be nice too,
but I'd like to see numbers for how they improve matters before I feel
comfortable saying yea or nay to adding those specific features.
I definitely see your point. It does seem to be a lot of added
complexity for a negligible benefit.
Note that there are also a bunch of NFSv4.1 features that have yet
to be
implemented, so the above list of tasks is not exhaustive. I'd be happy
to work with you to find something...
What else, precisely, would you like to get done? I need to get some
more detailed objectives to put into my application. (Forgive me for
so blatantly not looking myself, but it seems more efficient than me
digging through the code finding missing features and lobbing them at
you for approval, when I'm sure you know exactly where your priorities
are...)
Thanks very much,
Calvin Owens
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Finishing up the port of Labeled NFS would be some low hanging fruit if
someone wants to help tackle it. I'll be trying to find time to work on
it but its unclear how soon I'll be able to get around to it.
Dave
Okay. I took a look at your lnfs git tree - just to make sure I
understand: the patchset was originally against 2.6.33, and you're
working to make it apply to the current kernel, with the same
functionality? And stuff has changed enough since then that it's not
trivial? Or am I completely missing the point?
Thanks,
Calvin Owens
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Sorry I somehow completely missed this email. The latest tree should be
against 3.2 or something like that. Currently there is an issue where I
couldn't port one of the parts over in lookup (see a previous email I
sent to trond on list for the details). Once that issue is fixed I would
assume the forward port to 3.5 would be mostly trivial.
The Labeled NFS tree is managed as two git trees for people's
convenience. The tree listed first below [1] is the guilt patch set
which I keep track of. The second tree is a git tree which has had the
patches applied to it[2]. The tree currently has a v3.2-lnfs branch
which needs the one fix figured out. The way I do development is to
check out the kernel tag and the patch-set and just work from there.
Another issue is that currently, SELinux is really the only thing you
can use to test Labeled NFS. I have a setup script which should give a
small test environment to mess around with as well. If you're not
familiar with SELinux I can help you with that part as well.
If you find this interesting and want to try to fix the issue and do the
forward port I'd be glad to help you. It would be nice to get these
changes upstream.
[1]
http://git.selinuxproject.org/git/?p=users/dpquigl/lnfs-patchset/.git;a=summary
[2] http://git.selinuxproject.org/git/?p=users/dpquigl/lnfs/.git;a=summary
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html