- User Since
- Jan 13 2015, 10:58 PM (301 w, 4 d)
Fri, Oct 23
Added asomers@ in case he'd like ot review this.
Seems ok to me.
There have already been commits that changed this
output format and no one has reported problems
because of that.
As such, I don't think this format change will
cause people problems.
Tue, Oct 20
This patch has been committed as r365703. It didn't get automatically
closed for some reason.
Mon, Oct 19
Tue, Oct 13
Fix a bug where the sig_mask being used as the
argument to sigsuspend() was set to the wrong
bits, where SIGHUP was blocked.
Mon, Oct 12
Sat, Oct 10
Fri, Oct 9
Sun, Oct 4
Updated with changes as suggested by kib@ and freqlabs@.
Fri, Oct 2
Use the variant of sig_intr() in D26628.
Thu, Oct 1
Well, when I looked at a wireshark trace of copying a 1Gbyte file,
it turns out that it is the Commit RPC (the one that does VOP_FSYNC())
that takes the time and not the Copy RPC, so using time on the
Copy RPC is useless.
Wed, Sep 30
Updated the inline comments.
Made the changes suggested by asomers@
Tue, Sep 29
Change the blksize test to handle the special case
where _PC_MIN_HOLE_SIZE is returned as 1.
As well as asomers@ suggested change, I also
changed the blksize code just below it.
Use rounddown() as suggested by asomers@.
Fixed the calculation to take *inoffp into account,
as suggested by asomers@.
Mon, Sep 28
Add a check for len being clipped down to 0.
No sense in doing the VOP call for this case.
Change handling of a wrap around of *outoffp + len
to clip "len" instead of return EINVAL.
Although there is no explicit statement in the NFS
RFCs indicating an upper limit on an RPC response
time, the assumption is that the server will reply
in a "reasonable time".
--> I think 1second is a reasonable time limit,
although some might argue it should be less than that.
--> In NFSv4.2, a client can optionally specify the
Copy operation be done "asynchronously", where the server replies to the Copy RPC when it is started and then does a server->client callback to notify completion. I have not implemented that, since I believe that the Linux server only does this for Copies between servers, which FreeBSD does not know how to do. Without the "asynchronous" option , the Copy time needs to be limited to ensure a "timely" RPC reply.
The problem with using the "check for signals" approach
is that it won't work for the NFS server.
--> The NFS server will still need the 1sec timeout.
The VOP call can probably get away with using a
kernel only "flags" bit to indicate whether it should
use "1sec" vs "signal pending", but I'm not sure
if such semantics is overkill (the overhead of doing
1 syscall/sec isn't particularly high for a copy
Do others think this extra complexity is worth it?
Ok, so I have no idea how to do that.
Sat, Sep 26
Sep 25 2020
Sep 24 2020
Sep 23 2020
Looks fine to me, but I've never had anything to do
with this code.
I think trasz@ was the author of the nfsv4 acl code,
so you might want to ask him?
Sep 22 2020
Sep 21 2020
Sep 19 2020
Added a STANDARDS section, as suggested by gbe@.
Sep 18 2020
Sep 17 2020
Sep 16 2020
Sep 15 2020
Added some replies to inline comments.
Sep 14 2020
Sep 10 2020
Sep 6 2020
Interesting. SetClientID arguments are roughly:
A) - an identifier string (that should never change for a given client)
B) - a verifier that should change whenever the client looses state information
(usually a reboot)
C) - a host IP address for the server to use to do a connection to the
client for callbacks
Well, you are correct, in that other callers may
need similar fixes. (ie. Should never be called if
the ClientID is unconfirmed.)
--> For NFSv4.0, the only two are CBRECALL, to
recall a delegation. This occurs when a conflicting open occurs and the check in nfsrv_checkopen() should be sufficient. CBNULL, which is done during confirmation to check for a callback path. (Again handled by the current code, since it is done after the LCL_NEEDSCONFIRM flag is cleared with the global exclusive lock held.
--> There are Layout related CBs in NFSv4.1, but
since those use an established connection with a session, I think they are ok, but I will take a look.
Sep 5 2020
Sep 4 2020
Sep 3 2020
Modify the entry to be NFS specific and add a comment
w.r.t. where it is handled, per inline comment.
Although it is not really NFS specific, NFS is probably the
only use case that will happen in my lifetime, so define
it as NFS specific and comment w.r.t. where it is handled.
Sep 2 2020
Change the daemon's name from rpctlscd to rpc.tlsclntd
to avoid confusion with the server side daemon.
Rename rpctlssd to rpc.tlsservd, since that seemed to
be the preferred name for the daemon and this
hopefully will avoid confusion with the one for
the client side.
Sep 1 2020
Remove "the" and "daemon" as suggested by bjk@
for the exports.5 patch.
Replied to inline comment and asked if rpc.tlssd would be preferable
Take "the" and "daemon" out as suggested by bjk@.