Hi folks,
I found that the Linux user-space NFS server (unfsd) fails
for setattr requests against the kernel 2.6.22 and later.
For instance, it returns an invalid argument error when
overwriting an existing file by dd command as follows.
# mount -t nfs server:/pub /nfs
# dd if=/dev/zero of=/nfs/aaa bs=4k count=1
1+0 records in
1+0 records out
4096 bytes (4.1 kB) copied, 0.000462054 seconds, 8.9 MB/s
# dd if=/dev/zero of=/nfs/aaa bs=4k count=1
dd: opening `/nfs/aaa': Invalid argument
I found out this is caused by the following two reasons.
(1) Since kernel 2.6.22, range checks of utimes() system call
got more strict by an utimensat related patch
(1c710c896eb461895d3c399e15bb5f20b39c9073)
(2) Linux NFS client uses a Sun convention for "set to current
sever time" in which an invalid value useconds=1000000 is
passed to server. However, unfsd tries to use it as-is
for changing timestamp of requested files through the
utimes() system call.
This patch fixes the problem by adding the Sun convention
support to unfsd.
Best regards,
---
Ryusuke Konishi <[email protected]>
Index: nfs-user-server-2.2beta47/setattr.c
===================================================================
--- nfs-user-server-2.2beta47.orig/setattr.c 2007-08-09 17:55:14.000000000 +0900
+++ nfs-user-server-2.2beta47/setattr.c 2007-08-09 21:33:54.000000000 +0900
@@ -16,6 +16,7 @@
#include "nfsd.h"
#define IGNORE_TIME ((unsigned int) -1)
+#define SET_SERVER_TIME 1000000 /* Sun convention for "set to current server time" */
/*
* Set file attributes based on file handle
@@ -70,6 +71,17 @@
if (flags & SATTR_UTIMES) {
unsigned int a_secs = attr->atime.seconds;
unsigned int m_secs = attr->mtime.seconds;
+ unsigned int a_usecs = attr->atime.useconds;
+ unsigned int m_usecs = attr->mtime.useconds;
+ struct timeval server_time;
+
+ if (a_usecs == SET_SERVER_TIME || m_usecs == SET_SERVER_TIME) {
+ gettimeofday(&server_time, NULL);
+ if (a_usecs == SET_SERVER_TIME)
+ a_secs = server_time.tv_sec;
+ if (m_usecs == SET_SERVER_TIME)
+ m_secs = server_time.tv_sec;
+ }
if ((a_secs != IGNORE_TIME && a_secs != s->st_atime)
|| (m_secs != IGNORE_TIME && m_secs != s->st_mtime)) {
@@ -78,19 +90,30 @@
/*
* Cover for partial utime setting
* Alan Cox <[email protected]>
+ *
+ * Handle Sun convention for "set to current server time"
+ * Ryusuke Konishi <[email protected]>
*/
if (a_secs != IGNORE_TIME) {
- tvp[0].tv_sec = attr->atime.seconds;
- tvp[0].tv_usec = attr->atime.useconds;
- s->st_atime = attr->atime.seconds;
+ if (a_usecs != SET_SERVER_TIME) {
+ tvp[0].tv_sec = attr->atime.seconds;
+ tvp[0].tv_usec = attr->atime.useconds;
+ } else
+ tvp[0] = server_time;
+
+ s->st_atime = a_secs;
} else {
tvp[0].tv_sec = s->st_atime;
tvp[0].tv_usec = 0;
}
if (m_secs != IGNORE_TIME) {
- tvp[1].tv_sec = attr->mtime.seconds;
- tvp[1].tv_usec = attr->mtime.useconds;
- s->st_mtime = attr->mtime.seconds;
+ if (m_usecs != SET_SERVER_TIME) {
+ tvp[1].tv_sec = attr->mtime.seconds;
+ tvp[1].tv_usec = attr->mtime.useconds;
+ } else
+ tvp[1] = server_time;
+
+ s->st_mtime = m_secs;
} else {
tvp[1].tv_sec = s->st_mtime;
tvp[1].tv_usec = 0;
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Hi,
On Thu, 16 Aug 2007, Peter_Astrand wrote:
>On Thu, 16 Aug 2007, Ryusuke Konishi wrote:
>> Hi folks,
>>
>> I found that the Linux user-space NFS server (unfsd) fails
>> for setattr requests against the kernel 2.6.22 and later.
>
>Hi, I'm curious: Why are you using this old unfsd instead of the kernel
>based knfsd, or the modern userspace implementation "unfs3"?
I am using both unfsd and knfsd because Debian still offers both.
(It also offers unfs3 but I didn't notice until you let me know)
>As far as I understand, noone is maintaining the old unfsd anymore.
>
>
>Regards,
All right.
As you say, the mail to unfsd maintainers was returned by
Host unknown. (Sigh)
It seems to have little hope to modify unfsd for this.
Thanks,
Ryusuke Konishi
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Thu, Aug 16, 2007 at 04:51:01PM +0900, Ryusuke Konishi wrote:
> Hi,
>
> On Thu, 16 Aug 2007, Peter_Astrand wrote:
> >On Thu, 16 Aug 2007, Ryusuke Konishi wrote:
> >> Hi folks,
> >>
> >> I found that the Linux user-space NFS server (unfsd) fails
> >> for setattr requests against the kernel 2.6.22 and later.
> >
> >Hi, I'm curious: Why are you using this old unfsd instead of the kernel
> >based knfsd, or the modern userspace implementation "unfs3"?
>
> I am using both unfsd and knfsd because Debian still offers both.
> (It also offers unfs3 but I didn't notice until you let me know)
>
> >As far as I understand, noone is maintaining the old unfsd anymore.
> >
> >
> >Regards,
>
> All right.
> As you say, the mail to unfsd maintainers was returned by
> Host unknown. (Sigh)
> It seems to have little hope to modify unfsd for this.
Have you tried the debian bug-tracking system? Maybe they're
practically speaking the only maintainers that unfsd has now.
--b.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Thu, 16 Aug 2007, J. Bruce Fields wrote:
>> All right.
>> As you say, the mail to unfsd maintainers was returned by
>> Host unknown. (Sigh)
>> It seems to have little hope to modify unfsd for this.
>
>Have you tried the debian bug-tracking system? Maybe they're
>practically speaking the only maintainers that unfsd has now.
Thanks!
I could make contact with a package maintainer of unfsd.
Regards,
Ryusuke Konishi
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Thu, Aug 16, 2007 at 09:33:50AM -0400, J. Bruce Fields wrote:
> Have you tried the debian bug-tracking system? Maybe they're
> practically speaking the only maintainers that unfsd has now.
FWIW, mail to the bug tracking system goes to the same e-mail as the one in
the Maintainer: field in the package.
As maintainer of the current nfs-utils packages (including nfs-kernel-server)
I'd be happy to see nfs-user-server go away from Debian as well, but I've
spoken to the maintainer in the past and he seemed unwilling to let it go.
Don't ask me why.
/* Steinar */
--
Homepage: http://www.sesse.net/
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs