Newsgroup: it.comp.os.linux.sys
Titolo: Curiosita' su file system linux.

Una piccola curiosita': i file system di linux sono tutti file system 
indicizzati? E se si', quelli piu' recenti, che sopportano meglio il crash 
di sistema, in cosa differiscono? Solo nel fatto che scrivono subito su 
disco e non prima nel buffer?
Fatemi un po' di chiarezza..
Grazie e ciao.
-- 
Colonnello Kurtz, Cambogia.
Linux powered, user # 227143

 disco e non prima nel buffer?
immagino ti riferisca ai fs jurnaled (raiser, ext3, xfs, jfs, etc); in tal
caso la differenza e` che esiste un "registro" (journal) nel quale viene
tenuto traccia di COSA il sistema sta per fare al fs; in caso di crash il
check del filesystem diventa molto piu` veloce in quanto non serve
scansionare tutto il fs, ma solo le parti interessate alle modifiche in
corso al momento del crash
attenzione pero` che cio` non si traduce in un "sopportare meglio il
crash" (anzi, in alcuni casi aumenta anche la fragilita`), semplicemente
e` piu` VELOCE il normale check del filesystem che viene fatto
automaticamente al boot!!
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 
ero invece convinto che la differenza fosse nel fatto che i fs jurnaled 
scrivessero subito sul disco invece di utilizzare un buffer e poi scrivere 
ogni tot di tempo.


disco e non prima nel buffer?
Quello č il modo migliore per soffrire di piů con i crash di sistema.

corso al momento del crash
Amen. L'idea che il file system sia sempre in uno stato consistente
vogliamo farla passare oppure non ne sappiamo proprio niente?

Nel fausto dě di Sat, 02 Feb 2002 13:07:55 GMT, il prode _colonnello Kurtz_
presente alla corte di _it.comp.os.linux.sys_
cosě ebbe l'ardire di pronunziarsi:
[...]
 
|ero invece convinto che la differenza fosse nel fatto che i fs jurnaled 
|scrivessero subito sul disco invece di utilizzare un buffer e poi scrivere 
|ogni tot di tempo.
|
|Grazie e ciao.
| 
  Quello di cui scrivi č la sincronia dei file.  Linux di default usa il file
system in modo asincrono, perň gli si puň dire di usarlo in modo sincrono,
montandolo con l'opzione sync.
  Sandro
-- 
"In a world without walls and fences
you would not need windows and gates."
(Confucius)

  montandolo con l'opzione sync.
interessante, quindi, domandina :)
facendo una cosa del genere, ci possono essere dei problemi? aumento o
diminuzione delle prestazioni?
qualche link? va bene anche 
www.google.com
 o 
groups.google.com
 :)
-- 
 ___     | (o_
 |_|     | //\
 | |ndry | V_/_ Linux Newbie (quasi User :-) ), Slackware 8.0
         |        Linux User #221457


Direi che con la scrittura sincrona le prestazioni certo non migliorano, in
questo modo impedisci al sistema di ottimizzare la sequenza di
letture/scritture su disco.
--
Alessandro Staltari
staltari(a)
geocities.com

  letture/scritture su disco.
quindi, rimango come sto adesso, con la sincronizzazione gestita dal
kernel, grazie. :)


qualche link? va bene anche 
www.google.com
 o 
groups.google.com
 :)
Bhe' , visto che l'unico scopo della asincronia nella scrittura dei file 
e' l'aumento delle prestazioni , dovrebbero diminuire (e di molto) .
Ciao

  Ciao
ciao.


Zefram Cochrane wrote:

No no, hai proprio ragione, un fs journaled non garantisce l'integrità 
dei dati, ma quella del fs che *dovrebbe* rimanere integro 
(consistente) e quindi avviabile/utilizzabile.
Ciao.
-- 
***  Per E-mail rimuovi ModE dall'indirizzo  ***
  *** Linux user # 198661 --- ICQ 33500725 ***
*** homepage 
http://web.tiscalinet.it/kailed
 ***
            *** Powered by Linux ***

No no, hai proprio ragione,
Sě lo so. Mi domandavo se chi ha risposto a questo thread (chiunque sia,
non mi va di premere Esc-P per scoprirlo) sapesse cosa č un file system
journaled.
-- 
"Give me something to sing about.
I need something to sing about."
(Buffy, "Once More, With Feeling" BTVS 6.07)

 vogliamo farla passare oppure non ne sappiamo proprio niente?
buona la seconda: non ne sappiamo proprio niente


buona la seconda: non ne sappiamo proprio niente
Allora ti suggerisco di documentarti (anche con qualche buon libro sulle
basi di dati, incredibile ma vero) e, fino a quel giorno, di evitare di
partecipare a thread aldila' delle tue possibilità.


  qualche link? va bene anche 
www.google.com
 o 
groups.google.com
 :)
Immagino di si
Ciao, Andrea
-- 
          (o_  | 
(o_  (o_  //\  | Andrea Carosi, just another Linux user
(/)_ (/)_ V_/_ |
GnuPG PK fingerprint: 0857 1927 150B 3C8E 8274  F641 1388 AA6D 3FA0 5410


Cattivo :-P
-- 
Emanuele "SKULL" Balla
--------------------------------------------------------------------
"How should I know if it works?  That's what beta testers are for.  I only
coded it."
(Attributed to Linus Torvalds, somewhere in a posting)

  Immagino di si
google, il guru dei guri ;)


 partecipare a thread aldila' delle tue possibilità.
facciamo anche che, al di la di tutte le belle teorie, io considero che
*nella pratica* quello che ho scritto e` cio` che *io* (molto IMHO)
considero importante/interessante in tali filesystem?
facciamo che dire che "un filesystem e` in uno stato sempre consistente"
senza spiegarlo puo` portare a false interpretazioni da parte dei poveri
ignoranti (come me, ovviamente)
facciamo che questo e` un newsgroup libero dove tutti possono portare
liberamente il proprio contributo?
facciamo che sono finito molto offtopic e che quindi questo e` il mio
ultimo messaggio in questo thread (del quale, peraltro, non sono degno)
facciamo che questo articolo e` molto ;-)


 La velocita' dovrebbe diminuire a vantaggio della consistenza del fs
Non necessariamente, anzi per niente; ti serve comunque un sistema per 
rendere atomica la scrittura dei metadata.

 rendere atomica la scrittura dei metadata.
Mmm... interessante come idea... sai a quanto e` arrivato il costo del
plutonio? ;)
Un Henryx volutamente cazzaggiante
-- 
Alcuni guru di Open World si sono convertiti e hanno fatto i soldi, come
Linus Torvall, l'ideatore del sistema operativo Lynux (distribuito a
prezzi stracciati per fare concorrenza a Windows Xp);
		-- Luca Panerai su "Next" (inserto di Panorama)

  rendere atomica la scrittura dei metadata.
Uhm, potresti spiegarti meglio?


 Uhm, potresti spiegarti meglio?
Ci provo io, terra terra.
Rendere atomica la scrittura significa renderla un evento non
interrompibile, a tempo di esecuzione virtualmente nullo, cosi' da poter
restare solo in una di queste due situazioni: 
La scrittura e' stata eseguita *interamente*.
La scrittura e' stata interrotta, pertanto *non eseguita*.
Come vedi, in ognuno dei due casi, la consistenza e' assicurata.
Non e' assicurato, invece, l'allineamento all'ultima scrittura, cioe'
puoi perdere dati, ma non la coerenza del file system.
Cio' che succede, invece, in un file system normale, sincrono o
asincrono che sia, e' grossomodo questo:
Ogni volta che devi scrivere un qualche dato su disco, devi iniziare una
*serie* di operazioni, che vanno dalla scrittura del dato vero e proprio
alla scrittura dei puntatori e descrittori del dato stesso.
Solitamente, tali informazioni stanno in punti distanti e comunque
distinti del supporto di memorizzazione, percio', ogni interruzione del
funzionamento tra la prima e l'ultima di queste attivita', ti lascia il
file system in stato inconsistente.
Insomma, il journaling e' l'unico sistema per imbrogliare: O hai i dati
consistenti sul file system, o hai comunque una situazione pienamente
conclusa sul sistema di journal. Che poi i dati siano gli ultimi, i
penultimi o precedenti, sono comunque consistenti.
-- 
           |Save our planet!
  Ciao     |Save wildlife;
  roberto  |For your E-MAIL use only recycled Bytes !!
           |roberto poggi  
rpo...@softhome.net

  Ci provo io, terra terra.
[...]
Ora e' tutto chiaro, non riuscivo a cogliere il significato di "rendere
atomica"; il fatto e' che mentre scrivevo non stavo pensando ai
filesystem journaled, avevo in mente la differenza di prestazioni
tra una partizione ext2 in modalita' asincrona (linux) e una partizione
ufs in modalita' sincrona (OpenBSD), ed al fatto che con i dati scritti
in maniera sincrona non ci sono dati persi per via dei buffer (cache del
disco fisso a parte)


 Ciao
ciao
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 Una prova non costa nulla... allungare il 3d costa agli altri
fatta la prova... non ho notato nessun peggioramento "visibile".
Forse (e probabilmente) su server la differenza si vede ma in single
non la noto.
prova realizzate scaricando ng, usando gimp, visualizzando dvd.
ho visto anche che dipende dalla quantità di RAM. 
Io lo swap praticamente lo tengo per bellezza, in caso di uso dello swap
pesante il discorso cambia e parecchio.
