When server reboots again when share reservations or locks are being
reclaimed there is a risk that HandleErrors will invoke Reclaim(( again
making it crash due to some double locks and more importantly making
these two attempts to reclaim resources conflict and cause some much harder
to recover from server errors.
Instead all that, when server is rebooted again while recovering from previous
reboot the recovery is aborted, the client retries its original request and
then proper recovery occurs completly on a new server instance.
There are some NFS4 error codes we should not get if the client is operating
correctly.
CLID_INUSE may be caused only by incorrectly generated SETCLIENTID request.
NOFILEHANDLE, RESTOREFH and OP_ILLEGAL indicate that the client has sent
an incorrectly build request.
BAD_STATEID and BAD_SEQID indicate a bug in handling {open,lock}_owners.
LOCK_HELD happens when the client incorrectly cleans up after accessing a file.
* Inode::ReadDir missed an entry when given buffer was too small
* Each OpenDirCookie now has its own copy of directory snapshot what
would prevent Inode::ReadDir from accessing freed memory when removing
files and reading directory entries simultaneously
* Several minor issues fixed
VnodeToInode is another abstraction layer between VFS vnodes and NFS nodes.
It simplifies dealing with race conditions as well as faking some guarantees
VFS expects but NFS does not provide.
* copying the time attributes was fixed to copy the whole
st_?tim timespec struct but the allocation size was still only
that of st_?time subfield, which is only a time_t.
Signed-off-by: François Revol <revol@free.fr>
Signed-off-by: Pawel Dziepak <pdziepak@quarnos.org>
If the underlying file system reuses inode numbers it is possible that
an entry of inode with reused id in InodeIdMap will be removed.
This patch should also improve behavior when one of many hard links
is removed.
