Discussion:
[INN] CNFS-Buffer (was: ignore 21095.15 - CNFS-Buffer)
(zu alt für eine Antwort)
Marcel Logen
2023-11-18 17:46:39 UTC
Permalink
Soweit ich weiß, werden die Testgruppen auf dem tota-Server
in einem CNFS-Buffer (oder mehreren?) gespeichert.
| Neu ist das Cyclic News File System (CNFS). Bei dieser
| Storage-Methode werden sog. Buffer angelegt, in die die
| Postings der Eingangsreihenfolge nach hineingeschrieben
| werden. Ist das Ende des Buffers erreicht, wird an den
| Anfang zurückgesprungen; die ältesten Postings werden
| durch die neueintreffenden überschrieben. Das geht sehr
| fix und führt zu einem automatischen, aber zeitlich nicht
| genau festgelegten Expire - ein Posting ist genau dann
| expired, wenn eben der Buffer voll ist und es überschrieben
| wird. [...]
|
| Es ist möglich, verschiedene Storage-Methoden nebeneinander
| zu verwenden, bspw. große und unvorhersehbar wachsende
| Hierarchien und Binaries in - verschieden großen - CNFS-
| Buffern abzulegen, kleine und lokale Hierarchien aber als
| tradspool. Die Entscheidung, wo ein Posting gespeichert
| werden soll, kann anhand der Newsgroups, in die es gepostet
| wurde, der Größe oder auch des Expire-Zeitraumes erfolgen.
Heute sind die Testgruppen auf tota fast alle so gut wie leer.
Hier in de.test ist derzeit nur das Posting von Clemens
Da ist wohl der CNFS-Buffer wieder mal voll (bzw. er
'schob' gerade die älteren Postings - bis gestern - ver-
mutlich im FIFO-Verfahren 'hinaus'). (BTW: Dennis hatte
in diesem Zusammenhang mal gefragt, ob dieser Buffer
eigentlich *immer* voll sei.)
Inzwischen habe ich auch bei Russ mal gelesen.

<https://www.eyrie.org/~eagle/software/inn/docs-2.7/storage.conf.html>:

| The cnfs storage method stores articles in large cyclic
| buffers (CNFS stands for Cyclic News File System). Articles
| are stored in CNFS buffers in arrival order, and when the
| buffer fills, it wraps around to the beginning and stores
| new articles over the top of the oldest articles in the
| buffer. The expire time of articles stored in CNFS buffers
| is therefore entirely determined by how long it takes the
| buffer to wrap around, which depends on how quickly data
| is being stored in it. (This method is therefore said to
| have self-expire functionality. It also means that when
| an article is cancelled, the cycbuff doesn't go back and
| use space until it rolls over and the whole cycbuff starts
| being reused.)

Es sieht mir jetzt so aus, als wäre der Buffer nicht immer
'voll', sondern es gehen wohl nach dem Vollaufen alle bis-
herigen Inhalte verloren, da wieder am Anfang mit dem Spei-
chern begonnen wird. Also wohl kein FIFO-Prinzip, jedenfalls
nicht in dem Sinne, daß da Artikel an der einen Seite 'hin-
ein-' und an der anderen 'hinausgeschoben' würden.

Marcel

fup2 de.comm.software.newsserver
--
╭──╮ ╭───╮ ╭─╮ ╭──╮ ╭─╮ ╭──╮ ..61..╭───╮
╭──╮ ╭─╯ ╰─╯ ╰───╮ ╭──╯ ╰──╯ ╰─╮ ..46..│ ╰─╯ ╰───────╯ │
│ ╰─╮ ╰──╮ ╭───────╯ │ ╭─────────╯ ╭──╮ │ ..65..│
──╯ ╰─────╯ ╰───────────╯ ╰────────────╯ ╰──╯ ..65..╰─
Christian Garbs
2023-11-18 22:15:58 UTC
Permalink
Mahlzeit!
Post by Marcel Logen
Es sieht mir jetzt so aus, als wäre der Buffer nicht immer
'voll', sondern es gehen wohl nach dem Vollaufen alle bis-
herigen Inhalte verloren, da wieder am Anfang mit dem Spei-
chern begonnen wird. Also wohl kein FIFO-Prinzip, jedenfalls
nicht in dem Sinne, daß da Artikel an der einen Seite 'hin-
ein-' und an der anderen 'hinausgeschoben' würden.
Nein, bei einem Wraparound gehen nicht schlagartig alle Artikel
verloren. Das ist ein klassischer Ringbuffer:

Der CNFS-Buffer wächst bis zu seiner maximalen Größe¹, dabei bleibt
die Schreibposition für neue Artikel immer an seinem Ende. Das ist
erstmal das gleiche, als ob man Daten in eine reguläre Datei
hineinschreibt.

Erreicht der Buffer seine maximale Größe, gibt es einen "Wraparound":
Die Schreibposition springt wieder auf den Anfang und es wird
begonnen, die ältesten Artikel zu überschreiben. Alle noch nicht
überschriebenen alten Artikel sind aber weiterhin vorhanden - es wird
nicht plötzlich alles alte gelöscht. Das wäre ja sehr doof, dann
hätte man mal ganz viele und mal gar keine Artikel im Buffer.

Ab jetzt ändert sich die Größe des Buffers nicht mehr, nur die
Schreibposition wandert vom Anfang bis ans Ende und danach wieder vom
Anfang bis ans Ende.

Ungefähr so, als hätte jemand einen Stift an den Minutenzeiger einer
Analoguhr geklebt. Nach einer Stunde übermalt er das, was er vorher
gemalt hat – der Kreis, den er gemalt hat, wird aber nicht größer ;-)

Gruß
Christian

¹ Oder wird er direkt initial leer mit maximaler Größer angelegt?
Ich meine, dass er wächst, habe das jetzt aber nicht nachgeschlagen.
--
....Christian.Garbs....................................https://www.cgarbs.de
Gegen Angriffe kann man sich wehren, gegen Lob ist man machtlos.
(Sigmund Freud)
Daniel Weber
2023-11-18 22:59:10 UTC
Permalink
Post by Christian Garbs
¹ Oder wird er direkt initial leer mit maximaler Größer angelegt?
Ja, man legt den Buffer gleich mit der Ziel-Größe an.

Ciao
Daniel
Marcel Logen
2023-11-19 15:11:31 UTC
Permalink
Post by Christian Garbs
Post by Marcel Logen
Es sieht mir jetzt so aus, als wäre der Buffer nicht immer
'voll', sondern es gehen wohl nach dem Vollaufen alle bis-
herigen Inhalte verloren, da wieder am Anfang mit dem Spei-
chern begonnen wird. Also wohl kein FIFO-Prinzip, jedenfalls
nicht in dem Sinne, daß da Artikel an der einen Seite 'hin-
ein-' und an der anderen 'hinausgeschoben' würden.
Ich hatte da bisher immer so ein Bild mit einer waagerechten
Röhre im Sinn, wo an einer Seite die Postings hineingeschoben
werden.
Post by Christian Garbs
Nein, bei einem Wraparound gehen nicht schlagartig alle Artikel
OK
Post by Christian Garbs
Der CNFS-Buffer wächst bis zu seiner maximalen Größe¹, dabei bleibt
die Schreibposition für neue Artikel immer an seinem Ende. Das ist
erstmal das gleiche, als ob man Daten in eine reguläre Datei
hineinschreibt.
Die Schreibposition springt wieder auf den Anfang und es wird
"Springt"? Wenn ich Dich richtig verstehe, kommt die Schreib-
position sozusagen wieder automatisch am Anfang vorbei.
Post by Christian Garbs
begonnen, die ältesten Artikel zu überschreiben. Alle noch nicht
überschriebenen alten Artikel sind aber weiterhin vorhanden - es wird
nicht plötzlich alles alte gelöscht. Das wäre ja sehr doof, dann
hätte man mal ganz viele und mal gar keine Artikel im Buffer.
Genau so sieht es aber derzeit aus. Der Buffer war am 18.11. um
ca. 0 Uhr leer und füllt sich nun wieder.

Nach meinen Beobachtungen sind auf dem tota-Server die Gruppen
betroffen, deren Name auf die Regex "test$" matcht, also z. B.
nicht "abg.test04" oder "alt.testing.testing".

Es wurden auf dem tota-Server auch Crosspostings gelöscht, die
solche NGs enthielten, etwa
<news:***@o15.ybtra.de>
<http://al.howardknight.net/?ID=170034907000>.
(Auf individual ist das Posting natürlich noch vorhanden.)

Wurde vielleicht der CNFS-Buffer von Daniel am 18.11. um 0 Uhr
neu angelegt?
Post by Christian Garbs
Ab jetzt ändert sich die Größe des Buffers nicht mehr, nur die
Schreibposition wandert vom Anfang bis ans Ende und danach wieder vom
Anfang bis ans Ende.
Ungefähr so, als hätte jemand einen Stift an den Minutenzeiger einer
Analoguhr geklebt. Nach einer Stunde übermalt er das, was er vorher
gemalt hat – der Kreis, den er gemalt hat, wird aber nicht größer ;-)
Danke, aber es ist mir immer noch nicht ganz klar, warum
am 18.11. um 0 Uhr der Buffer leer war (jedenfalls sah es
so aus) und sich jetzt langsam wieder füllt.

Marcel
--
╭──╮ ╭─────────────╮ ╭───╮ ╭───╮ ..62..╭─╮
╭─╮ ╭───╮ │ ╰─╮ ╰─────────╮ ╰─────╮ ╭──╯ │ │ ╰──╮ ╭───╯ │
─╯ ╰─╮ │ ╰─╯ │ ╭──╮ ╭─╯ ╭────╯ │ ╭───╯ ╰──╮ │ ╰─╮ ╰─╮
╰─╯ ╰───╯ ╰───╯..31..╰──────╯ ╰─────────╯ ╰────╯ ╰
Marcel Logen
2023-11-19 15:56:27 UTC
Permalink
Marcel Logen in de.comm.software.newsserver:

[...]
Post by Marcel Logen
Nach meinen Beobachtungen sind auf dem tota-Server die Gruppen
betroffen, deren Name auf die Regex "test$" matcht, also z. B.
nicht "abg.test04" oder "alt.testing.testing".
Auch nicht "alt.test.d".

[...]
Post by Marcel Logen
Wurde vielleicht der CNFS-Buffer von Daniel am 18.11. um 0 Uhr
neu angelegt?
Oder am 17.11. um 20 Uhr oder früher?

Jedenfalls sind in "bln.test" noch Artikel von danach zu finden.

Ingrid
--
│ ╭────╮ ╭──╮ ..34..╭───╮ ╭───╮ ╭───╮ ╭─╮ ╭───╮ ╭─
╰──╮ ╭─╮ ..11..╰─╮ ╰─────╯ ╰───╮ ╭──╯ │ ╭─╯ ╰─╯ ╰─╯ ╰─╯ ╰──╯
╭─╯ │ │ ╭────╮ │ ╭──────────╯ │ ╭─╯ │ ..67..
╰────╯ ╰──╯ ╰─╯ ╰────────────╯ ╰───╯ ..67..
Daniel Weber
2023-11-19 16:45:26 UTC
Permalink
Post by Marcel Logen
Wurde vielleicht der CNFS-Buffer von Daniel am 18.11. um 0 Uhr
neu angelegt?
Nein...
Post by Marcel Logen
Danke, aber es ist mir immer noch nicht ganz klar, warum
am 18.11. um 0 Uhr der Buffer leer war (jedenfalls sah es
so aus) und sich jetzt langsam wieder füllt.
...und da er nicht neu angelegt wurde war er am 18.11. nicht leer.

Ich vermute, dass einfach am 17.11. irgendjemand in eine der
Test-Gruppen besonders viel Traffic abgeladen hat, dann "cycled" der
zugehörige CNFS-Puffer halt besonders schnell (und auch bisher hatten
die Test-Gruppen nur ca. 3 Tage).

Schöne Grüße
Daniel

Lesen Sie weiter auf narkive:
Loading...