time.
Cheers,
Gianluca
Chuck Lever wrote:
Hi Gianluca-
On Feb 6, 2008, at 1:25 PM, Gianluca Alberici wrote:
Hello all,
Thanks to Chuck's help i finally decided to proceed to a git bisect
and found the bad patch. Is there anybody that has an idea why it
breaks userspace nfs servers as we
Gianluca
Hi Gianluca-
On Jan 30, 2008, at 7:40 AM, Gianluca Alberici wrote:
Hello again everybody
Here follows the testbench:
- I got two mirrors, same machine, same disk etc...chaged hostname,
IP, and on the second i have recompiled kernel.
- First: 2.6.21.7 on debian sarge
- Second: 2.6.
time.
Cheers,
Gianluca
Chuck Lever wrote:
Hi Gianluca-
On Feb 6, 2008, at 1:25 PM, Gianluca Alberici wrote:
Hello all,
Thanks to Chuck's help i finally decided to proceed to a git bisect
and found the bad patch. Is there anybody that has an idea why it
breaks userspace nfs servers as we
Hello Chuck,
As you requested i have finally found out that the problem was
introduced in 2.6.22 (2.6.21.7 works, after 2.6.21.7 theres 2.6.22)
I have also examined the changeslogs: 2.6.22 introduce a certain number
of patches into NFS client. Many of them are yours and Trond's.
Pls can
help ?
Gianluca
Chuck Lever wrote:
On Dec 25, 2007, at 5:04 PM, Andrew Morton wrote:
On Sun, 23 Dec 2007 12:35:17 +0100 Gianluca Alberici
<[EMAIL PROTECTED]> wrote:
Hello,
I can do better. I have investigated a bit the problem:
1) The problem arises only with the userspace nfsd (Univers
Lever wrote:
On Dec 25, 2007, at 5:04 PM, Andrew Morton wrote:
On Sun, 23 Dec 2007 12:35:17 +0100 Gianluca Alberici
[EMAIL PROTECTED] wrote:
Hello,
I can do better. I have investigated a bit the problem:
1) The problem arises only with the userspace nfsd (Universal nfsd
2.2).
I have
Hello Chuck,
As you requested i have finally found out that the problem was
introduced in 2.6.22 (2.6.21.7 works, after 2.6.21.7 theres 2.6.22)
I have also examined the changeslogs: 2.6.22 introduce a certain number
of patches into NFS client. Many of them are yours and Trond's.
Pls can
2007 12:35:17 +0100 Gianluca Alberici <[EMAIL PROTECTED]> wrote:
Hello,
I can do better. I have investigated a bit the problem:
1) The problem arises only with the userspace nfsd (Universal nfsd 2.2).
I have realized that the latest patches introduced in 2.6.22 have
changed a lot of
2007 12:35:17 +0100 Gianluca Alberici [EMAIL PROTECTED] wrote:
Hello,
I can do better. I have investigated a bit the problem:
1) The problem arises only with the userspace nfsd (Universal nfsd 2.2).
I have realized that the latest patches introduced in 2.6.22 have
changed a lot of things
which is an nfs server pretty old fashioned).
- This problem makes UNFSD and CFSD unusable on 2.6.22 and up (this
doesnt sound good to me)
The question are:
- Is this wanted or is a bug ?
- Can this be solved with some backwards compat stuff into the kernel or
all the old packages as UNFSD ha
strange behaviors of the new NFS filesystem support
that i am investigating. All are bound to the user of
old userspace servers onto the new NFS (since 2.6.22). What to do ?
Thanks
Gianluca
Scott wrote:
On Dec 22, 2007, at 5:52 AM, Gianluca Alberici wrote:
I've run into this problem
Hi,
Sorry for repeating but as far as i can see 2.6.23.11/12 got no changes
into NFS.
I've run into this problem 2.6.23.9. The open syscall will return
"Invalid argument" when O_TRUNC is set on existing files.
The same file can be opened for append or removed.
The evidence is for example:
Hi,
Sorry for repeating but as far as i can see 2.6.23.11/12 got no changes
into NFS.
I've run into this problem 2.6.23.9. The open syscall will return
Invalid argument when O_TRUNC is set on existing files.
The same file can be opened for append or removed.
The evidence is for example:
Hi,
Sorry for repeating but as far as i can see 2.6.23.11/12 got no changes
into NFS.
I've run into this problem 2.6.23.9. The open syscall will return
"Invalid argument" when O_TRUNC is set on existing files.
The same file can be opened for append or removed.
The evidence is for example:
Hi,
Sorry for repeating but as far as i can see 2.6.23.11/12 got no changes
into NFS.
I've run into this problem 2.6.23.9. The open syscall will return
Invalid argument when O_TRUNC is set on existing files.
The same file can be opened for append or removed.
The evidence is for example:
Hi,
I've run into this problem on a 'localhost:' NFS mount on a 2.6.23.9:
The fopen syscall will return "Invalid argument" trying to fopen in "w"
mode an existing file. The same file can be opened for append or removed.
The evidence is for example:
mars:~# mount localhost:/opt/nfs/ /mnt/tmp
Hi,
I've run into this problem on a 'localhost:' NFS mount on a 2.6.23.9:
The fopen syscall will return Invalid argument trying to fopen in w
mode an existing file. The same file can be opened for append or removed.
The evidence is for example:
mars:~# mount localhost:/opt/nfs/ /mnt/tmp
Trond Myklebust wrote:
On Sun, 2007-11-18 at 19:44 +0100, Gianluca Alberici wrote:
Trond,
The problem is in nfs_mountpoint_timeout. After this time
dentry_delete(/,4) removes the mountpoint, then it is very difficult to
automount (at least with CFSD), one has got to try 2 or three times
Trond,
The problem is in nfs_mountpoint_timeout. After this time
dentry_delete(/,4) removes the mountpoint, then it is very difficult to
automount (at least with CFSD), one has got to try 2 or three times
cd'ing into the mount point. Applications wont ever had the chance to
autoremount
Trond,
The problem is in nfs_mountpoint_timeout. After this time
dentry_delete(/,4) removes the mountpoint, then it is very difficult to
automount (at least with CFSD), one has got to try 2 or three times
cd'ing into the mount point. Applications wont ever had the chance to
autoremount
Trond Myklebust wrote:
On Sun, 2007-11-18 at 19:44 +0100, Gianluca Alberici wrote:
Trond,
The problem is in nfs_mountpoint_timeout. After this time
dentry_delete(/,4) removes the mountpoint, then it is very difficult to
automount (at least with CFSD), one has got to try 2 or three times
Hello,
I have found out something new about the cfs problem:
1) on a 2.6.20, working good:
after starting cfs, nothing cattach'd:
zeus:~# cat /proc/fs/nfsfs/volumes
NV SERVER PORT DEV FSID
v2 7f01 be9 0:140:0
after cattaching (and at least once listing the directory, if not
0. Anyway it seems that pakets with length 48 are only present when
system doesnt work.
What do you think ?
Regards,
Gianluca
Trond Myklebust wrote:
On Fri, 2007-11-16 at 13:11 +0100, markus reichelt wrote:
* Gianluca Alberici <[EMAIL PROTECTED]> wrote:
If i cd into i
, sometimes
10. Anyway it seems that pakets with length 48 are only present when
system doesnt work.
What do you think ?
Regards,
Gianluca
Trond Myklebust wrote:
On Fri, 2007-11-16 at 13:11 +0100, markus reichelt wrote:
* Gianluca Alberici [EMAIL PROTECTED] wrote:
If i cd
Hello,
I have found out something new about the cfs problem:
1) on a 2.6.20, working good:
after starting cfs, nothing cattach'd:
zeus:~# cat /proc/fs/nfsfs/volumes
NV SERVER PORT DEV FSID
v2 7f01 be9 0:140:0
after cattaching (and at least once listing the directory, if not
Hello,
Got problems with CFS after a kernel upgrade from 2.6.20 to 2.6.23.
After a certain amount of time since cattach i get:
ios:~$ ls /opt/clear/
ls: /opt/clear/: Not a directory
stracing the command i get stat64() returning ENOTDIR.
Applications won't find the directory.
If i cd into it
Hello,
Got problems with CFS after a kernel upgrade from 2.6.20 to 2.6.23.
After a certain amount of time since cattach i get:
ios:~$ ls /opt/clear/
ls: /opt/clear/: Not a directory
stracing the command i get stat64() returning ENOTDIR.
Applications won't find the directory.
If i cd into it
Hello,
Got problems with CFS after a kernel upgrade from 2.6.20 to 2.6.23.
After a certain amount of time since cattach i get:
ios:~$ ls /opt/clear/
ls: /opt/clear/: Not a directory
stracing the command i get stat64() returning ENOTDIR.
Applications won't find the directory.
If i cd into it
Hello,
Got problems with CFS after a kernel upgrade from 2.6.20 to 2.6.23.
After a certain amount of time since cattach i get:
ios:~$ ls /opt/clear/
ls: /opt/clear/: Not a directory
stracing the command i get stat64() returning ENOTDIR.
Applications won't find the directory.
If i cd into it
Hello,
Got problems with CFS after a kernel upgrade from 2.6.20 to 2.6.23.
After a certain amount of time since cattach i get:
ios:~$ ls /opt/clear/
ls: /opt/clear/: Not a directory
stracing the command i get stat64() returning ENOTDIR.
Applications won't find the directory.
If i cd into it
Hello,
Got problems with CFS after a kernel upgrade from 2.6.20 to 2.6.23.
After a certain amount of time since cattach i get:
ios:~$ ls /opt/clear/
ls: /opt/clear/: Not a directory
stracing the command i get stat64() returning ENOTDIR.
Applications won't find the directory.
If i cd into it
Hello,
What is the status of the HSDPA driver after 2.6.19.1 ? Is it part of
the kernel tree or not yet ?
If not is there any version of ther nozomi pack which is gonna compile
under ker > 2.6.18 (the original one is not compiling anymore after 2.6.18).
Thanks,
Gianluca
-
To unsubscribe
Hello,
What is the status of the HSDPA driver after 2.6.19.1 ? Is it part of
the kernel tree or not yet ?
If not is there any version of ther nozomi pack which is gonna compile
under ker 2.6.18 (the original one is not compiling anymore after 2.6.18).
Thanks,
Gianluca
-
To unsubscribe from
33 matches
Mail list logo
