Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
[INN] CNFS-Buffer (was: ignore 21095.15 - CNFS-Buffer)
1 view
Skip to first unread message
Marcel Logen
Nov 18, 2023, 12:46:41 PM11/18/23
to
Marcel Logen in de.test:
>Soweit ich weiß, werden die Testgruppen auf dem tota-Server
>in einem CNFS-Buffer (oder mehreren?) gespeichert.
>
><https://th-h.de/net/usenet/servers/inn/overview/>:
>
>| 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
><news:m2jzqgy...@cmschueller.my-fqdn.de> vorhanden.
>
>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..╰─
>Soweit ich weiß, werden die Testgruppen auf dem tota-Server
>in einem CNFS-Buffer (oder mehreren?) gespeichert.
>
><https://th-h.de/net/usenet/servers/inn/overview/>:
>
>| 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
><news:m2jzqgy...@cmschueller.my-fqdn.de> vorhanden.
>
>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
Nov 18, 2023, 5:16:00 PM11/18/23
to
Mahlzeit!
In de.comm.software.newsserver Marcel Logen <33320000...@ybtra.de> wrote:
> 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)
In de.comm.software.newsserver Marcel Logen <33320000...@ybtra.de> wrote:
> 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.
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
Nov 18, 2023, 5:59:13 PM11/18/23
to
Am 18.11.2023 um 23:15 schrieb 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.
> ¹ Oder wird er direkt initial leer mit maximaler Größer angelegt?
Ciao
Daniel
Marcel Logen
Nov 19, 2023, 10:11:33 AM11/19/23
to
Christian Garbs in de.comm.software.newsserver:
>In de.comm.software.newsserver Marcel Logen <33320000...@ybtra.de> wrote:
>> 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.
>Nein, bei einem Wraparound gehen nicht schlagartig alle Artikel
>verloren. Das ist ein klassischer Ringbuffer:
OK
>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
"Springt"? Wenn ich Dich richtig verstehe, kommt die Schreib-
position sozusagen wieder automatisch am Anfang vorbei.
>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:20231113...@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?
>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..╰──────╯ ╰─────────╯ ╰────╯ ╰
>In de.comm.software.newsserver Marcel Logen <33320000...@ybtra.de> wrote:
>> 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.
Röhre im Sinn, wo an einer Seite die Postings hineingeschoben
werden.
>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
position sozusagen wieder automatisch am Anfang vorbei.
>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.
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:20231113...@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?
>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 ;-)
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
Nov 19, 2023, 10:56:30 AM11/19/23
to
Marcel Logen in de.comm.software.newsserver:
[...]
>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".
[...]
>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..
[...]
>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".
[...]
>Wurde vielleicht der CNFS-Buffer von Daniel am 18.11. um 0 Uhr
>neu angelegt?
Jedenfalls sind in "bln.test" noch Artikel von danach zu finden.
Ingrid
--
│ ╭────╮ ╭──╮ ..34..╭───╮ ╭───╮ ╭───╮ ╭─╮ ╭───╮ ╭─
╰──╮ ╭─╮ ..11..╰─╮ ╰─────╯ ╰───╮ ╭──╯ │ ╭─╯ ╰─╯ ╰─╯ ╰─╯ ╰──╯
╭─╯ │ │ ╭────╮ │ ╭──────────╯ │ ╭─╯ │ ..67..
╰────╯ ╰──╯ ╰─╯ ╰────────────╯ ╰───╯ ..67..
Daniel Weber
Nov 19, 2023, 11:45:29 AM11/19/23
to
Am 19.11.2023 um 16:11 schrieb Marcel Logen:
> Wurde vielleicht der CNFS-Buffer von Daniel am 18.11. um 0 Uhr
> neu angelegt?
Nein...
> Wurde vielleicht der CNFS-Buffer von Daniel am 18.11. um 0 Uhr
> neu angelegt?
> 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.
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
0 new messages