schrijven zonder buffering?

[Rob]

Bestaat er ook een methode in Linux om een file te schrijven waarbij
deze niet tevens ook in de buffercache terecht komt?

Ik wil een (grote) file schrijven en ik heb geen noodzaak om hem
binnenkort weer te lezen. De blokken in de buffercache bewaren heeft
dus geen zin, en werkt bovendien contra-productief (omdat ik wel
ander dingen in het geheugen wil bewaren).

Hoe pak ik dat aan?

[unknown]

Bestaat er ook een methode in Linux om een file te schrijven waarbij deze
niet tevens ook in de buffercache terecht komt?
Ik wil een (grote) file schrijven en ik heb geen noodzaak om hem
binnenkort weer te lezen. De blokken in de buffercache bewaren heeft dus
geen zin, en werkt bovendien contra-productief (omdat ik wel ander dingen
in het geheugen wil bewaren).
Hoe pak ik dat aan?

http://stackoverflow.com/questions/4703946/unbuffered-i-o-in-linux

[Rob]

Post by unknown

Bestaat er ook een methode in Linux om een file te schrijven waarbij deze
niet tevens ook in de buffercache terecht komt?
Ik wil een (grote) file schrijven en ik heb geen noodzaak om hem
binnenkort weer te lezen. De blokken in de buffercache bewaren heeft dus
geen zin, en werkt bovendien contra-productief (omdat ik wel ander dingen
in het geheugen wil bewaren).
Hoe pak ik dat aan?

http://stackoverflow.com/questions/4703946/unbuffered-i-o-in-linux

Hmm kennelijk is er C-coding nodig om dit werkend te maken.

Ik zal een voorbeeld geven van hoe ik het wil inzetten:

Stel je wilt een backup maken naar een externe disk. Je plugt de
externe disk in, (auto)mount hem, en dan ga je als een idioot data
schrijven naar die disk.

Bijvoorbeeld "tar cf /media/usbdisk/backup1.tar /local" of iets
als "cp -a /local /media/usbdisk/local".

(extra detail vlaggetjes om dit helemaal goed te laten werken even
weggelaten, het gaat om het idee)

Wat iedere Linux gebruiker wel weet is dat als je dit doet op een
systeem waar je op zit te werken, de performance totaal wegzakt.
Veel erger dan bij Windows, bijvoorbeeld.

Hoe komt dit? Door de buffercache die vaak zo opgehemeld wordt.
"unused memory is wasted memory", je kent het wel. In die pagina
waar hierboven naar verwezen wordt komt ook weer iemand ermee.

Maar in dit geval is het totaal nutteloos. Het memory wordt gevuld
met allemaal copietjes van blokken die net naar die externe schijf
geschreven zijn, en om ruimte te maken voor al die shit worden blokken
van programma's die op dat moment draaien vrijgemaakt of zelfs
uitgeswapt! (als het r/w data is)

Gevolg: het systeem performed totaal niet meer. Als je wisselt van
virtueel scherm dan wordt het nieuwe scherm tergend langzaam opgebouwd,
e.d. Sterker nog: als het een beetje tegenzit dan is het zelfs
nauwelijks meer mogelijk om dit programma af te breken omdat het
systeem geen zin meer heeft om je terminal window in memory te houden
en je ^C signal te verwerken. Alles voor disk buffering.

En als je klaar bent unmount je de disk en wordt al dat memory op
slag weer vrijgegeven en komt de performance langzaam weer terug.

Wat je dus eigenlijk wilt is dat er wel wat buffering is om het schrijven
soepel te laten verlopen, maar dat ie niet alle geschreven blokken nog
weer eens als "recent" gaat zitten bestempelen en in memory voorrang
geeft boven andere blokken die 5 minuten geleden nog nodig waren.
Dit zou dus moeten kunnen door die outputfile O_DIRECT te openen. Maar
helaas zie ik in tar of cp geen opties om dat te doen.

Vroeger gebruikte ik in combinatie met tape nog wel eens het programma
"buffer":

tar cf - /local | buffer -o /dev/tape

Daarmee kon je dan voorkomen dat de tape steeds maar heen en weer
stond te spoelen. Dit lijkt me een plek waar ik eventueel een
O_DIRECT open zou kunnen doen van de outputfile maar ik zie in
buffer ook geen optie daarvoor.

Iemand een idee hoe dat zou kunnen zonder zelf een nieuwe tool
te gaan maken?

[unknown]

Stel je wilt een backup maken naar een externe disk. Je plugt de externe
disk in, (auto)mount hem, en dan ga je als een idioot data schrijven naar
die disk.
Bijvoorbeeld "tar cf /media/usbdisk/backup1.tar /local" of iets als "cp
-a /local /media/usbdisk/local".
(extra detail vlaggetjes om dit helemaal goed te laten werken even
weggelaten, het gaat om het idee)
Wat iedere Linux gebruiker wel weet is dat als je dit doet op een systeem
waar je op zit te werken, de performance totaal wegzakt. Veel erger dan
bij Windows, bijvoorbeeld.

Ik doe zoiets zeer regelmatig, grote (3-7GB) bestanden van lokaal naar
externe USB schijf schrijven. Meestal een GB of 70 tot 120 in totaal. Als
dat draait merk ik daar weinig van, terwijl de server in kwestie
tegelijkertijd ook gebruikt wordt als MythTV backend of fileserver voor
XBMC (waarbij het ding dus tijdens de kopieeractie ook videofiles over het
netwerk aan het streamen is).

En het is echt geen superhardware, de processor is een 2.6Ghz C2D die 90%
van de tijd op 1.2Ghz draait, met 2GB RAM.

e.d. Sterker nog: als het een beetje tegenzit dan is het zelfs
nauwelijks meer mogelijk om dit programma af te breken omdat het systeem
geen zin meer heeft om je terminal window in memory te houden en je ^C
signal te verwerken. Alles voor disk buffering.

Misschien helpt het om die schijf 'sync' te mounten?

[Rob]

Post by unknown

Stel je wilt een backup maken naar een externe disk. Je plugt de externe
disk in, (auto)mount hem, en dan ga je als een idioot data schrijven naar
die disk.
Bijvoorbeeld "tar cf /media/usbdisk/backup1.tar /local" of iets als "cp
-a /local /media/usbdisk/local".
(extra detail vlaggetjes om dit helemaal goed te laten werken even
weggelaten, het gaat om het idee)
Wat iedere Linux gebruiker wel weet is dat als je dit doet op een systeem
waar je op zit te werken, de performance totaal wegzakt. Veel erger dan
bij Windows, bijvoorbeeld.

Ik doe zoiets zeer regelmatig, grote (3-7GB) bestanden van lokaal naar
externe USB schijf schrijven. Meestal een GB of 70 tot 120 in totaal. Als
dat draait merk ik daar weinig van, terwijl de server in kwestie
tegelijkertijd ook gebruikt wordt als MythTV backend of fileserver voor
XBMC (waarbij het ding dus tijdens de kopieeractie ook videofiles over het
netwerk aan het streamen is).
En het is echt geen superhardware, de processor is een 2.6Ghz C2D die 90%
van de tijd op 1.2Ghz draait, met 2GB RAM.

Het moge duidelijk zijn dat de processor of de hoeveelheid RAM niet
relevant is, het gaat om het buffermanagement.
Hoe veel last je er van hebt hangt er vanaf wat je draait.
Bijvoorbeeld een internet browser onder X heeft er veel meer last van
dan een fileserver.

Post by unknown

e.d. Sterker nog: als het een beetje tegenzit dan is het zelfs
nauwelijks meer mogelijk om dit programma af te breken omdat het systeem
geen zin meer heeft om je terminal window in memory te houden en je ^C
signal te verwerken. Alles voor disk buffering.

Misschien helpt het om die schijf 'sync' te mounten?

Dat denk ik niet.
Die O_DIRECT ziet er op zich goed uit, ik ben alleen op zoek naar hoe
ik die bij de open kan krijgen die in een bestaand tool zit.

[unknown]

Post by Rob

Post by unknown
En het is echt geen superhardware, de processor is een 2.6Ghz C2D die
90% van de tijd op 1.2Ghz draait, met 2GB RAM.

Het moge duidelijk zijn dat de processor of de hoeveelheid RAM niet
relevant is, het gaat om het buffermanagement. Hoe veel last je er van
hebt hangt er vanaf wat je draait. Bijvoorbeeld een internet browser
onder X heeft er veel meer last van dan een fileserver.

Als jij al problemen hebt met het openen van een VT zou een fileserver ook
problemen moeten vertonen. Op dezelfde machine draaien een paar OpenVZ
containers met o.a. deze slrn (in een screen) erin, ook daar merk ik weinig
tot niks van zo'n kopieeractie.

Het zou kunnen, maar dat kan ik nu niet testen, dat de schijf vanwege het
fs dat erop staat juist 'sync' gemount wordt, wat me op het volgende

Post by Rob

Post by unknown
Misschien helpt het om die schijf 'sync' te mounten?

Dat denk ik niet.

Ik wel, daarmee wordt write-buffering (wat jouw probleem is, volgens
jezelf) uitgeschakeld.

Anders bestaat er ook nog dit:
http://superuser.com/questions/242928/disable-linux-read-and-write-file-cache-on-partition/464382#464382

[Rob]

Post by unknown

Post by Rob

Post by unknown
En het is echt geen superhardware, de processor is een 2.6Ghz C2D die
90% van de tijd op 1.2Ghz draait, met 2GB RAM.

Het moge duidelijk zijn dat de processor of de hoeveelheid RAM niet
relevant is, het gaat om het buffermanagement. Hoe veel last je er van
hebt hangt er vanaf wat je draait. Bijvoorbeeld een internet browser
onder X heeft er veel meer last van dan een fileserver.

Als jij al problemen hebt met het openen van een VT zou een fileserver ook
problemen moeten vertonen. Op dezelfde machine draaien een paar OpenVZ
containers met o.a. deze slrn (in een screen) erin, ook daar merk ik weinig
tot niks van zo'n kopieeractie.

Nee nee dan snap je de issue toch niet goed.
Het is alleen een probleem op werkstations, niet (of veel minder) op
servers.

Post by unknown
Het zou kunnen, maar dat kan ik nu niet testen, dat de schijf vanwege het
fs dat erop staat juist 'sync' gemount wordt, wat me op het volgende

Post by Rob

Post by unknown
Misschien helpt het om die schijf 'sync' te mounten?

Dat denk ik niet.

Ik wel, daarmee wordt write-buffering (wat jouw probleem is, volgens
jezelf) uitgeschakeld.

Nee je hebt het niet goed begrepen. Het gaat niet om de write buffering
zelf. maar om het probleem dat de buffers na het schrijven gewoon memory
blijven innemen omdat ze "vers" zijn.
Lees het eventueel nog eens rustig door.

Post by unknown
http://superuser.com/questions/242928/disable-linux-read-and-write-file-cache-on-partition/464382#464382

Dat zou interessant kunnen zijn. Nu moet ik eerst ander werk doen
maar ik ga hier nog naar kijken...

[unknown]

Post by Rob

Post by unknown
Ik wel, daarmee wordt write-buffering (wat jouw probleem is, volgens
jezelf) uitgeschakeld.

Nee je hebt het niet goed begrepen. Het gaat niet om de write buffering
zelf. maar om het probleem dat de buffers na het schrijven gewoon memory
blijven innemen omdat ze "vers" zijn.

"uitschakelen". Als in: de data die je naar een sync-mounted schijf
schrijft komen helemaal niet in buffermemory terecht. En dus zit je ook
niet met het probleem dat al aanwezige data in die buffers weggemikt
wordt waardoor je machine traag gaat voelen.

Post by Rob
Lees het eventueel nog eens rustig door.

Och, ik heb wel iets beters te doen. Veel succes er verder mee!

[Rob]

Post by unknown

Post by Rob

Post by unknown
Ik wel, daarmee wordt write-buffering (wat jouw probleem is, volgens
jezelf) uitgeschakeld.

Nee je hebt het niet goed begrepen. Het gaat niet om de write buffering
zelf. maar om het probleem dat de buffers na het schrijven gewoon memory
blijven innemen omdat ze "vers" zijn.

"uitschakelen". Als in: de data die je naar een sync-mounted schijf
schrijft komen helemaal niet in buffermemory terecht. En dus zit je ook
niet met het probleem dat al aanwezige data in die buffers weggemikt
wordt waardoor je machine traag gaat voelen.

Dat is niet wat sync mounted doet.
Dit wil zeggen dat alles meteen weggeschreven wordt en het resultaat
gechecked, niet dat het niet in buffers terecht komt.

Post by unknown

Post by Rob
Lees het eventueel nog eens rustig door.

Och, ik heb wel iets beters te doen. Veel succes er verder mee!

Bedankt, ik zoek verder en laat me niet afleiden door standaardkreten.

[unknown]

Post by unknown

Post by Rob
Nee je hebt het niet goed begrepen. Het gaat niet om de write
buffering zelf. maar om het probleem dat de buffers na het schrijven
gewoon memory blijven innemen omdat ze "vers" zijn.

"uitschakelen". Als in: de data die je naar een sync-mounted schijf
schrijft komen helemaal niet in buffermemory terecht. En dus zit je ook
niet met het probleem dat al aanwezige data in die buffers weggemikt
wordt waardoor je machine traag gaat voelen.

Dat is niet wat sync mounted doet. Dit wil zeggen dat alles meteen
weggeschreven wordt en het resultaat gechecked, niet dat het niet in
buffers terecht komt.

Vertel dat tegen alle personen die in Linuxfora de vraag 'hoe moet ik write
buffering uitzetten?' antwoorden 'mount de drive met "sync"'. Als je zoekt
op 'linux mount sync disable write buffering' kan je ze vinden.

[Rob]

Post by unknown

Post by unknown

Post by Rob
Nee je hebt het niet goed begrepen. Het gaat niet om de write
buffering zelf. maar om het probleem dat de buffers na het schrijven
gewoon memory blijven innemen omdat ze "vers" zijn.

"uitschakelen". Als in: de data die je naar een sync-mounted schijf
schrijft komen helemaal niet in buffermemory terecht. En dus zit je ook
niet met het probleem dat al aanwezige data in die buffers weggemikt
wordt waardoor je machine traag gaat voelen.

Dat is niet wat sync mounted doet. Dit wil zeggen dat alles meteen
weggeschreven wordt en het resultaat gechecked, niet dat het niet in
buffers terecht komt.

Vertel dat tegen alle personen die in Linuxfora de vraag 'hoe moet ik write
buffering uitzetten?' antwoorden 'mount de drive met "sync"'. Als je zoekt
op 'linux mount sync disable write buffering' kan je ze vinden.

Als iedereen hetzelfde antwoord geeft wil dat nog niet zeggen dat ze
het goed hebben! Die link waar jij naar verwees die had wel twee goede
antwoorden maar daar zat ook zo'n loser bij die erover begon dat je dit
helemaal niet moet willen en dat de buffercache geweldig is. Dat soort
mensen heb je nou eenmaal altijd.

Bovendien is 'hoe moet ik write buffering uitzetten?' geen goede vraag omdat
dit voor meerdere uitleg vatbaar is. Sommige mensen bedoelen hiermee dat
ze niet willen dat een proces wat een file schrijft een OK antwoord
krijgt terwijl de data in werkelijkheid nog in memory staat en pas een
halve seconde later door bdflush naar disk geschreven wordt, wat dan
fout kan gaan. Dat is een terecht punt, en als je dat niet wilt kun
je sync mounten.

Maar met wat ik bedoel (en wat ik in mijn OP duidelijk beschreven heb)
is heel wat anders.

[unknown]

Als iedereen hetzelfde antwoord geeft wil dat nog niet zeggen dat ze het
goed hebben!

Gelukkig dan maar dat jij het altijd beter weet.

[Rob]

Post by unknown

Als iedereen hetzelfde antwoord geeft wil dat nog niet zeggen dat ze het
goed hebben!

Gelukkig dan maar dat jij het altijd beter weet.

Ja precies, daar ben ik heel vaak heel erg blij mee.

[Dick Streefland]

Rob <***@example.com> wrote:
| Dat denk ik niet.
| Die O_DIRECT ziet er op zich goed uit, ik ben alleen op zoek naar hoe
| ik die bij de open kan krijgen die in een bestaand tool zit.

Zo te zien doet "dd oflag=direct" wat je wilt.

[Rob]

Post by Dick Streefland
| Dat denk ik niet.
| Die O_DIRECT ziet er op zich goed uit, ik ben alleen op zoek naar hoe
| ik die bij de open kan krijgen die in een bestaand tool zit.
Zo te zien doet "dd oflag=direct" wat je wilt.

Ahhh dd! Dat ik daar niet gekeken heb... bedankt!

[Rob]

Post by Rob

Post by Dick Streefland
| Dat denk ik niet.
| Die O_DIRECT ziet er op zich goed uit, ik ben alleen op zoek naar hoe
| ik die bij de open kan krijgen die in een bestaand tool zit.
Zo te zien doet "dd oflag=direct" wat je wilt.

Ahhh dd! Dat ik daar niet gekeken heb... bedankt!

Dit blijkt inderdaad goed te werken!

Probeer dit maar eens:

dd if=/dev/zero of=/tmp/x bs=128k oflag=direct

(dit moet je natuurlijk na een tijdje afbreken en dan die /tmp/x weer weggooien)

Degenen die het allemaal niet geloven of "nooit gezien hebben", start
dat commando vooral een keer op zonder die oflag=direct en kijk wat
er dan gebeurt met de werkbaarheid van je X applicaties zoals browser
en terminal schermen.
Hou maar eens in de gaten wat "free" zegt terwijl je dat uitvoert.
(als het je nog lukt om iets als free of df uit te voeren in een xterm
of konsole)

Dit is duidelijk iets om in het backup script in te voeren.
Bedankt Dick!

[marc]

Post by Rob
Bestaat er ook een methode in Linux om een file te schrijven waarbij
deze niet tevens ook in de buffercache terecht komt?

fflush in C, zelfs flush in tcl ;-)


FFLUSH(3) Linux
Programmer's Manual
FFLUSH(3)

NAME
fflush - flush a stream

SYNOPSIS
#include <stdio.h>

int fflush(FILE *stream);

DESCRIPTION
For output streams, fflush() forces a write of all user-space
buffered data for the given output or update stream via the stream's
underlying
write function. For input streams, fflush() discards any buffered
data that has been fetched from the underlying file, but has not been
consumed
by the application. The open status of the stream is unaffected.

If the stream argument is NULL, fflush() flushes all open output
streams.

For a nonlocking counterpart, see unlocked_stdio(3).

RETURN VALUE
Upon successful completion 0 is returned. Otherwise, EOF is returned
and errno is set to indicate the error.

ERRORS
EBADF Stream is not an open stream, or is not open for writing.

The function fflush() may also fail and set errno for any of the
errors specified for write(2).

CONFORMING TO
C89, C99, POSIX.1-2001, POSIX.1-2008.

The standards do not specify the behavior for input streams. Most
other implementations behave the same as Linux.

NOTES
Note that fflush() only flushes the user space buffers provided by
the C library. To ensure that the data is physically stored on disk the
kernel
buffers must be flushed too, for example, with sync(2) or fsync(2).

SEE ALSO
fsync(2), sync(2), write(2), fclose(3), fopen(3), setbuf(3),
unlocked_stdio(3)
...

[Rob]

Post by marc

Post by Rob
Bestaat er ook een methode in Linux om een file te schrijven waarbij
deze niet tevens ook in de buffercache terecht komt?

fflush in C, zelfs flush in tcl ;-)
FFLUSH(3) Linux
Programmer's Manual
FFLUSH(3)

Zie je wel Robert, dat er mensen een antwoord geven betekent nog
niet dat ze er wat van snappen!

[unknown]

Post by Rob

Post by marc

Post by Rob
Bestaat er ook een methode in Linux om een file te schrijven waarbij
deze niet tevens ook in de buffercache terecht komt?

fflush in C, zelfs flush in tcl ;-)
FFLUSH(3) Linux
Programmer's Manual
FFLUSH(3)

Zie je wel Robert, dat er mensen een antwoord geven betekent nog
niet dat ze er wat van snappen!

Een compleet onnodige en aanmatigende opmerking, Rob.

[Jan van den Broek]

Post by marc

Post by Rob
Bestaat er ook een methode in Linux om een file te schrijven waarbij
deze niet tevens ook in de buffercache terecht komt?

fflush in C, zelfs flush in tcl ;-)

Dat heeft met buffering te maken, maar Rob heeft daar niet veel aan.
fflush leegt buffers, Rob wil juist dat ze niet gevuld worden.
(setbuf had een betere suggestie geweest.)

[Rob]

Post by Jan van den Broek

Post by marc

Post by Rob
Bestaat er ook een methode in Linux om een file te schrijven waarbij
deze niet tevens ook in de buffercache terecht komt?

fflush in C, zelfs flush in tcl ;-)

Dat heeft met buffering te maken, maar Rob heeft daar niet veel aan.
fflush leegt buffers, Rob wil juist dat ze niet gevuld worden.
(setbuf had een betere suggestie geweest.)

Nee ook dat heeft er niks mee te maken.
Het gaat niet over locale filebuffers in processen maar over de
buffer cache.
Je weet wel dat wat je ziet met "free".

[Jan van den Broek]

Post by Rob

Post by Jan van den Broek

Post by marc

Post by Rob
Bestaat er ook een methode in Linux om een file te schrijven waarbij
deze niet tevens ook in de buffercache terecht komt?

fflush in C, zelfs flush in tcl ;-)

Dat heeft met buffering te maken, maar Rob heeft daar niet veel aan.
fflush leegt buffers, Rob wil juist dat ze niet gevuld worden.
(setbuf had een betere suggestie geweest.)

Nee ook dat heeft er niks mee te maken.
Het gaat niet over locale filebuffers in processen maar over de
buffer cache.

Ik zal eerlijk zeggen setbuf het eerste was wat zo bij mij opkwam,
ik heb verder niet nagekeken wat het precies doet, ik heb het
met name gebruikt om zaken zonder buffering in te lezen.

Post by Rob
Je weet wel dat wat je ziet met "free".

Die "free" kende ik niet, tot nu toe nog niet nodig gehad kennelijk.

[Rob]

Post by Jan van den Broek

Post by Rob

Post by Jan van den Broek

Post by marc

Post by Rob
Bestaat er ook een methode in Linux om een file te schrijven waarbij
deze niet tevens ook in de buffercache terecht komt?

fflush in C, zelfs flush in tcl ;-)

Dat heeft met buffering te maken, maar Rob heeft daar niet veel aan.
fflush leegt buffers, Rob wil juist dat ze niet gevuld worden.
(setbuf had een betere suggestie geweest.)

Nee ook dat heeft er niks mee te maken.
Het gaat niet over locale filebuffers in processen maar over de
buffer cache.

Ik zal eerlijk zeggen setbuf het eerste was wat zo bij mij opkwam,
ik heb verder niet nagekeken wat het precies doet, ik heb het
met name gebruikt om zaken zonder buffering in te lezen.

Als je wilt weten waar ik het over heb dan moet je maar even
googlen naar "linux buffer cache".
Ik krijg hier als 1e resultaat:

http://linux.about.com/od/lsa_guide/a/gdelsa44.htm

Daarin wordt vrij kort en duidelijk uitgelegd hoe het werkt, maar
de nadelen komen daarin niet ter sprake. Er zijn veel van dit soort
artikelen en als je er een vraag over stelt zijn er altijd voldoende
mensen die alleen dit goede nieuws gelezen hebben en enthousiast
vertellen hoe geweldig het werkt, maar helaas heeft het ook andere
kanten. In mijn 2e posting in deze thread heb ik wat meer uitgelegd
wat er fout kan gaan.

[unknown]

Als je wilt weten waar ik het over heb dan moet je maar even googlen naar
http://linux.about.com/od/lsa_guide/a/gdelsa44.htm
Daarin wordt vrij kort en duidelijk uitgelegd hoe het werkt, maar de
nadelen komen daarin niet ter sprake. Er zijn veel van dit soort
artikelen en als je er een vraag over stelt zijn er altijd voldoende
mensen die alleen dit goede nieuws gelezen hebben en enthousiast
vertellen hoe geweldig het werkt, maar helaas heeft het ook andere
kanten.

Je bent er ongetwijfeld van op de hoogte dat je dat soort spul al jarenlang
kunt tunen, tot aparte 'desktop' schedulers aan toe.

[Rob]

Post by unknown

Als je wilt weten waar ik het over heb dan moet je maar even googlen naar
http://linux.about.com/od/lsa_guide/a/gdelsa44.htm
Daarin wordt vrij kort en duidelijk uitgelegd hoe het werkt, maar de
nadelen komen daarin niet ter sprake. Er zijn veel van dit soort
artikelen en als je er een vraag over stelt zijn er altijd voldoende
mensen die alleen dit goede nieuws gelezen hebben en enthousiast
vertellen hoe geweldig het werkt, maar helaas heeft het ook andere
kanten.

Je bent er ongetwijfeld van op de hoogte dat je dat soort spul al jarenlang
kunt tunen, tot aparte 'desktop' schedulers aan toe.

Ja dat weet ik. Via /etc/sysctl.conf heb ik wel eens wat ingesteld.

Maar die methode van Dick werkt veel beter!

[unknown]

Post by Rob

Post by unknown
Je bent er ongetwijfeld van op de hoogte dat je dat soort spul al
jarenlang kunt tunen, tot aparte 'desktop' schedulers aan toe.

Ja dat weet ik. Via /etc/sysctl.conf heb ik wel eens wat ingesteld.
Maar die methode van Dick werkt veel beter!

Voor een enkele file, ja. Het is wachten op de keer dat je een find of du
draait op / om vervolgens hier te komen klagen dat daarna je systeem weer
zo traag is...

[Rob]

Post by unknown

Post by Rob

Post by unknown
Je bent er ongetwijfeld van op de hoogte dat je dat soort spul al
jarenlang kunt tunen, tot aparte 'desktop' schedulers aan toe.

Ja dat weet ik. Via /etc/sysctl.conf heb ik wel eens wat ingesteld.
Maar die methode van Dick werkt veel beter!

Voor een enkele file, ja. Het is wachten op de keer dat je een find of du
draait op / om vervolgens hier te komen klagen dat daarna je systeem weer
zo traag is...

Nou nee dat heb ik wel onder controle kunnen krijgen.
Vroeger had ik wel dat probleem dat als ik na een weekend bij
mijn werkstation op het werk kwam dat hij eerst 5 minuten aan het
inswappen was als ik de muis bewoog, omdat hij in de tussentijd
alleen maar via ssh gebruikt was, maar dat probleem is er nu niet
meer zo.

[Philip Paeps]

Post by Rob
Bestaat er ook een methode in Linux om een file te schrijven waarbij
deze niet tevens ook in de buffercache terecht komt?

Lange thread met veel onzin, maar nog geen antwoord tegengekomen.

LD_PRELOAD een utility library die open() wrapt en O_DIRECT meegeeft.
Vergeet ook niet open64() te wrappen als je bestaand programma die
gebruikt. Eventueel __open() en __open64() ook.

Uit de losse pols:

static int (*real_open)(const char *, int, ...);
int open(const char *, int, ...) __attribute__((weak, alias("fake_open")));

int fake_open(const char *path, int oflag, ...)
{
va_list args;
mode_t mode;

va_start(args, oflag);
mode = va_args(args, mode_t);
va_end(args);

oflag |= O_DIRECT;

return (real_open(path, oflag, mode));
}

void _init(void)
{

real_open = dlsym(RTLD_NEXT, "open");
assert (real_open != NULL);
}

Niet vergeten te linken met -ldl.

- Philip

[Rob]

Post by Philip Paeps

Post by Rob
Bestaat er ook een methode in Linux om een file te schrijven waarbij
deze niet tevens ook in de buffercache terecht komt?

Lange thread met veel onzin, maar nog geen antwoord tegengekomen.

Er is al een makkelijk bruikbaar antwoord voor een pipeline gegeven
(met gebruik van dd) en ook een verwijzing naar een google code pagina
waar een compleet pakket op staat wat doet wat jij beschrijft.

Misschien dat ik dat toch wel ga gebruiken ipv dd want nu ik in mijn
backup script duik zie ik dat er staat:

tar cvzf $DIR/local.tar.gz /local | gzip -9 >$DIR/local.lst.gz

dus toch weer niet zo simpel om daar een dd tussen te frommelen...

[Philip Paeps]

Post by Rob

Post by Philip Paeps

Post by Rob
Bestaat er ook een methode in Linux om een file te schrijven waarbij
deze niet tevens ook in de buffercache terecht komt?

Lange thread met veel onzin, maar nog geen antwoord tegengekomen.

Er is al een makkelijk bruikbaar antwoord voor een pipeline gegeven
(met gebruik van dd) en ook een verwijzing naar een google code pagina
waar een compleet pakket op staat wat doet wat jij beschrijft.

Die heb ik gemist dan. Maar ik heb niet de gewoonte om web-links op
Usenet te volgen. Er staat nog meer onzin op het web dan op Usenet. ;)

Post by Rob
Misschien dat ik dat toch wel ga gebruiken ipv dd want nu ik in mijn
tar cvzf $DIR/local.tar.gz /local | gzip -9 >$DIR/local.lst.gz
dus toch weer niet zo simpel om daar een dd tussen te frommelen...

Je bespaart ook een fork/exec uit door gewoon de functie te wrappen. Ik
heb zo nog wel wat pareltjes in mijn $HOME/lib zitten.

- Philip

[unknown]

Post by Philip Paeps

Post by Philip Paeps

Post by Rob
Bestaat er ook een methode in Linux om een file te schrijven waarbij
deze niet tevens ook in de buffercache terecht komt?

Lange thread met veel onzin, maar nog geen antwoord tegengekomen.

Er is al een makkelijk bruikbaar antwoord voor een pipeline gegeven (met
gebruik van dd) en ook een verwijzing naar een google code pagina waar
een compleet pakket op staat wat doet wat jij beschrijft.

Die heb ik gemist dan. Maar ik heb niet de gewoonte om web-links op
Usenet te volgen.

http://instantrimshot.com/index.php?sound=rimshot&play=true

[Rob]

Post by Philip Paeps

Post by Rob

Post by Philip Paeps

Post by Rob
Bestaat er ook een methode in Linux om een file te schrijven waarbij
deze niet tevens ook in de buffercache terecht komt?

Lange thread met veel onzin, maar nog geen antwoord tegengekomen.

Er is al een makkelijk bruikbaar antwoord voor een pipeline gegeven
(met gebruik van dd) en ook een verwijzing naar een google code pagina
waar een compleet pakket op staat wat doet wat jij beschrijft.

Die heb ik gemist dan. Maar ik heb niet de gewoonte om web-links op
Usenet te volgen. Er staat nog meer onzin op het web dan op Usenet. ;)

Ja maar wijs daar vooral niet op want dan worden er mensen boos :)


Inmiddels heb ik een nieuw probleem ontdekt...

Ik had deze workaround bedacht voor mijn pipeline probleem:

tar cvzf - /local 2> >(gzip -9 >$DIR/tar.lst.gz) | dd of=$DIR/local.tar.gz oflag=direct

Dat werkt op zich wel een beetje maar aan het eind komt er:

dd: writing `local.tar.gz': Invalid argument
3442+1 records in
3442+0 records out

(even een testje gedaan met een andere directory)

Hoe komt dat? Omdat een met O_DIRECT geopende file alleen writes
accepteert ter grootte van de blocksize. Bummer.

Dat is dan weer op te lossen door dd te laten padden:

tar cvzf - /local 2> >(gzip -9 >$DIR/tar.lst.gz) | dd bs=4k conv=sync of=$DIR/local.tar.gz oflag=direct

en dat werkt. Met jouw oplossing lukt dit niet zo makkelijk denk
ik :-)
(of wil je dan ook de write call gaan aanpassen door een die pad)

[Philip Paeps]

Post by Rob

Post by Philip Paeps

Post by Rob

Post by Philip Paeps

Post by Rob
Bestaat er ook een methode in Linux om een file te schrijven waarbij
deze niet tevens ook in de buffercache terecht komt?

Lange thread met veel onzin, maar nog geen antwoord tegengekomen.

Er is al een makkelijk bruikbaar antwoord voor een pipeline gegeven
(met gebruik van dd) en ook een verwijzing naar een google code pagina
waar een compleet pakket op staat wat doet wat jij beschrijft.

Die heb ik gemist dan. Maar ik heb niet de gewoonte om web-links op
Usenet te volgen. Er staat nog meer onzin op het web dan op Usenet. ;)

Ja maar wijs daar vooral niet op want dan worden er mensen boos :)

:-)

Post by Rob
Hoe komt dat? Omdat een met O_DIRECT geopende file alleen writes
accepteert ter grootte van de blocksize. Bummer.

Klopt.

Post by Rob
tar cvzf - /local 2> >(gzip -9 >$DIR/tar.lst.gz) | dd bs=4k conv=sync of=$DIR/local.tar.gz oflag=direct
en dat werkt. Met jouw oplossing lukt dit niet zo makkelijk denk
ik :-)
(of wil je dan ook de write call gaan aanpassen door een die pad)

Ik zou in dit specifieke geval tar gewoon -b 8 meegeven.

- Philip

[Rob]

Post by Philip Paeps

Post by Rob
tar cvzf - /local 2> >(gzip -9 >$DIR/tar.lst.gz) | dd bs=4k conv=sync of=$DIR/local.tar.gz oflag=direct
en dat werkt. Met jouw oplossing lukt dit niet zo makkelijk denk
ik :-)
(of wil je dan ook de write call gaan aanpassen door een die pad)

Ik zou in dit specifieke geval tar gewoon -b 8 meegeven.

Dat werkt niet. Ik denk dat de blocking gebeurt met de input van
gzip die het vervolgens wegcomprimeert.

[Philip Paeps]

Post by Rob

Post by Philip Paeps

Post by Rob
tar cvzf - /local 2> >(gzip -9 >$DIR/tar.lst.gz) | dd bs=4k conv=sync of=$DIR/local.tar.gz oflag=direct
en dat werkt. Met jouw oplossing lukt dit niet zo makkelijk denk
ik :-)
(of wil je dan ook de write call gaan aanpassen door een die pad)

Ik zou in dit specifieke geval tar gewoon -b 8 meegeven.

Dat werkt niet. Ik denk dat de blocking gebeurt met de input van
gzip die het vervolgens wegcomprimeert.

Dat lijkt me een bug. De bestaansreden voor die -b parameter is het
ondersteunen van fixed-blocksize tape devices.

Werkt het met bzip2 compressie wel?

Als je bestaande tool inderdaad geen zinvolle manier heeft om je
blocksize/alignment aan te geven, kan je met een wrapper weinig beginnen
(of je moet veel wrappen, en dan stijgt het risico voor bugs). Je kàn
inderdaad write() en consoorten ook wrappen, maar ... ik zou er niet aan
beginnen. :)

- Philip

[Rob]

Post by Philip Paeps

Post by Rob

Post by Philip Paeps

Post by Rob
tar cvzf - /local 2> >(gzip -9 >$DIR/tar.lst.gz) | dd bs=4k conv=sync of=$DIR/local.tar.gz oflag=direct
en dat werkt. Met jouw oplossing lukt dit niet zo makkelijk denk
ik :-)
(of wil je dan ook de write call gaan aanpassen door een die pad)

Ik zou in dit specifieke geval tar gewoon -b 8 meegeven.

Dat werkt niet. Ik denk dat de blocking gebeurt met de input van
gzip die het vervolgens wegcomprimeert.

Dat lijkt me een bug. De bestaansreden voor die -b parameter is het
ondersteunen van fixed-blocksize tape devices.

Ja dat klopt, maar ik denk dat tar niet vaak in combinatie met de z optie
gebruikt wordt op tapedrives. Die kunnen dat comprimeren meestal zelf.

Post by Philip Paeps
Werkt het met bzip2 compressie wel?
Als je bestaande tool inderdaad geen zinvolle manier heeft om je
blocksize/alignment aan te geven, kan je met een wrapper weinig beginnen
(of je moet veel wrappen, en dan stijgt het risico voor bugs). Je k??n
inderdaad write() en consoorten ook wrappen, maar ... ik zou er niet aan
beginnen. :)

Nee en het blijft zowizo een beetje tricky allemaal.
Met die dd bs=4k conv=sync lijkt het te werken.
Maar de performance was nog beter met een grotere bs.
Dus ik dacht ik maak van die 4k gewoon 400k, dat maakt niet uit voor
wat de dd moet doen alleen verspil ik hooguit 400k aan het eind van
de backup.
Echter, als ik dat doe dan raken de outputfiles corrupt. tar xvzf
kan ze niet meer lezen.
Ofwel die conv=sync doet iets anders dan ik denk, ofwel er zit ergens
een nog meer tricky bug.

Dit ben ik nog aan het onderzoeken, maar ik meld het maar even voor
degenen die enthousiast hun scripts gaan aanpassen: test wel even of
het resultaat wel leesbaar is!

[Martijn van Buul]

Post by Rob
Dus ik dacht ik maak van die 4k gewoon 400k, dat maakt niet uit voor
wat de dd moet doen alleen verspil ik hooguit 400k aan het eind van
de backup.
Echter, als ik dat doe dan raken de outputfiles corrupt. tar xvzf
kan ze niet meer lezen.
Ofwel die conv=sync doet iets anders dan ik denk, ofwel er zit ergens
een nog meer tricky bug.

Ik vermoed dat het een gevolg is van de pipe-implementatie van Linux. Zie
pipe(7):

Pipe Capacity
A pipe has a limited capacity. If the pipe is full, then a write(2) will
block or fail, depending on whether the O_NONBLOCK flag is set (see
below). Different implementations have different limits for the pipe
capacity. Applications should not rely on a particular capacity: an
application should be designed so that a reading process consumes data as
soon as it is available, so that a writing process does not remain
blocked.

In Linux versions before 2.6.11, the capacity of a pipe was the same as
the system page size (e.g., 4096 bytes on i386). Since Linux 2.6.11, the
pipe capacity is 65536 bytes.

Met bs=400k zit je dus ruim boven de grootte van die pipe. Alle reads
zullen om die redenen altijd minder dan 400KB opleveren, met als gevolg dat dd
niet alleen het *laatste* block van je file gaat padden, maar *ieder* block.

Er van uitgaande dat je >2.6.11 gebruikt is 64k dus de maximum blocksize.

Post by Rob
Dit ben ik nog aan het onderzoeken, maar ik meld het maar even voor
degenen die enthousiast hun scripts gaan aanpassen: test wel even of
het resultaat wel leesbaar is!

Geldt dat niet voor alles wat je met backups doet?

[Rob]

Post by Martijn van Buul

Post by Rob
Dus ik dacht ik maak van die 4k gewoon 400k, dat maakt niet uit voor
wat de dd moet doen alleen verspil ik hooguit 400k aan het eind van
de backup.
Echter, als ik dat doe dan raken de outputfiles corrupt. tar xvzf
kan ze niet meer lezen.
Ofwel die conv=sync doet iets anders dan ik denk, ofwel er zit ergens
een nog meer tricky bug.

Ik vermoed dat het een gevolg is van de pipe-implementatie van Linux. Zie
Pipe Capacity
A pipe has a limited capacity. If the pipe is full, then a write(2) will
block or fail, depending on whether the O_NONBLOCK flag is set (see
below). Different implementations have different limits for the pipe
capacity. Applications should not rely on a particular capacity: an
application should be designed so that a reading process consumes data as
soon as it is available, so that a writing process does not remain
blocked.
In Linux versions before 2.6.11, the capacity of a pipe was the same as
the system page size (e.g., 4096 bytes on i386). Since Linux 2.6.11, the
pipe capacity is 65536 bytes.
Met bs=400k zit je dus ruim boven de grootte van die pipe. Alle reads
zullen om die redenen altijd minder dan 400KB opleveren, met als gevolg dat dd
niet alleen het *laatste* block van je file gaat padden, maar *ieder* block.
Er van uitgaande dat je >2.6.11 gebruikt is 64k dus de maximum blocksize.

Ja dat zou het inderdaad wel eens kunnen zijn.
Eigenlijk moet ik toch geen dd ertussen hebben maar meer iets als buffer,
wat helaas geen padding en O_DIRECT support.
Dus wellicht dan toch maar zelf iets knutselen of buffer aanpassen. Of
een aparte ibs en obs aangeven voor dd.

Post by Martijn van Buul

Post by Rob
Dit ben ik nog aan het onderzoeken, maar ik meld het maar even voor
degenen die enthousiast hun scripts gaan aanpassen: test wel even of
het resultaat wel leesbaar is!

Geldt dat niet voor alles wat je met backups doet?

Ja ik test dit soort dingen uiteraard (anders was het me niet opgevallen)
maar ik weet dat er heel veel mensen zijn die al hardstikke trots zijn
dat ze een scriptje hebben kunnen maken, en het dan meteen op usenet
(of het web) pletteren terwijl er allerlei problemen mee zijn. Dat is
ook de reden dat ik zelf onderzoek of claims wel waar zijn ipv af te
gaan op "heel veel mensen geven dit antwoord"...

[Martijn van Buul]

Met bs=400k zit je dus ruim boven de grootte van die pipe. Alle reads zullen
om die redenen altijd minder dan 400KB opleveren, met als gevolg dat dd niet
alleen het *laatste* block van je file gaat padden, maar *ieder* block.

Yup, maar niet helemaal:

Script started on Mon Oct 8 18:08:29 2012

atlas(0):/tmp% dd if=/dev/zero bs=4k count=200 | dd of=bla bs=400k conv=sync
200+0 records in
200+0 records out
819200 bytes (819 kB) copied, 0.00768104 s, 107 MB/s
0+8 records in
8+0 records out
3276800 bytes (3.3 MB) copied, 0.00834485 s, 393 MB/s
atlas(0):/tmp% du -h bla
3.2M bla

Script done on Mon Oct 8 18:09:59 2012

De eerste dd schrijft braaf 800[1] KB[2] weg, in 200 records. De tweede
dd leest die data in 8 records in (en niet in ceil(800/64) = 13 records,
zoals ik had verwacht), pad dit vervolgens naar blocks van 400KB[2] elk,
en schrijft vervolgens 8*400=3200KB weg.

Wat ik dus niet helemaal begrijp is waar die 8 records vandaan komen.
Blijkkbaar is man(7) niet helemaal correct (het blijft Linux), en krijgt
dd het af en toe voor elkaar om meer dan 64 KB in te lezen in een enkele
read. Zoals ik de manpage interpreteer zou dat niet moeten kunnen.

Dat gezegd hebbende: Bij een blocksize van 64KB gaat het wel goed
(geen short reads), alles daarboven geeft willekeurig gedrag, en de vraag
is dus in hoeverre bs=64k eigenlijk wel betrouwbaar is.

[1] Welke prutsmuts heeft er nou weer voor gezorgd dat de output van dd
de politiek-correcte-maar-bijzonder-onhandige SI-definitie van
"kilo" gebruikt (1000), terwijl er bij het parsen van de commandline
opties de veel logischere (maar te moeilijk voor het gepeupel)
definitie van 1024[2] aanhoudt. Bah. Die kibiwibitibipribipruts is
al erg zat *zonder* inconsequent gedrag.
[2] Eigenlijk had daar KiB moeten staan, maar dat vertik ik.

[Rob]

Inmiddels ben ik erachter dat het probleem met de performance wat ik
probeerde op te lossen alleen speelt als het output device mijn locale
disk is.

Tja dit is natuurlijk het nadeel van het buitenspel zetten van de OS
disk buffering. Die zal normaal gesproken meer data verzamelen om
die in grotere chunks naar de disk te schrijven en dat gaat dan
sneller. Wellicht ook minder seeks.

Alleen jammer dat het dan ook in de buffer cache bewaard wordt, en nog
jammerder dat daarvoor nuttige dingen verwijderd worden.

Met een externe disk performed het ook met een kleine buffer nog goed
en is dit hele probleem er niet.

Alleen beperkt het comprimeren wel behoorlijk de performance...

[unknown]

Post by Rob
Inmiddels ben ik erachter dat het probleem met de performance wat ik
probeerde op te lossen alleen speelt als het output device mijn locale
disk is.

Joh!

[Rob]

Post by Rob
Inmiddels ben ik erachter dat het probleem met de performance wat ik
probeerde op te lossen alleen speelt als het output device mijn locale
disk is.

Joh!

Het verhaal is wat vreemd geworden doordat ik een paragraaf die ik
eerst had getikt voor het posten verwijderd had omdat deze naar mijn
idee de zaak ingewikkelder maakte dan nodig en wellicht niet relevant
was. Maar dat was toch niet zo.

Wat ik gemerkt heb met het testen van writes van 00 bytes (/dev/zero
copieren) is dat het op de locale disk niet zo snel gaat, en dat dit
probleem verdwijnt als de buffer groter is.

Mijn locale disk is uiteraard een RAID-1 array en daarop schrijft hij
in O_DIRECT mode heel langzaam. Kennelijk worden de writes niet zo
handig gescheduled. Op de externe disk is dat probleem er niet.

Het probleem met de hele operatie is dat de primitive die ik nu gebruik
(O_DIRECT) eigenlijk helemaal niet is wat ik zoek om het doel te
bereiken. Het werkt op zich wel maar er zitten ook aspecten aan die
helemaal niet goed zijn.

Er mag best wat gebufferd worden, een paar meg ofzo, maar wat niet
de bedoeling is dat is dat geschreven blokken in de buffer cache
blijven en dat het alloceren van steeds meer pages voor te schrijven
blokken ten koste gaat van pages van draaiende processen.

Die POSIX_FADV_DONTNEED is meer wat ik moet hebben, maar die is
niet zo simpel in te zetten icm een bestaand programma zoals tar.

Wellicht is het tunen van de vm behaviour (desnoods alleen tijdens
het backuppen) toch een betere optie. Maar eens onderzoeken of je
bijvoorbeeld de relatieve prioriteiten van process pages en disk buffer
pages kunt veranderen. Ik zie wel vm.dirty_ratio maar ik vrees dat
die alleen te maken heeft met hoeveel buffers er dirty kunnen zijn,
niet hoeveel er na het schrijven in memory blijven.

[Pyt T.]

Post by Rob
Inmiddels ben ik erachter dat het probleem met de performance wat ik
probeerde op te lossen alleen speelt als het output device mijn locale
disk is.
Tja dit is natuurlijk het nadeel van het buitenspel zetten van de OS
disk buffering. Die zal normaal gesproken meer data verzamelen om
die in grotere chunks naar de disk te schrijven en dat gaat dan
sneller. Wellicht ook minder seeks.

Volgens mij mis ik nog raw in dit draadje.
Uit "man raw":
".. In particular, access to the raw device bypasses the kernel's block
buffer cache entirely: all I/O is done directly
to and from the address space of the process performing the
I/O .."

Maar dat is waarschijnlijk ook niet zo snel.

[Rob]

Post by Pyt T.

Post by Rob
Inmiddels ben ik erachter dat het probleem met de performance wat ik
probeerde op te lossen alleen speelt als het output device mijn locale
disk is.
Tja dit is natuurlijk het nadeel van het buitenspel zetten van de OS
disk buffering. Die zal normaal gesproken meer data verzamelen om
die in grotere chunks naar de disk te schrijven en dat gaat dan
sneller. Wellicht ook minder seeks.

Volgens mij mis ik nog raw in dit draadje.
".. In particular, access to the raw device bypasses the kernel's block
buffer cache entirely: all I/O is done directly
to and from the address space of the process performing the
I/O .."
Maar dat is waarschijnlijk ook niet zo snel.

Dat is block-level I/O. Ik wil wel graag het filesystem gebruiken...

[Pyt T.]

Post by Rob

Post by Pyt T.

Post by Rob
Inmiddels ben ik erachter dat het probleem met de performance wat ik
probeerde op te lossen alleen speelt als het output device mijn locale
disk is.
Tja dit is natuurlijk het nadeel van het buitenspel zetten van de OS
disk buffering. Die zal normaal gesproken meer data verzamelen om
die in grotere chunks naar de disk te schrijven en dat gaat dan
sneller. Wellicht ook minder seeks.

Volgens mij mis ik nog raw in dit draadje.
".. In particular, access to the raw device bypasses the kernel's block
buffer cache entirely: all I/O is done directly
to and from the address space of the process performing the
I/O .."
Maar dat is waarschijnlijk ook niet zo snel.

Dat is block-level I/O. Ik wil wel graag het filesystem gebruiken...

Staat jou filesystem niet op een block device?
En hoe groot is die backup eigenlijk? En hoeveel intern geheugen heb je?

[Rob]

Post by Pyt T.

Post by Rob

Post by Pyt T.

Post by Rob
Inmiddels ben ik erachter dat het probleem met de performance wat ik
probeerde op te lossen alleen speelt als het output device mijn locale
disk is.
Tja dit is natuurlijk het nadeel van het buitenspel zetten van de OS
disk buffering. Die zal normaal gesproken meer data verzamelen om
die in grotere chunks naar de disk te schrijven en dat gaat dan
sneller. Wellicht ook minder seeks.

Volgens mij mis ik nog raw in dit draadje.
".. In particular, access to the raw device bypasses the kernel's block
buffer cache entirely: all I/O is done directly
to and from the address space of the process performing the
I/O .."
Maar dat is waarschijnlijk ook niet zo snel.

Dat is block-level I/O. Ik wil wel graag het filesystem gebruiken...

Staat jou filesystem niet op een block device?

Jawel maar ik wil geen raw block i/o doen maar gewoon een file openen
en daar in schrijven.

Post by Pyt T.
En hoe groot is die backup eigenlijk? En hoeveel intern geheugen heb je?

De backup varieert in grootte van tientallen GB tot honderden GB
en ik heb 2GB geheugen.
Ik wil dus niet dat hij gaat proberen die outputfile in buffers te
houden want dat gaat toch niet passen en ik wil em toch niet meer
lezen.
Hij mag best een megje of wat bufferen op weg naar de disk maar dat
moet ie dan recyclen binnen die toepassing en dus niet afsnoepen
van de draaiende programma's.

[Pyt T.]

Post by Rob

Post by Pyt T.

Post by Rob

Post by Pyt T.

Post by Rob
Inmiddels ben ik erachter dat het probleem met de performance wat ik
probeerde op te lossen alleen speelt als het output device mijn locale
disk is.
Tja dit is natuurlijk het nadeel van het buitenspel zetten van de OS
disk buffering. Die zal normaal gesproken meer data verzamelen om
die in grotere chunks naar de disk te schrijven en dat gaat dan
sneller. Wellicht ook minder seeks.

Volgens mij mis ik nog raw in dit draadje.
".. In particular, access to the raw device bypasses the kernel's block
buffer cache entirely: all I/O is done directly
to and from the address space of the process performing the
I/O .."
Maar dat is waarschijnlijk ook niet zo snel.

Dat is block-level I/O. Ik wil wel graag het filesystem gebruiken...

Staat jou filesystem niet op een block device?

Jawel maar ik wil geen raw block i/o doen maar gewoon een file openen
en daar in schrijven.

Ik zie nu dat dat raw niet zo modern is.

Post by Rob

Post by Pyt T.
En hoe groot is die backup eigenlijk? En hoeveel intern geheugen heb je?

De backup varieert in grootte van tientallen GB tot honderden GB
en ik heb 2GB geheugen.
Ik wil dus niet dat hij gaat proberen die outputfile in buffers te
houden want dat gaat toch niet passen en ik wil em toch niet meer
lezen.
Hij mag best een megje of wat bufferen op weg naar de disk maar dat
moet ie dan recyclen binnen die toepassing en dus niet afsnoepen
van de draaiende programma's.

Met alleen het schrijven niet bufferen ben je er dan niet tenzij je de
dingen die je in het geheugen wilt hebben als laatste backupt.

[Rob]

Post by Pyt T.

Post by Rob
Hij mag best een megje of wat bufferen op weg naar de disk maar dat
moet ie dan recyclen binnen die toepassing en dus niet afsnoepen
van de draaiende programma's.

Met alleen het schrijven niet bufferen ben je er dan niet tenzij je de
dingen die je in het geheugen wilt hebben als laatste backupt.

Het klopt dat je ook de leesbuffers hebt, en dat die eigenlijk ook
ongewenst zijn bij het backuppen. In feite zou het backupprogramma
na het lezen van een file die call moeten doen die de buffers weer
vrij geeft (zie eerder in de thread).

Maar op de een of andere manier heeft het lezen van heel veel data
minder impact dan het schrijven. Ik denk dat er bij het kiezen van een
strategie voor het alloceren van een buffer een verschil is tussen of
die buffer voor lezen of voor schrijven is. Als een buffer voor lezen
is dan wordt er kennelijk alleen een andere buffer vrijgemaakt die al
daarvoor gebruikt was bij een andere file, en als er een buffer nodig
is voor schrijven dan wordt die desnoods afgepikt van een programma als
het schrijven heel hard gaat. Het probleem is wellicht dat een
leesbuffer altijd kosteloos kan worden vrijgegeven maar dat een dirty
schrijfbuffer eerst naar disk moet worden geschreven, en dus niet zo'n
fijne kandidaat is om vrij te geven als je een buffer nodig hebt.

Ik weet dat het onderscheid tussen leesbuffers en programmacode maar erg
marginaal is omdat de code van een programma in feite alleen een mapping
is van de blokken van het programmabestand naar locaties in memory,
en dat een programma in memory dus in feite hetzelfde is als een file
die je leest en die gedeeltelijk in buffers staat.

[Philip Paeps]

Post by Rob

Post by Philip Paeps

Post by Rob
Dat werkt niet. Ik denk dat de blocking gebeurt met de input van
gzip die het vervolgens wegcomprimeert.

Dat lijkt me een bug. De bestaansreden voor die -b parameter is het
ondersteunen van fixed-blocksize tape devices.

Ja dat klopt, maar ik denk dat tar niet vaak in combinatie met de z optie
gebruikt wordt op tapedrives. Die kunnen dat comprimeren meestal zelf.

Geen idee eigenlijk. Het is inmiddels een hele tijd geleden dat ik nog
ben geconfronteerd met een "domme" tape drive. De laatste paar jaar
zijn die dingen in mijn leefwereld allemaal een stuk autonomer geworden.

Ik herinner me wel dat je ingebouwde compressie van tape streamers niet
altijd even geweldig was en dat software compressive vele malen sneller
en efficiënter was. Compressed blokken naar tape schrijven lijkt me dus
geen uitzonderlijke usecase.

Post by Rob
Echter, als ik dat doe dan raken de outputfiles corrupt. tar xvzf
kan ze niet meer lezen.
Ofwel die conv=sync doet iets anders dan ik denk, ofwel er zit ergens
een nog meer tricky bug.

Het zou ook kunnen dat tar probeert te slim te zijn, en de laatste blok
niet pad tot de blocksize als de output naar een pipe gaat. Tegen dat
soort bugs ben ik in het stenen tijdperk vaak gelopen. De ingebouwde
decompressie van tar lustte de files perfect, maar standalone gzip dan
weer niet.

Post by Rob
Dit ben ik nog aan het onderzoeken, maar ik meld het maar even voor
degenen die enthousiast hun scripts gaan aanpassen: test wel even of
het resultaat wel leesbaar is!

Backups steeds testen. :)

- Philip

[Rob]

Post by Philip Paeps

Post by Rob

Post by Philip Paeps

Post by Rob
Dat werkt niet. Ik denk dat de blocking gebeurt met de input van
gzip die het vervolgens wegcomprimeert.

Dat lijkt me een bug. De bestaansreden voor die -b parameter is het
ondersteunen van fixed-blocksize tape devices.

Ja dat klopt, maar ik denk dat tar niet vaak in combinatie met de z optie
gebruikt wordt op tapedrives. Die kunnen dat comprimeren meestal zelf.

Geen idee eigenlijk. Het is inmiddels een hele tijd geleden dat ik nog
ben geconfronteerd met een "domme" tape drive. De laatste paar jaar
zijn die dingen in mijn leefwereld allemaal een stuk autonomer geworden.
Ik herinner me wel dat je ingebouwde compressie van tape streamers niet
altijd even geweldig was en dat software compressive vele malen sneller
en efficiënter was. Compressed blokken naar tape schrijven lijkt me dus
geen uitzonderlijke usecase.

Tja dan moet je er "buffer" tussen hangen. Dat deed ik ook altijd toen
ik nog een tape had. In de systemen van toen had ik van die QIC tapes
en hoewel die nu zielig traag en klein zijn, was het toen al een hele
toer om ze streamend te houden. Met buffer lukte het wel redelijk, tot
je in een source directory ofzo terecht kwam met honderden kleine filetjes.

Vandaag de dag is het probleem mogelijk nog moeilijker geworden.
Op het werk hebben we LTO-4 tape, en er bestaat ook LTO-5, en die
dingen hebben >100MB per seconde doorvoersnelheid, als de compressie
uit staat. Met de compressie aan is dat variabel tot het dubbele.

Zelfs al heb je snelle disken dan nog is het bijna niet te doen om
een continue datastroom van die snelheid te produceren met een backup
op file basis.

Post by Philip Paeps

Post by Rob
Echter, als ik dat doe dan raken de outputfiles corrupt. tar xvzf
kan ze niet meer lezen.
Ofwel die conv=sync doet iets anders dan ik denk, ofwel er zit ergens
een nog meer tricky bug.

Het zou ook kunnen dat tar probeert te slim te zijn, en de laatste blok
niet pad tot de blocksize als de output naar een pipe gaat.

Het probleem blijkt te zijn dat dd geen brokken aangereikt krijgt van
de size die ik opgeef. Het is op te lossen door de parameters
ibs=4k obs=400k conv=sync oflag=direct te gebruiken.
(en tar gewoon zonder blocksize en met z flag)

Dan krijg ik in ieder geval een correcte .tar.gz file.
De .lst.gz file is incompleet. Ik denk dat de shell bij het gebruik
van die >(proces) constructie de EOF niet netjes afhandelt ofzo.
Dit is minder belangrijk, die listing is meer voor de heb, hij is
toch al niet erg nuttig omdat de sizes en timestamps er niet bij staan.

[Martijn van Buul]

Post by Philip Paeps

Post by Rob
Bestaat er ook een methode in Linux om een file te schrijven waarbij
deze niet tevens ook in de buffercache terecht komt?

Lange thread met veel onzin,

En dat helemaal zonder mijn inbreng!

Martijn - Was op vakantie en had verdacht weinig zin om 15 euro/dag te
gaan lappen voor wifi

[unknown]

Post by Martijn van Buul

Post by Philip Paeps

Post by Rob
Bestaat er ook een methode in Linux om een file te schrijven waarbij
deze niet tevens ook in de buffercache terecht komt?

Lange thread met veel onzin,

En dat helemaal zonder mijn inbreng!

We hebben je gemist! :)

[Fred Mobach]

Post by Martijn van Buul

Post by Philip Paeps

Post by Rob
Bestaat er ook een methode in Linux om een file te schrijven waarbij
deze niet tevens ook in de buffercache terecht komt?

Lange thread met veel onzin,

En dat helemaal zonder mijn inbreng!
Martijn - Was op vakantie en had verdacht weinig zin om 15 euro/dag te
gaan lappen voor wifi

Die kon je beter besteden aan je vakantie.

[Philip Paeps]

Post by Martijn van Buul

Post by Philip Paeps

Post by Rob
Bestaat er ook een methode in Linux om een file te schrijven waarbij
deze niet tevens ook in de buffercache terecht komt?

Lange thread met veel onzin,

En dat helemaal zonder mijn inbreng!
Martijn - Was op vakantie en had verdacht weinig zin om 15 euro/dag te
gaan lappen voor wifi

Welkom thuis. :)

- Philip