bug su filesystem?

[masalapianta]

AHAHAHAHAHAHAHAHAHAHA

Scusa ma non ho capito .

mi han fatto sbellicare le battute (anche se la sezione giusta sarebbe stata "Libera") sul "timing", la cache dei dischi, il sync e presunte inconsistenze rilevate da applicazioni in user land che accedono ai file system

[ZeroUno]

io so solo una cosa. do alcune find in una directory mentre il filesystem è in uso e viene questo è l'output.

Codice: Seleziona tutto

find: WARNING: Hard link count is wrong for `./chrome/app' (saw only st_nlink=3 but we already saw 1 subdirectories): this may be a bug in your file system driver. Automatically turning on find's -noleaf option. Earlier results may have failed to include directories that should have been searched.

Le stesse su tmpfs non danno errori.
non ho provato altri filesystem


mi viene in mente adesso che il contenuto di questa directory varia in modo relativamente veloce; probabilmente da il problema quando la directory cambia durante il ciclo di vita della find (che viene eseguita ogni 10sec)

[conraid]

Sembra simile al "famoso" problema su /proc, che anche il codice di find "spiega":

Codice: Seleziona tutto

if (mode && S_ISDIR(mode) && (subdirs_left == 0))
                {
                  /* This is a subdirectory, but the number of directories we 
                   * have found now exceeds the number we would expect given 
                   * the hard link count on the parent.   This is likely to be 
                   * a bug in the file system driver (e.g. Linux's 
                   * /proc file system) or may just be a fact that the OS 
                   * doesn't really handle hard links with Unix semantics.
                   * In the latter case, -noleaf should be used routinely.
                   */
                  error(0, 0, _("WARNING: Hard link count is wrong for %s (saw only st_nlink=%d but we already saw %d subdirectories): this may be a bug in your file system driver.  Automatically turning on find's -noleaf option.  Earlier results may have failed to include directories that should have been searched."),

così come in /proc anche il tuo caso mi sembra che contempli la possibilità che le directory cambino "sotto il naso" di find

[masalapianta]

io so solo una cosa. do alcune find in una directory mentre il filesystem è in uso e viene questo è l'output.

Codice: Seleziona tutto

find: WARNING: Hard link count is wrong for `./chrome/app' (saw only st_nlink=3 but we already saw 1 subdirectories): this may be a bug in your file system driver. Automatically turning on find's -noleaf option. Earlier results may have failed to include directories that should have been searched.

Le stesse su tmpfs non danno errori.
non ho provato altri filesystem

quindi? la stat() sulla parent directory e le successiva ricerca di sottodirectory non sono un'operazione atomica, se tra la stat() e quel che segue, un altro processo modifica opportunamente il fs, ecco che il numero di hard links non torna più; non è un bug ne una cosa strana (e men che meno c'entrano i sync, la cache dei dischi o le altre assurdità che ho letto nel post di Vanoni )

mi viene in mente adesso che il contenuto di questa directory varia in modo relativamente veloce; probabilmente da il problema quando la directory cambia durante il ciclo di vita della find (che viene eseguita ogni 10sec)

gia

[ZeroUno]

mi viene in mente adesso che il contenuto di questa directory varia in modo relativamente veloce; probabilmente da il problema quando la directory cambia durante il ciclo di vita della find (che viene eseguita ogni 10sec)

gia

solo che ci ho pensato solo oggi.

[Mario Vanoni]

io so solo una cosa. do alcune find in una directory mentre il filesystem è in uso e viene questo è l'output.

Codice: Seleziona tutto

find: WARNING: Hard link count is wrong for `./chrome/app' (saw only st_nlink=3 but we already saw 1 subdirectories): this may be a bug in your file system driver. Automatically turning on find's -noleaf option. Earlier results may have failed to include directories that should have been searched.

Le stesse su tmpfs non danno errori.
non ho provato altri filesystem

quindi? la stat() sulla parent directory e le successiva ricerca di sottodirectory non sono un'operazione atomica, se tra la stat() e quel che segue, un altro processo modifica opportunamente il fs, ecco che il numero di hard links non torna più; non è un bug ne una cosa strana (e men che meno c'entrano i sync, la cache dei dischi o le altre assurdità che ho letto nel post di Vanoni )

mi viene in mente adesso che il contenuto di questa directory varia in modo relativamente veloce; probabilmente da il problema quando la directory cambia durante il ciclo di vita della find (che viene eseguita ogni 10sec)

gia

Umile domanda,
il perche' di questo effetto che noto da un anno:

- Intel Core 2 Dual 1866MHz con 4096kB di cache
- RAM di 4GB
- HD Hitachi/IBM 1TB con 64MB di memoria on-board
- senza alcun X11 che viaggi, solo tty
- kernel -stable, -ck o -rt, tutti uguali

Per divertire la nipotina attaverso l'impianto Hi-Fi parte
- aplay *.wav
- sporadicamente segnala underrun!!! al least 23072.276 ms long, sempre cifre simili
Ascoltado la musica si nota/si sente la anche minima interruzione!

A quale componente HW o SW si puo` attribuire la colpa?

[masalapianta]

Umile domanda,
il perche' di questo effetto che noto da un anno:

- Intel Core 2 Dual 1866MHz con 4096kB di cache
- RAM di 4GB
- HD Hitachi/IBM 1TB con 64MB di memoria on-board
- senza alcun X11 che viaggi, solo tty
- kernel -stable, -ck o -rt, tutti uguali

Per divertire la nipotina attaverso l'impianto Hi-Fi parte
- aplay *.wav
- sporadicamente segnala underrun!!! al least 23072.276 ms long, sempre cifre simili
Ascoltado la musica si nota/si sente la anche minima interruzione!

A quale componente HW o SW si puo` attribuire la colpa?

siamo ot, btw quel messaggio significa che il buffer si è svuotato e non ci sono più dati da leggere; senza ulteriori informazioni è impossibile identificare la causa, potrebbe essere un bug del player o delle libalsa, il/i processore/i che sta/stanno facendo diverse cose e il player non ha una priorità sufficientemente alta rispetto agli altri processi, troppo i/o concorrente sul fs su cui sta il file audio da leggere (questa imho è la più probabile), ecc...

[ZeroUno]

in caso di multimedialità può essere comodo ricompilare il kernel mettendo uno scheduler Low-Latency o ancora meglio la patch kernel realtime, anche se, effettivamente, mi pare un po' esagerato per un semplice aplay

[Mario Vanoni]

siamo ot, btw quel messaggio significa che il buffer si è svuotato e non ci sono più dati da leggere; senza ulteriori informazioni è impossibile identificare la causa, potrebbe essere un bug del player o delle libalsa, il/i processore/i che sta/stanno facendo diverse cose e il player non ha una priorità sufficientemente alta rispetto agli altri processi, troppo i/o concorrente sul fs su cui sta il file audio da leggere (questa imho è la più probabile), ecc...

Non e` [OT], tu pensi che e` un problema di FS, uso ext2.
Il disco 2 contiene unicamente i files *.wav, nessun altro accesso.
Il sistema sta sul disco 1, identico modello, con / ecc. ecc.
Quindi e` la logica on-board del HD che si strozza con ext2,
essendo aplay l'unico processo attivo, a parte i vari demoni ...

Domanda: come/dove trovare ulteriori informazioni?

[masalapianta]

Non e` [OT]

si, lo è

, tu pensi che e` un problema di FS

eh? non ho mai detto che fosse un problema di fs ma che, tra le altre mille cose, potesse dipendere da un elevato I/O concorrente sul fs su cui sta il file audio da leggere

, uso ext2.

irrilevante

Il disco 2 contiene unicamente i files *.wav, nessun altro accesso.

solo aplay legge da quel disco? nessun updatedb o altro?

Quindi e` la logica on-board del HD che si strozza con ext2,
essendo aplay l'unico processo attivo, a parte i vari demoni ...

eh??? che c'entra la cache dei dischi con il tuo problema? non potrebbe dipendere dalla marmotta cioccolataia?

Domanda: come/dove trovare ulteriori informazioni?

facendo debug sul codice del player e vedendo su quali funzioni sta troppo tempo (ammesso che il problema stia li e non sia un bug nelle libalsa)

[Mario Vanoni]

solo aplay legge da quel disco? nessun updatedb o altro?

Esatto, _niente_ altro,
provo sulla macchina 2 un strace aplay ...

[Mario Vanoni]

solo aplay legge da quel disco? nessun updatedb o altro?

Esatto, _niente_ altro,
provo sulla macchina 2 un strace aplay ...

Kernel 2.6.34-ck1 compilato statico, senza moduli!
Macchina 1, ho sgarrato ad impostarla, e senza strace, ma meglio.
Durata non-stop 28 ore, con un X11 sempre attivo,
aplay *.wav >> /root/.error-aplay 2>&1
nessun messaggio di "underrun!!! ..."
quindi pregio a Con Kolivas con la sua versione del kernel.

[414N]

- sporadicamente segnala underrun!!! al least 23072.276 ms long, sempre cifre simili
Ascoltado la musica si nota/si sente la anche minima interruzione!

A quale componente HW o SW si puo` attribuire la colpa?

Se non ricordo male, in altri post avevi detto di aver impostato il kernel con timer a 100Hz. Non credi possa essere proprio questo il problema?

[Ansa89]

Ieri è capitato anche a me che alsa mi segnalasse un buffer-underrun sulla musichetta di fondo di frozen-bubble.
Uso un kernel 2.6.34 con patch ck1 e timer impostato a 1000Hz.

EDIT: ecco l'output dell'errore: "ALSA lib pcm.c:7245:(snd_pcm_recover) underrun occured".

[Mario Vanoni]

Dal kernel 2.6.34-ck1 1000Hz, con HD SATA 1TB e 64MB mem, mai piu` successo.

Citando Masalapianta
"e men che meno c'entrano i sync, la cache dei dischi o le altre assurdità che ho letto nel post di Vanoni",
mi puzza tanto invece di errore della logica interna/memoria del disco.

Sulla terza macchina con HD vecchio IDE di 160GB lo fa` tuttora una tantum,
pure con kernel 2.6.34-ck1 a 1000Hz e sempre Slackware 12.2.

Quindi un kernel attuale ha difficolta` con HW piu` anziana, ma gestisce bene/benino HW recente.

Vale la discussione su LKML come mantenere il codice, pieno di errori, dei floppy disk.
http://lkml.indiana.edu/hypermail/linux ... 01580.html
Lo stesso Linus Torvalds risponde

> The driver is a complex mess of spaghetti state. Does one of the original
> authors have more background to fix this?
Doubtful. There are no "original authors" left really. Yes, I technically
wrote the original driver, but it has gotten seriously rewritten a couple
of times - sadly always just expanding on the cruftyness.