bug su filesystem?

[ZeroUno]

questo mi è nuovo:

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.

Sarà veramente un bug?

[Ansa89]

Che filesystem usi?

[ZeroUno]

ext3

ho lanciato il processo in tmpfs ed è andato tutto bene.

però è la prima volta che vedo questo messaggio.

[Mario Vanoni]

ext3

ho lanciato il processo in tmpfs ed è andato tutto bene.

però è la prima volta che vedo questo messaggio.

Leggendo regolarmente LKML,
i file system journaled hanno problemi, soprattutto ext3, ext4 ed XFS.
Il problema e` il timing, CPU/memoria veloci, HD molto lenti,
se il journal in memoria e` piu` recente di quello che il disco ha registrato effettivamente,
qui fregano le memorie su HD, per fare meno spostamenti della testina ...
Con 64MB o 128MB on cache, finche' non sposta, il find(1) da errore.
Ed il find(1) sulla memoria cache ha la precedenza sull'aggiornamento HD!

Quindi vecchia regola dai tempi di AT&T UNIX SVR2:
prima di fare un lavoro che coinvolge il FS,
sync ; sync ; sync
tre volte perche' cosi` ha il tempo di farlo veramente!
Leggere man sync(1), che lo spiega.
La uso da decenni in ogni sh script, e funziona perfettamente.

Ci sono diverse patch per i vari FS, che probabilemente troveremo nel kernel 2.6.35.

[ZeroUno]

Veramente brutta come cosa..

Quello che dici è compatibile con il mio caso, credo.

Lancio una compilazione con make -j3 che dura 3/4 d'ora circa.
La lancio in background e da una find ogni 10 secondi per creare delle statistiche sullo stato di avanzamento.

Il sync purtroppo credo che non mi gioirebbe molto alla compilazione.
Mi tengo il warning.

[Mario Vanoni]

Veramente brutta come cosa..

Quello che dici è compatibile con il mio caso, credo.

Lancio una compilazione con make -j3 che dura 3/4 d'ora circa.
La lancio in background e da una find ogni 10 secondi per creare delle statistiche sullo stato di avanzamento.

Il sync purtroppo credo che non mi gioirebbe molto alla compilazione.
Mi tengo il warning.

Non so che CPU hai, io ho Intel Core 2 Dual 1866MHz, non uguali.
Con il kernel di Con Kolivas, compilando il kernel unicamente statico,
time make -j 2 bzImage impiega 5...6 minuti, e vedo sul tty come prosegue.
Ovviamente in quei tempi non eseguo lavori p.e. di backup ecc. accanto.
Ma se li fa` crontab(1), tutti gli script hanno un triplice ssync(1),
rallentano per i CPU usati, ma _mai_ hanno dato errore!

[ZeroUno]

Intel(R) Core(TM)2 Duo CPU T5550 @ 1.83GHz

compilazione del browser chromium (il binario sono 50MB c.a.). Senza -jX 90 minuti.

Il kernel non l'ho mai compilato statico, quindi non saprei il tempo che impiegherebbe.

[Mario Vanoni]

Intel(R) Core(TM)2 Duo CPU T5550 @ 1.83GHz

compilazione del browser chromium (il binario sono 50MB c.a.). Senza -jX 90 minuti.

Il kernel non l'ho mai compilato statico, quindi non saprei il tempo che impiegherebbe.

I miei CPU sono 6320 e 6300, passami l'indirizzo di quel browser,
non mi interessa, ma lo complilo per confrontare i tempi.

[ZeroUno]

ti allego lo slackbuild e i file correlati.

nello slackbuild in riga 114 c'è la find che va in errore.
precisamente l'errore me l'ha dato compilando in una slackware64 13.1 chrootata su filesystem ext3. Su tmpfs l'errore non lo da.
Stesso slackbuild, stessa macchina, stessa partizione, con una slackware 13.1 non chrootata l'errore non lo da.

in tutti e tre i casi compilata con -j3

Codice: Seleziona tutto

# MAKEFLAGS="-j3" bash chromium.SlackBuild

hai bisogno di 1.4GB di spazio sulla /tmp

[Mario Vanoni]

Matteo, io uso un 12.2 32-bit!
Da utente root
tar xzf chromium-5.0.375.71-x86_64-1sl-src.tar.gz
cd src
time sh chromium.SlackBuild
7m32 per scaricare, ma poi gli manca gconf-2.0 e termina.
Quindi test inutile, sorry.

[ZeroUno]

serve gconf e orbit2

[Mario Vanoni]

ext3

ho lanciato il processo in tmpfs ed è andato tutto bene.

però è la prima volta che vedo questo messaggio.

Leggi questo post di ieri nella LKML
http://lkml.indiana.edu/hypermail/linux ... 02440.html
ext3 sembra un po` instabile.

[masalapianta]

ext3

ho lanciato il processo in tmpfs ed è andato tutto bene.

però è la prima volta che vedo questo messaggio.

Leggendo regolarmente LKML,
i file system journaled hanno problemi, soprattutto ext3, ext4 ed XFS.
Il problema e` il timing, CPU/memoria veloci, HD molto lenti,
se il journal in memoria e` piu` recente di quello che il disco ha registrato effettivamente,
qui fregano le memorie su HD, per fare meno spostamenti della testina ...
Con 64MB o 128MB on cache, finche' non sposta, il find(1) da errore.
Ed il find(1) sulla memoria cache ha la precedenza sull'aggiornamento HD!

Quindi vecchia regola dai tempi di AT&T UNIX SVR2:
prima di fare un lavoro che coinvolge il FS,
sync ; sync ; sync
tre volte perche' cosi` ha il tempo di farlo veramente!
Leggere man sync(1), che lo spiega.
La uso da decenni in ogni sh script, e funziona perfettamente.

AHAHAHAHAHAHAHAHAHAHA

[Ansa89]

AHAHAHAHAHAHAHAHAHAHA

Scusa ma non ho capito .

[ZeroUno]

nemmeno io