[leafnode-list] locking, again

[krasel@xxxxxxxxxxxxxxxxxxxxxxxxxxxx (Cornelius Krasel)]

When musing about the subject of having a global lock (something that
has been discussed on this list before and is not implemented very
well in the current 2.0 beta), it occurred to me that the nntpd may
not have to write a new groupinfo file when adding an article.

Why?

The groupinfo file contains numbers for the first and last article in
a newsgroup. These numbers are verified by texpire and fetchnews and
are needed by fetchnews and the nntpd. fetchnews needs to know the
last number of an article when it sorts new articles into the spool
to rise the article number properly. The nntpd needs to know the last
number to give proper replies to GROUP commands.

If the nntpd would not write the groupinfo file, it would still know
the last number because it stores it internally. This leaves the
problem with fetchnews.

fetchnews contains a small hack to correct for small misadjustments of
the last number. If an article with the number that fetchnews thinks
is the first new one already exists, fetchnews will notice that and
increase the article number by one. That is, if fetchnews thinks the
last article is e.g. 368 but if articles 354 to 372 exist on your
HD, then fetchnews will check whether it can store the new article
as 369, then register that the article already exists, then do the
same for numbers 370 to 372 and finally store the new article as
373. However, this mechanism will not work if there are gaps in the
numbering, e.g. if files 368, 369 and 372 exist. In that case, the
article will be stored as 370 and a newsreader will most likely never
see it.

Therefore, if we give up locking by the nntpd fetchnews would have
to determine the correct first and last number from the article
directory itself. This can be done by reading the directory. As long
as you don't check for file types, it's quite fast. Indeed, that
is the way texpire determines correct first and last numbers;
fetchnews -f works the same.

What are the advantages of giving up locking of the nntpd?

1) Posting should be faster because there is no need for the nntpd to
   fork and write a new groupinfo file. When doing a rereadactive(),
   the nntpd will still acquire new "correct" groupinfo files.
2) We can abolish the file locking based on fcntl(). This would make
   it possible to implement NFS-secure file locking by using open()
   (I think this was suggested by Matthias Andree).
3) Locking would be again more "safe".

The only disadvantage that I can see so far is that fetchnews would
be a little bit slower because it has to cycle through all
"interesting" groups once to determine the "correct" first and last
article.

Comments with regard to this proposal are appreciated.

--Cornelius.

-- 
/* Cornelius Krasel, U Wuerzburg, Dept. of Pharmacology, Versbacher Str. 9 */
/* D-97078 Wuerzburg, Germany   email: krasel@xxxxxxxxxxxxxxxxxxxxxxxxxxxx */
/* "Science is the game we play with God to find out what His rules are."  */

-- 
leafnode-list@xxxxxxxxxxxxxxxxxxxxxxxxxxxx -- mailing list for leafnode
To unsubscribe, send mail with "unsubscribe" in the subject to the list