clusternfs-devel Mailing List for ClusterNFS
Brought to you by:
warnes
You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
(16) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(1) |
Feb
(7) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2004 |
Jan
|
Feb
|
Mar
(2) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: jan p. s. <js...@ig...> - 2004-04-01 08:50:39
|
hello bernd, thanks. i've tried it and didn't work as reliable as i was wishing it would. the problem i'm actually trying to solve is that on a redhat based cluster client whose root dir is served on nfs (i.e. cNFS) up2date/rpm are not working correctly/reliably. rpm sometimes exits from installs saying that doing cpio of some package returned an error. is there any known problem/issue wrt. cNFS and cpio? btw. is my impression correct that the people involved in cNFS/unfs3 are mostly from germany (just curious)? tia, j. -- +------------------------------------+--------------------------------------+ | jan p. springer | js...@ig... | | computer science, buw.media.vrsys | jan...@me... | +------------------------------------+--------------------------------------+ |
From: Bernd S. <ber...@we...> - 2004-03-30 16:42:35
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 30 March 2004 17:23, jan p. springer wrote: > hi, > > is there any effort underway to move clusternfs beyond the nfs2 protocol? > if yes i would be glad to help. if no, where would i have to start diggin= g? > > on a related topic, is there any alternative to clusternfs (in the distr. > filesystem area, maybe)? > Hi Jan, Pacal has done great work and developed unfs3 (unfs3.sf.net). He also=20 implemented cNFS compability, so it supports the same cluster extensions as= =20 cNFS does :) Cheers, Bernd =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAaaNtC8BUnAF+ydYRAsWyAKCHacIILaBGU+2iBd7J+RF5xHNavwCdEjdS bAMcJuzIFXV+MQJFk1lp1HA=3D =3DPyMu =2D----END PGP SIGNATURE----- |
From: jan p. s. <js...@ig...> - 2004-03-30 15:24:08
|
hi, is there any effort underway to move clusternfs beyond the nfs2 protocol? if yes i would be glad to help. if no, where would i have to start digging? on a related topic, is there any alternative to clusternfs (in the distr. filesystem area, maybe)? tia, j. -- +------------------------------------+--------------------------------------+ | jan p. springer | js...@ig... | | computer science, buw.media.vrsys | jan...@me... | +------------------------------------+--------------------------------------+ |
From: Bernd S. <ber...@we...> - 2003-02-19 17:56:40
|
> > Hi, > > > > sorry for the delay but as usual I rather busy with other things. > > > > Attached are 2 patches, the first is a reformated version of the last one > > (avoid to long lines), the second disables opendir warnings. Additinaly a > > changelog for both is attached. > > > > Michal, please mail me again if you still want to have want to have > > something changed. > > Hi, > I've committed your patches to CVS, though I didn't have a chance to test > them. I believe you did ;-) Thanks for them! > Hello Michal, yes of course, it is running stable several weeks now. Thanks for applying. The next thing I'm thinking about is to look into nfs-fh stuff, since sometimes on updating some packages on the server can cause I/O errors or rather strange library problems on the clients, but of course this will take some time again. Best regards, Bernd |
From: Bernd S. <ber...@we...> - 2003-02-19 17:56:32
|
> > Hi, > > > > sorry for the delay but as usual I rather busy with other things. > > > > Attached are 2 patches, the first is a reformated version of the last one > > (avoid to long lines), the second disables opendir warnings. Additinaly a > > changelog for both is attached. > > > > Michal, please mail me again if you still want to have want to have > > something changed. > > Hi, > I've committed your patches to CVS, though I didn't have a chance to test > them. I believe you did ;-) Thanks for them! > Hello Michal, yes of course, it is running stable several weeks now. Thanks for applying. Best regards, Bernd |
From: Michal L. <mi...@lo...> - 2003-02-19 15:47:19
|
On Mon, 10 Feb 2003, Bernd Schubert wrote: > On Wednesday 29 January 2003 14:49, Bernd Schubert wrote: > > Hi, > > > > this week I checked if there are updates to the cvs-version and was very > > surprised to see that there was done a memory leak fix already in last > > September -- would be nice if something like this gets posted to any of the > > mailing lists. > > > > Well, my patch that fixes i/o-errors caused by my privious patches was also > > ready since this time, but I kept it back (and we didn't use it here > > either), since it seemed to increase the memory leakage. > > > > Attached is an improved and cleaned up version of the one I posted last > > year, so please apply to cvs. > > > > Btw, as you can see I had to add some additional lines to > > nfsd_nfsproc_readdir_2(), as noted in my comments IMHO it would be better > > to introduce a subfunction now. What do you think about it ? > > > > Thanks, > > Bernd > > > Hi, > > sorry for the delay but as usual I rather busy with other things. > > Attached are 2 patches, the first is a reformated version of the last one > (avoid to long lines), the second disables opendir warnings. Additinaly a > changelog for both is attached. > > Michal, please mail me again if you still want to have want to have something > changed. Hi, I've committed your patches to CVS, though I didn't have a chance to test them. I believe you did ;-) Thanks for them! Michal Ludvig |
From: Bernd S. <ber...@we...> - 2003-02-10 16:13:38
|
On Wednesday 29 January 2003 14:49, Bernd Schubert wrote: > Hi, > > this week I checked if there are updates to the cvs-version and was ver= y > surprised to see that there was done a memory leak fix already in last > September -- would be nice if something like this gets posted to any of= the > mailing lists. > > Well, my patch that fixes i/o-errors caused by my privious patches was = also > ready since this time, but I kept it back (and we didn't use it here > either), since it seemed to increase the memory leakage. > > Attached is an improved and cleaned up version of the one I posted last > year, so please apply to cvs. > > Btw, as you can see I had to add some additional lines to > nfsd_nfsproc_readdir_2(), as noted in my comments IMHO it would be bett= er > to introduce a subfunction now. What do you think about it ? > > Thanks, > =09Bernd Hi, sorry for the delay but as usual I rather busy with other things. Attached are 2 patches, the first is a reformated version of the last one= =20 (avoid to long lines), the second disables opendir warnings. Additinaly a= =20 changelog for both is attached. Michal, please mail me again if you still want to have want to have somet= hing=20 changed. Best reagards, =09Bernd |
From: Michal L. <mic...@lo...> - 2003-02-03 13:33:51
|
On Mon, 3 Feb 2003, Bernd Schubert wrote: > #ifdef TRANSLATE_NAMES > { /* bracket by Bernd, ... */ > #endif > res_size = 0; > ... /* some other lines needed by both */ > #ifdef TRANSLATE_NAMES > } /* end of bracket by Bernd. */ > #else > #endif > > So it DOES compile if TRANSLATE_NAMES is undefined. Errr, I missed the second #ifdef/#endif pair. Sorry, my fault. Michal Ludvig |
From: Bernd S. <ber...@we...> - 2003-02-03 12:23:00
|
On Monday 03 February 2003 11:16, Michal Ludvig wrote: > On Wed, 29 Jan 2003, Bernd Schubert wrote: > > Attached is an improved and cleaned up version of the one I posted la= st > > year, so please apply to cvs. > > Please reformate it to avoid long lines (especially in comments, but > preferably no line should be longer than cca 70 chars). > > And include a changelog please. > O.k., no problem I will do this. > > Btw, as you can see I had to add some additional lines to > > nfsd_nfsproc_readdir_2(), as noted in my comments IMHO it would be be= tter > > to introduce a subfunction now. What do you think about it ? > > Is it a duplicite code or is it there only once? It isn't *that* long, > anyway, I'd leave it in-place. O.k., I wasn't sure, thatswhy I asked. > > But the problem is, that you have introduced this construction: > > #ifdef TRANSLATE_NAMES > { /* bracket by Bernd, ... */ > #endif > } /* end of bracket by Brend. */ > > Shouldn't the #ifdef/#endif be nested inside the brackets? This way it > won't even compile if you undefine TRANSLATE_NAMES. No, the construction is: #ifdef TRANSLATE_NAMES { /* bracket by Bernd, ... */ #endif res_size =3D 0; =2E.. /* some other lines needed by both */ #ifdef TRANSLATE_NAMES } /* end of bracket by Bernd. */ #else #endif So it DOES compile if TRANSLATE_NAMES is undefined. Anyway I will reformat it this evening end send a new patch. Best regards, =09Bernd |
From: Michal L. <mic...@lo...> - 2003-02-03 10:16:56
|
On Wed, 29 Jan 2003, Bernd Schubert wrote: > Attached is an improved and cleaned up version of the one I posted last year, > so please apply to cvs. Please reformate it to avoid long lines (especially in comments, but preferably no line should be longer than cca 70 chars). And include a changelog please. > Btw, as you can see I had to add some additional lines to > nfsd_nfsproc_readdir_2(), as noted in my comments IMHO it would be better to > introduce a subfunction now. What do you think about it ? Is it a duplicite code or is it there only once? It isn't *that* long, anyway, I'd leave it in-place. But the problem is, that you have introduced this construction: #ifdef TRANSLATE_NAMES { /* bracket by Bernd, ... */ #endif } /* end of bracket by Brend. */ Shouldn't the #ifdef/#endif be nested inside the brackets? This way it won't even compile if you undefine TRANSLATE_NAMES. Michal Ludvig |
From: Bernd S. <ber...@we...> - 2003-01-29 13:49:58
|
Hi, this week I checked if there are updates to the cvs-version and was very=20 surprised to see that there was done a memory leak fix already in last=20 September -- would be nice if something like this gets posted to any of t= he=20 mailing lists. Well, my patch that fixes i/o-errors caused by my privious patches was al= so=20 ready since this time, but I kept it back (and we didn't use it here eith= er),=20 since it seemed to increase the memory leakage. Attached is an improved and cleaned up version of the one I posted last y= ear,=20 so please apply to cvs. Btw, as you can see I had to add some additional lines to=20 nfsd_nfsproc_readdir_2(), as noted in my comments IMHO it would be better= to=20 introduce a subfunction now. What do you think about it ? Thanks, =09Bernd |
From: Bernd S. <ber...@we...> - 2002-09-16 13:30:39
|
On Monday 16 September 2002 15:14, Michal Ludvig wrote: > On Fri, 6 Sep 2002, Bernd Schubert wrote: > > Hi, > > > > here's a new patch for 3 things: > > > > 1.) Complete the previous CREATE-tag patches, now no i/o errors shoul= d > > appear. > > > > 2.) Disable 2 syslog-lines -- our syslog file was filled with > > opendir: permission denieds, though everything seems to work fine > > > > 3.) Add a malloc from mplayer for i686, here I need your help, since = I > > think the configure scripts need to be modified and I have almost zer= o > > experience with configure scripts. > > > > Sorry for the long delay since the last patch, but actually the patch= was > > almost ready since March, but there was on odd bug, that only effecte= d > > directoried with lots of subdirectories - and I had no clue what caus= ed > > this. Well it were the following lines, which I'm not really sure wha= t > > they are for: > > > > nfsd - 1132: > > > > res_size =3D 0; > > memcpy(&dloc, argp->cookie, sizeof(dloc)); > > if (dloc !=3D 0) > > efs_seekdir(dirp, ntohl(dloc)); > > first =3D 1; > > > > > > The modified nfsd seems to run fine, but please Michal, wait a furthe= r > > week before applying the patch. > > So, can I enroll the patch? Does it work? > > Michal Ludvig > Hi Michal, we just (2 hours ago) found a memory-leak, it seams that it are again the= =20 lines from above, but I will investigate this during the evening. I think I will have to send a new patch. Sorry for inconvinience, Bernd |
From: Michal L. <mi...@lo...> - 2002-09-16 13:14:50
|
On Fri, 6 Sep 2002, Bernd Schubert wrote: > Hi, > > here's a new patch for 3 things: > > 1.) Complete the previous CREATE-tag patches, now no i/o errors should appear. > > 2.) Disable 2 syslog-lines -- our syslog file was filled with > opendir: permission denieds, though everything seems to work fine > > 3.) Add a malloc from mplayer for i686, here I need your help, since I think > the configure scripts need to be modified and I have almost zero experience > with configure scripts. > > Sorry for the long delay since the last patch, but actually the patch was > almost ready since March, but there was on odd bug, that only effected > directoried with lots of subdirectories - and I had no clue what caused this. > Well it were the following lines, which I'm not really sure what they are > for: > > nfsd - 1132: > > res_size = 0; > memcpy(&dloc, argp->cookie, sizeof(dloc)); > if (dloc != 0) > efs_seekdir(dirp, ntohl(dloc)); > first = 1; > > > The modified nfsd seems to run fine, but please Michal, wait a further week > before applying the patch. So, can I enroll the patch? Does it work? Michal Ludvig |
From: Bernd S. <ber...@we...> - 2002-09-06 17:02:08
|
Hi, here's a new patch for 3 things: 1.) Complete the previous CREATE-tag patches, now no i/o errors should appear. 2.) Disable 2 syslog-lines -- our syslog file was filled with opendir: permission denieds, though everything seems to work fine 3.) Add a malloc from mplayer for i686, here I need your help, since I think the configure scripts need to be modified and I have almost zero experience with configure scripts. Sorry for the long delay since the last patch, but actually the patch was almost ready since March, but there was on odd bug, that only effected directoried with lots of subdirectories - and I had no clue what caused this. Well it were the following lines, which I'm not really sure what they are for: nfsd - 1132: res_size = 0; memcpy(&dloc, argp->cookie, sizeof(dloc)); if (dloc != 0) efs_seekdir(dirp, ntohl(dloc)); first = 1; The modified nfsd seems to run fine, but please Michal, wait a further week before applying the patch. |
From: Bernd S. <ber...@we...> - 2002-03-14 14:15:48
|
On Thursday 14 March 2002 14:45, you wrote: > On Thu, 14 Mar 2002, Bernd Schubert wrote: > > Here's the patch for current cvs. > > This time it really seems to work. > > I hope you've already tested it ;-) Yes, I've added another client to our test system and this time no server specific files have been deleted :-) And using the 'vi' on the client for client specific files also works without deleting or replacing the server's files. > > OK, it's committed. > > Michal Ludvig > > |
From: Michal L. <mi...@lo...> - 2002-03-14 13:46:00
|
On Thu, 14 Mar 2002, Bernd Schubert wrote: > Here's the patch for current cvs. > This time it really seems to work. I hope you've already tested it ;-) OK, it's committed. Michal Ludvig |
From: Bernd S. <ber...@we...> - 2002-03-14 13:35:09
|
Here's the patch for current cvs. This time it really seems to work. On Tuesday 12 March 2002 13:20, Bernd Schubert wrote: > Hi, > > currently my changes to the create tag only work if only one client is > connected to the server. > > I'll work on this during the next evenings. > > > Bernd > > _______________________________________________ > ClusterNFS-Devel mailing list > Clu...@li... > https://lists.sourceforge.net/lists/listinfo/clusternfs-devel |
From: Bernd S. <ber...@we...> - 2002-03-12 12:20:47
|
Hi, currently my changes to the create tag only work if only one client is connected to the server. I'll work on this during the next evenings. Bernd |
From: Michal L. <mi...@lo...> - 2002-03-06 10:05:50
|
On Tue, 5 Mar 2002, Bernd Schubert wrote: > Oh yes, actually I only sent this patches, to have you a look on it and tell > me if you like my style of programming, but since you applied it to cvs, I > also think its better to remove these lines :-) I have no problem with your coding style. Perhaps one thing: there is no need to write funct((struct->item), something) Enough is: funct(struct->item, something) Also I prefer to put one space after each comma in argument list like: (arg1, arg2) instead of (arg1,arg2). > Probably during the weekend I'll make use from the testlines below and write > a patch that prevents the input/output errors (by removing this files for the > client all) that currently occurs when a file with the CREATE tag and a > servers file exists but not a client specific file. > But I'm not sure if all users will like it -- could possibly a new tag be > necessary? Since current status commits an IO errors (I noticed them also) I don't see a reason why not to bring a solution. I vote against another tag. Possibly you can add a compile-time option for this via #ifdef ... #endif so that anybody could switch it off if they don't like it. Michal Ludvig |
From: Bernd S. <ber...@we...> - 2002-03-05 17:08:55
|
Oh yes, actually I only sent this patches, to have you a look on it and tell me if you like my style of programming, but since you applied it to cvs, I also think its better to remove these lines :-) Probably during the weekend I'll make use from the testlines below and write a patch that prevents the input/output errors (by removing this files for the client all) that currently occurs when a file with the CREATE tag and a servers file exists but not a client specific file. But I'm not sure if all users will like it -- could possibly a new tag be necessary? On Tuesday 05 March 2002 17:47, Michal Ludvig wrote: > On Tue, 5 Mar 2002, Bernd Schubert wrote: > > O.k. this was easy, another patch for the current cvs-tree is attached. > > Commited, thanks. > > IMHO This one can be removed from your tree as well or not? > > diff -ubB /usr/people/bernd/bin/clusternfs/ClusterNFS/trnames2.c > ClusterNFS/trnames2.c --- > /usr/people/bernd/bin/clusternfs/ClusterNFS/trnames2.c Tue Mar 5 > 14:43:00 2002 +++ ClusterNFS/trnames2.c Tue Mar 5 17:30:59 2002 > @@ -609,6 +612,14 @@ > > name = strdup(filename); > len = strlen(name); > + > + /* some lines by Bernd for testing */ > + if (strcmp(name,"testfile")==0) > + { > + return NULL; > + } > + > + > > > Michal Ludvig > > > > _______________________________________________ > ClusterNFS-Devel mailing list > Clu...@li... > https://lists.sourceforge.net/lists/listinfo/clusternfs-devel -- Bernd Schubert Physikalisch Chemisches Institut Abt. Theoretische Chemie INF 229, 69120 Heidelberg Tel.: 06221/54-5210 e-mail: ber...@tc... |
From: Michal L. <mi...@lo...> - 2002-03-05 16:47:46
|
On Tue, 5 Mar 2002, Bernd Schubert wrote: > O.k. this was easy, another patch for the current cvs-tree is attached. Commited, thanks. IMHO This one can be removed from your tree as well or not? diff -ubB /usr/people/bernd/bin/clusternfs/ClusterNFS/trnames2.c ClusterNFS/trnames2.c --- /usr/people/bernd/bin/clusternfs/ClusterNFS/trnames2.c Tue Mar 5 14:43:00 2002 +++ ClusterNFS/trnames2.c Tue Mar 5 17:30:59 2002 @@ -609,6 +612,14 @@ name = strdup(filename); len = strlen(name); + + /* some lines by Bernd for testing */ + if (strcmp(name,"testfile")==0) + { + return NULL; + } + + Michal Ludvig |
From: Bernd S. <ber...@we...> - 2002-03-05 16:36:21
|
O.k. this was easy, another patch for the current cvs-tree is attached. On Tuesday 05 March 2002 16:45, Bernd Schubert wrote: > Hmm, something went wrong, I just wanted to test the patches in our > workgroup but it didn't work. Seems that fixing the bug also 'fixed' some > other things. > > Sorry for inconvinience, Bernd > |
From: Bernd S. <ber...@we...> - 2002-03-05 15:45:44
|
Hmm, something went wrong, I just wanted to test the patches in our workgroup but it didn't work. Seems that fixing the bug also 'fixed' some other things. Sorry for inconvinience, Bernd On Tuesday 05 March 2002 14:56, you wrote: > On Tue, 5 Mar 2002, Bernd Schubert wrote: > > here's another patch, my previous one had several bugs (mountd didn't > > compile and another very critical one, introduced by me in > > tr2_getfarray). > > Thanks for your patches. I've committed them into cnfsd's CVS on > sourceforge, but haven't time to verify yet. If someone can do it, > please pull out the sources from CVS as written on > http://sourceforge.net/cvs/?group_id=5768 and tell us the results. > > Brend, please use -bB switch to diff as well (or don't change whitespaces > :-) > > Michal Ludvig > > > _______________________________________________ > ClusterNFS-Devel mailing list > Clu...@li... > https://lists.sourceforge.net/lists/listinfo/clusternfs-devel -- Bernd Schubert Physikalisch Chemisches Institut Abt. Theoretische Chemie INF 229, 69120 Heidelberg Tel.: 06221/54-5210 e-mail: ber...@tc... |
From: Michal L. <mi...@lo...> - 2002-03-05 14:29:00
|
On Tue, 5 Mar 2002, Bernd Schubert wrote: > one if the things I still don't understand is why mountd also has support for > name translation (I'm not common with nfs details, but I thought it's only > necessary for allowing the client to mount a directory). Furthermore, I think > I ones tried if it works. when nfsd name translation is disables and I > believe to remember that it didn't work. Well I've found it a bit useless as well. But you can disable it if you don't like it. > And can anyone give me a list of literature citates that describe NFS? Search the web for NFS version 2 (ie via Google). Originally it is a protocol from Sun Microsystems. Michal Ludvig |
From: Bernd S. <ber...@we...> - 2002-03-05 13:57:43
|
Hi, one if the things I still don't understand is why mountd also has support for name translation (I'm not common with nfs details, but I thought it's only necessary for allowing the client to mount a directory). Furthermore, I think I ones tried if it works. when nfsd name translation is disables and I believe to remember that it didn't work. And can anyone give me a list of literature citates that describe NFS? Thanks, Bernd |