Newsgroup: it.comp.os.linux.sys
Titolo: [lungo] 2.X.X vfat mi buca i file?

Torno all'attacco con una grana partcolamente dura da digerire.
Anche se credo che qualche fortunello si sia gia' scontrato in passato
con il problema, espongo ugualmente l'intero romanzo.
Ho una workstation con 2 dischi IDE (hda, hdc) con le partizioni linux su hda.
Ogni volta che accedo in scrittura alla sola partizione FAT16 presente in hdc
per traferire file piu' grandi di 20-30k non ottengo apparentemente 
nessun tipo di problema. Dopo aver smontato smontato la partizione mi accorgo
pero' che quasi tutti file scritti da linux hanno subito alterazioni
( crc error a iosa, mp3 con armoniche sballate, ecc... ).
Ora, questo inconveniente non e' riscontrabile da linux se non dopo aver
montato nuovamente la partizione ed aver comparato i file "sani" con quelli 
"bacati" scritti sulla partizione FAT16.
Cio' mi fa pensare che in qualche modo la cache possa temporaneamente 
mascherare gli errori fatti durante l'accesso in scrittura.
( quindi il problema risiede nel layer VFS o nei layer attigui )
Indagando con maggiore perizia ho scoperto che con uno schema apparentemente
casuale, linux omette di scrivere alcuni byte durante la scrittura dei file su 
vfat; stranamente pero' la lunghezza logica del file ottenuto non ne viene 
alterata.
Questo mi ha fatto pensare ad un difetto della motherboard o dei controller ide
ma ho inseguito constatato che altri SO leggono e scrivono correttamente sullo 
stesso device senza il minimo problema.
Ho provato ad accedere in loop a una partizione fittizia vfat creata 
temporaneamente sul canale ide hda, ma il problema non si e' verificato.
Analogamente, creando una partizione ext2 sul canale ide incriminato hdc
non ho ottenuto nessun tipo di inconveniente.
Tutto porta a pensare che il difetto risieda nel supporto del filesystem *fat,
originariamente per il 2.2.15.
Ho effettuato prove con il 2.2.5, 2.2.16, 2.3.45, 2.0.38 ottenendo sempre lo 
stesso risultato e i file bacati al successivo mount.
L'unica cosa che ancora mi rimane da fare e' cambiare la configurazione dei
canali ide. Per il momento ho scoperto solo che anche rimuovendo hdb e hdd
il problema permane.
Qualcuno ne sa qualcosa??
Macchina Piii 196MB, 13 + 8 Gb,
Mandrake 7 e RH 6.2
kernel 2.2.16 (2.2.5, 2.2.14-mdk, 2.2.15, 2.3.45)
/dev/hda = 13GB UDma 7200rpm
/dev/hdb = Asus 40X
/dev/hdc = 8GB UDma
/dev/hdd = Waitek WT2422EI
/dev/sysadmin = individuo stressato
# cat /proc/aspirina
  Stack overflow
#
Saluti.

 
...snippone...
Non so se sia questo il "problema" ma il supporto vfat non è eccezionale. Lo
vedi anche nelle prestazioni...
Ciao.
-- 
***  Per E-mail rimuovi ModE dall'indirizzo  ***
              *** ICQ 33500725 ***
*** homepage 
http://web.tiscalinet.it/kailed
 ***
            *** Powered by Linux ***

>>>>> "u" == unix2k  <uni...@servillo.masters.ks> writes:
u> 
u> Tutto porta a pensare che il difetto risieda nel supporto del filesystem *fat,
u> originariamente per il 2.2.15.
u> Ho effettuato prove con il 2.2.5, 2.2.16, 2.3.45, 2.0.38 ottenendo sempre lo 
u> stesso risultato e i file bacati al successivo mount.
ho sempre fatto spostamenti di  file (anche da 20-30MB) tra partizioni
fat16/32 di un disco e  partizioni ext2 di  un altro disco, ma non  ho
mai  riscontrato  il benchč minimo problema,   con diverse versioni di
kernel, dal 2.0 al 2.2.
Ciao
Marco
-- 
Il software e' deterministico.
Il problema e' che e' l'hardware a non esserlo.
		-- Signature di Matteo Ianeselli

 Lo vedi anche nelle prestazioni...
Beh, questo è evidente. Ma tra svirgolare una FAT perchè il supporto 
non è grandioso e lasciare direttamente dei buchi in un file c'e' IMO 
una gran bella differenza!
Salutoni.

Qualcuno ne sa qualcosa??
non so come esserti di aiuto, ho 4 hd e ho trasferito anche file > 1gb
da e verso ext2 e fat32 a partire da kernel 2.0.36 fino al 2.2.16
senza mai problemi, non e' che hai qualche impostazione strana di
hdparm o nel bios per la gestione dei dischi ?
bye
-- 
     #@@@ missinglink on slackware 7.1 ###
     ####       member of telug        #@@