R: [Tech] Copia file

[scm@scmlink.it]

Rimango attonito davanti a tanta sapienza.
Il controller del Promise non c'entra perché il problema si manifestava
anche prima con il RAID1 software. Ho provato ad invertire i 2 banchi di
memoria da 256 ed anche a montarli singolarmente.
Il bello è che anche in fase d'installazione si presenta il problema. Riesco
ad installare fino alla 7.3 a scheda madre resettata previo interruzione
dell'alimentazione altrimenti, se tento di ripetere l'installazione o
d'installare la 8.0, al momento di formattare il o i dischi, appare un
messaggio di errore che dice che non può rileggere la directory /tmp/hda e/o
hdc quindi s'interrompe e fine. La 8.0 dà anche un errore di python sempre
prima della formattazione.
Il bello è che, ahimè, windows 2000 server s'installa e funziona alla
perfezione, anche attivando il RAID1 software.
Nel frattempo continuo i test sperando di riuscire a capire che sta
succedendo.
Grazie,

                                ricc

-----Messaggio originale-----
Da: tech-admin@firenze.linux.it [mailto:tech-admin@firenze.linux.it] Per
conto di Marco Ermini
Inviato: martedì 15 aprile 2003 15.16
A: tech@firenze.linux.it
Oggetto: Re: [Tech] Copia file

Simone Piccardi <piccardi@softwarelibero.org> wrote:
> On Tue, 2003-04-15 at 11:12, Marco Ermini wrote:
> > Vanni Guarnieri <guarnier@arcetri.astro.it> wrote:
> > > il kernel normalmente non gestisce files di dimensione > 2Gb;
> > 
> > Non per essere pedanti, ma al kernel non gliene puo' fregare di meno,
> > il problema e' di filesystem e di glibc.
> Tanto per continuare a essere pedanti, ma fino a prova contraria i
> filesystem stanno nel kernel.

Reiserfs e' la prova contraria... :-)

...come in realta', a dire il vero, sono prova contrario un po' tutti i fs,
visto che esiste ext2 per FreeBSD, e viceversa esiste UFS per Linux... le
specifiche tecniche di un filesystem sono indipendenti dal kernel a cui sono
collegate - al di la' del fatto che il codice venga, tecnicamente, compilato
insieme: i limiti tecnici dei filesystem sono indipendenti dal kernel su cui
sono implementati. Mi spiego: la tecnologia di accesso alla geometria del
disco e _memcopy sono specifiche di ciascun kernel, il fatto che ext2 non
gestisca file di 64 GB (tanto per fare un esempio, non so nemmeno se e'
corretto...) e' una specifica del filesystem, ma nulla vieta che nello
stesso
kernel si possa implementare reiserfs, che invece indirizza tranquillamente
2
terabyte: al kernel di Linux strictu sensu interessa poco come sono
configurati gli i-node e le altre strutture di allocazione del fs (certo,
tecnicamente reiserfs.o e' un modulo compilato assieme al resto del
kernel...
pero' dipende dal livello a cui vedi le cose, se e' "implementativo" o
"funzionale").

Poi, e' vero che "storicamente" Linux e' sempre stato molto "legato" ai
filesystem "extN", tanto che per implementare reiserfs sono state cambiate
diverse cose in Linux per rendere possibile il processo. Questi sono
problemi
"infantili" di Linux, tutto sommato si puo' dire che i fs sono ormai (e non
solo in Linux) "moduli plug-in" funzionalmente indipendenti dal kernel.

Tornando alle cose che ci interessano, e' improbabile che il suo problema
sia
legato alla grandezza dei files, perche' comunque Linux non dovrebbe andare
in
freeze (al massimo, in core dump, ma secondo me neanche quello). E' molto
piu'
probabile che nel creare un grosso files si manifesti un qualche altro
problema che altrimenti non si manifesta, come per esempio un banco di
memoria
bacato che non e' mai stato utilizzato prima di quella copia; oppure, un bug
nel driver del controller Promise, o qualche conflitto hardware (interrupt,
piuttosto che DMA) sempre causato dal controller (o dal suo driver). In ogni
caso, se aggiorna ad una versione recente di glibc dovrebbe togliersi ogni
dubbio circa eventuali problemi software nella copia di files grossi.

Per rispondere ad un altro dubbio che aveva: e' normale che Linux mostri un
utilizzo quasi al 100% della RAM: la RAM non usata e' una risorsa sprecata,
e
quindi Linux la "mappa" comunque tutta o quasi tutta anche se non la sta
ancora realmente utilizzando; e' per questo free ritorna un "consumo alto"
di
memoria anche se in realta' non appare giustificato dall'utilizzo che si sta
facendo del PC.


ciao


-- 
Marco Ermini
http://macchimacchi.net - ICQ 50825709 - GPG KEY 0x64ABF7C6 - L.U. #180221
Di fronte alle sofferenze del mondo tu puoi tirarti indietro, sì, questo è
qualcosa che sei libero di fare e che si accorda con la tua natura, ma
precisamente questo tirarsi indietro è l'unica sofferenza che forse potresti
evitare. (F. Kafka)

_______________________________________________
FLUG - Discussioni tecniche - tech@firenze.linux.it
URL: http://lists.firenze.linux.it/mailman/listinfo/tech
Archivio: http://lists.firenze.linux.it/pipermail/tech
Ricerca nell'archivio: http://www.firenze.linux.it/search