Discussione:
Le 10 maggiori novità di Windows Server 2008...
(troppo vecchio per rispondere)
Fabio Fioretti - WindoM
2007-05-29 00:33:32 UTC
Permalink
... secondo BetaNews:

http://www.betanews.com/article/Top_10_New_Features_in_Windows_Server_2008/1180045346

#10: The self-healing NTFS file system.
#9: Parallel session creation.
#8: Clean service shutdown.
#7: Kernel Transaction Manager.
#6: SMB2 network file system.
#5: Address Space Load Randomization (ASLR).
#4: Windows Hardware Error Architecture (WHEA).
#3: Windows Server Virtualization.
#2: PowerShell.
#1: Server Core.


Lettura consigliata. A parte il numero 8, secondo me marginale, le altre
caratteristiche evidenziate sono tutte degne di nota. Notevole la numero 10.
Da sottolineare le numero 2 e 1: la nuova shell (e che shell!) finalmente
integrata nel sistema e la tanto agognata indipendenza dall'interfaccia
grafica.


SALUTONI,

WindoM
Ottavio Campana
2007-05-29 03:00:08 UTC
Permalink
Post by Fabio Fioretti - WindoM
http://www.betanews.com/article/Top_10_New_Features_in_Windows_Server_2008/1180045346
#10: The self-healing NTFS file system.
lodevole esempio di marketing: spacciare un taccone per una feature. Ma
fare un filesysem robusto? Posso capire su dischi ide dove il protocollo
non prevede la conferma della correttezza dei dati scritti, ma su scsi
non dovrebbe mai accadere che si sputtani una parte del filesystem.
Fabio Fioretti - WindoM
2007-05-29 13:28:21 UTC
Permalink
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
#10: The self-healing NTFS file system.
lodevole esempio di marketing: spacciare un taccone per una feature. Ma
fare un filesysem robusto?
Perché NTFS non sarebbe robusto?
Post by Ottavio Campana
Posso capire su dischi ide dove il protocollo
non prevede la conferma della correttezza dei dati scritti, ma su scsi
non dovrebbe mai accadere che si sputtani una parte del filesystem.
E se un settore del disco comincia a far cilecca?


SALUTONI,

WindoM
Ottavio Campana
2007-05-29 15:32:34 UTC
Permalink
Post by Fabio Fioretti - WindoM
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
#10: The self-healing NTFS file system.
lodevole esempio di marketing: spacciare un taccone per una feature. Ma
fare un filesysem robusto?
Perché NTFS non sarebbe robusto?
se prevedono un taccone e poi anche alla voce kernel transaction manager
riaprlano di sputtanamenti del filesystem allora forse un dubbio mi viene.
Post by Fabio Fioretti - WindoM
Post by Ottavio Campana
Posso capire su dischi ide dove il protocollo
non prevede la conferma della correttezza dei dati scritti, ma su scsi
non dovrebbe mai accadere che si sputtani una parte del filesystem.
E se un settore del disco comincia a far cilecca?
con scsi lo rilevi. ha il controllo di errore apposta.

Parliamo di server, quindi con hardware carrozzato, non del pc sotto la
scrivania.
unknown
2007-05-30 09:32:48 UTC
Permalink
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
#10: The self-healing NTFS file system.
lodevole esempio di marketing: spacciare un taccone per una feature. Ma
fare un filesysem robusto?
Perché NTFS non sarebbe robusto?
se prevedono un taccone e poi anche alla voce kernel transaction manager
riaprlano di sputtanamenti del filesystem allora forse un dubbio mi viene.
Sai anche che 'transaction' e` una parolona bella di moda ora...
--
Sensei <senseiwa at Apple's mac dot com>

There is no reason for any individual to have a computer in his home.
(Ken Olsen, President, Digital Equipment, 1977)
Ottavio Campana
2007-05-30 18:16:40 UTC
Permalink
Post by unknown
Sai anche che 'transaction' e` una parolona bella di moda ora...
a me piacciono quelle finanziarie che apportano capitali al mio conto :-P
unknown
2007-06-01 10:18:58 UTC
Permalink
Post by Ottavio Campana
Post by unknown
Sai anche che 'transaction' e` una parolona bella di moda ora...
a me piacciono quelle finanziarie che apportano capitali al mio conto :-P
Se ne vuoi fare una sul mio conto sei il benvenuto eh :D
--
Sensei <senseiwa at Apple's mac dot com>

Beware of bugs in the above code; I have only proved it correct, not tried it.
(Donald Knuth)
Fabio Fioretti - WindoM
2007-05-30 11:37:39 UTC
Permalink
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Perché NTFS non sarebbe robusto?
se prevedono un taccone
Ma, fammi capire, non ti è mai capitato di dover fare un fsck su un
journaled file system? Ubuntu, per fare un esempio, me lo fa in automatico
ogni n boot, ma non per questo mi sento di dire che ext3 non sia robusto.
:-) Se "self-healing NTFS" saprà fare il check online, non mi pare un
miglioramento trascurabile.
Post by Ottavio Campana
e poi anche alla voce kernel transaction manager
riaprlano di sputtanamenti del filesystem allora forse un dubbio mi viene.
Nella sezione relativa al Kernel Transaction Manager, l'uso del termine
"corruption" è infelice: KTM agisce sul file system inteso come dati (e sul
Registry) fornendo alle applicazioni un layer d'accesso transaction based,
anche in modo distribuito, in stile DBMS.
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Post by Ottavio Campana
Posso capire su dischi ide dove il protocollo
non prevede la conferma della correttezza dei dati scritti, ma su scsi
non dovrebbe mai accadere che si sputtani una parte del filesystem.
E se un settore del disco comincia a far cilecca?
con scsi lo rilevi. ha il controllo di errore apposta.
Non che sia infallibile... un controllo online a livello di sistema
operativo non mi sembra da buttar via.


SALUTONI,

WindoM
Ottavio Campana
2007-05-30 18:16:45 UTC
Permalink
Post by Fabio Fioretti - WindoM
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Perché NTFS non sarebbe robusto?
se prevedono un taccone
Ma, fammi capire, non ti è mai capitato di dover fare un fsck su un
journaled file system? Ubuntu, per fare un esempio, me lo fa in automatico
ogni n boot, ma non per questo mi sento di dire che ext3 non sia robusto.
:-) Se "self-healing NTFS" saprà fare il check online, non mi pare un
miglioramento trascurabile.
premesso che di fsck di solito li faccio perché mi trovo a reboottare
sistemi con uptime anche di anni e di solito debian suggerisce per
sicurezza di farlo almeno ogni 180 giorni.

Una cosa è se il filesystem si sputtana per motivi fisici, come la
mancanza di corrente e scaricamento degli ups (evento raro se l'upsmè
dimensionato in modo saggio) o per rotture del server tipo alimentatori
che seppur ridondanti vanno al creatore (e qua non ci sono nè santi né
madonne).

Però un'altra cosa è dire che prevedi un meccanismo per correggere le
strutture dati (nota bene: non i dati, come nei filesystem journaled)
durante la normale attività del server. Perché stai dicendo che ti si
sputtana il filesystem anche durante le normali operazioni....

Se questo non corrisponde a verità allora hanno toppato a presentare la
feature.
Post by Fabio Fioretti - WindoM
Post by Ottavio Campana
e poi anche alla voce kernel transaction manager
riaprlano di sputtanamenti del filesystem allora forse un dubbio mi viene.
Nella sezione relativa al Kernel Transaction Manager, l'uso del termine
"corruption" è infelice: KTM agisce sul file system inteso come dati (e sul
Registry) fornendo alle applicazioni un layer d'accesso transaction based,
anche in modo distribuito, in stile DBMS.
ok, ma serve? sinceramente, non basta un locking decente?
Fabio Fioretti - WindoM
2007-05-30 19:46:53 UTC
Permalink
Post by Ottavio Campana
Però un'altra cosa è dire che prevedi un meccanismo per correggere le
strutture dati (nota bene: non i dati, come nei filesystem journaled)
durante la normale attività del server. Perché stai dicendo che ti si
sputtana il filesystem anche durante le normali operazioni....
Non è la "normale attività" del server, è ovvio che c'è qualche problema
software (sotto il layer del file system) o hardware.

Qualche tempo fa, il server principale di kernel.org s'è schiantato per
problemi di corruzione del file system a livello di RAID. Ext3 non ha potuto
farci niente. Self-healing NTFS avrebbe potuto limitare i danni, riparare la
corruzione a runtime segnalando prontamente il problema e permetterne la
risoluzione senza mandare a farfalle tutto il file system.

Per fare un fsck su quella macchina c'è voluta più di una settimana, più del
tempo necessario a ripristinare l'intero file system dal backup.
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Nella sezione relativa al Kernel Transaction Manager, l'uso del termine
"corruption" è infelice: KTM agisce sul file system inteso come dati (e
sul Registry) fornendo alle applicazioni un layer d'accesso transaction
based, anche in modo distribuito, in stile DBMS.
ok, ma serve? sinceramente, non basta un locking decente?
No, un semplice locking non basta perché non ha il roll-back. Se anche
bastasse, sarebbe un incubo lasciare tutto in mano agli sviluppatori
applicativi... KTM semplifica e centralizza.

KTM, inoltre, è alla base di Transactional NTFS:

http://msdn2.microsoft.com/en-us/library/aa365456.aspx

"Transactional NTFS (TxF) integrates transactions into the NTFS file system,
which makes it easier for application developers and administrators to
gracefully handle errors and preserve data integrity.

TxF can participate in distributed transactions that the Distributed
Transaction Coordinator (DTC) coordinates, which allows you to use TxF for
the following:

- Transactions that span multiple data stores, for example, a single
transaction for file and SQL operations
- Transactions that span multiple computers, for example, a single
transaction for file updates on multiple computers"


SALUTONI,

WindoM
Ottavio Campana
2007-05-30 20:48:11 UTC
Permalink
Post by Fabio Fioretti - WindoM
Post by Ottavio Campana
Però un'altra cosa è dire che prevedi un meccanismo per correggere le
strutture dati (nota bene: non i dati, come nei filesystem journaled)
durante la normale attività del server. Perché stai dicendo che ti si
sputtana il filesystem anche durante le normali operazioni....
Non è la "normale attività" del server, è ovvio che c'è qualche problema
software (sotto il layer del file system) o hardware.
allora, se il problema è hardware non ci sono santi: il sistema è fottuto.

se il problema è software allora è bug di windows e la feature è un taccone.
Post by Fabio Fioretti - WindoM
Qualche tempo fa, il server principale di kernel.org s'è schiantato per
problemi di corruzione del file system a livello di RAID. Ext3 non ha potuto
farci niente. Self-healing NTFS avrebbe potuto limitare i danni, riparare la
corruzione a runtime segnalando prontamente il problema e permetterne la
risoluzione senza mandare a farfalle tutto il file system.
no, se il danno è hardware non ci sono nè santi nè madonne. Come fai a
sapere che il contenuto dei volumi sia integro? E' triste, è una rottura
immensa di palle, ma se si schianta un volume prendi il backup e vivrai
meglio. Chi te lo fa fare di prendere, curare, poi prendere il backup
controllare i file, e ripristinare quelli dubbio senza avere la certezza
di averli presi tutti?
Post by Fabio Fioretti - WindoM
Per fare un fsck su quella macchina c'è voluta più di una settimana, più del
tempo necessario a ripristinare l'intero file system dal backup.
link, per piacere. detta così sembra una bufala. Sopratutto perché
voglio vedere quell'idiota che non ha preso un backup....
Post by Fabio Fioretti - WindoM
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Nella sezione relativa al Kernel Transaction Manager, l'uso del termine
"corruption" è infelice: KTM agisce sul file system inteso come dati (e
sul Registry) fornendo alle applicazioni un layer d'accesso transaction
based, anche in modo distribuito, in stile DBMS.
ok, ma serve? sinceramente, non basta un locking decente?
No, un semplice locking non basta perché non ha il roll-back. Se anche
bastasse, sarebbe un incubo lasciare tutto in mano agli sviluppatori
applicativi... KTM semplifica e centralizza.
ha proprio ragione sensei....
Post by Fabio Fioretti - WindoM
http://msdn2.microsoft.com/en-us/library/aa365456.aspx
"Transactional NTFS (TxF) integrates transactions into the NTFS file system,
which makes it easier for application developers and administrators to
gracefully handle errors and preserve data integrity.
TxF can participate in distributed transactions that the Distributed
Transaction Coordinator (DTC) coordinates, which allows you to use TxF for
- Transactions that span multiple data stores, for example, a single
transaction for file and SQL operations
- Transactions that span multiple computers, for example, a single
transaction for file updates on multiple computers"
insomma, è un distributed lock manager. nulldi nuovo, sebbene comodo.
Fabio Fioretti - WindoM
2007-05-31 00:31:51 UTC
Permalink
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Post by Ottavio Campana
Però un'altra cosa è dire che prevedi un meccanismo per correggere le
strutture dati (nota bene: non i dati, come nei filesystem journaled)
durante la normale attività del server. Perché stai dicendo che ti si
sputtana il filesystem anche durante le normali operazioni....
Non è la "normale attività" del server, è ovvio che c'è qualche problema
software (sotto il layer del file system) o hardware.
allora, se il problema è hardware non ci sono santi: il sistema è fottuto.
E su questo posso concordare, anche se non è scontanto e bisognerebbe vedere
l'effettiva implementazione.
Post by Ottavio Campana
se il problema è software allora è bug di windows e la feature è un taccone.
Ottavio, basta un driver bacato, basta un bug di un layer sotto il file
system come RAID...
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Qualche tempo fa, il server principale di kernel.org s'è schiantato per
problemi di corruzione del file system a livello di RAID. Ext3 non ha
potuto farci niente. Self-healing NTFS avrebbe potuto limitare i danni,
riparare la corruzione a runtime segnalando prontamente il problema
e permetterne la risoluzione senza mandare a farfalle tutto il file
system.
no, se il danno è hardware non ci sono nè santi nè madonne. Come fai a
sapere che il contenuto dei volumi sia integro? E' triste, è una rottura
immensa di palle, ma se si schianta un volume prendi il backup e vivrai
meglio. Chi te lo fa fare di prendere, curare, poi prendere il backup
controllare i file, e ripristinare quelli dubbio senza avere la certezza
di averli presi tutti?
Bada che è il RAID software ad essere impazzito in questo caso, dovrebbero
esserci tracce del fattaccio su LKML. Un check a livello di file system
avrebbe potuto rattoppare gran parte dei danni del caso.
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Per fare un fsck su quella macchina c'è voluta più di una settimana, più
del tempo necessario a ripristinare l'intero file system dal backup.
link, per piacere. detta così sembra una bufala. Sopratutto perché
voglio vedere quell'idiota che non ha preso un backup....
Sembra che l'abbia scritto io ma giuro che non è così. :-)

"Recently the main server for kernel.org, which hosts several years' worth
of Linux kernel archives, suffered file system corruption at the RAID level;
running fsck on the (journaling) ext3 file system took over a week, more
than the time required to restore the entire file system from backup. In
addition, two of our primary design targets, desktops and laptops, so far
have not been attractive markets for RAID."
http://www.usenix.org/events/hotdep06/tech/prelim_papers/henson/henson_html/node2.html
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
No, un semplice locking non basta perché non ha il roll-back. Se anche
bastasse, sarebbe un incubo lasciare tutto in mano agli sviluppatori
applicativi... KTM semplifica e centralizza.
ha proprio ragione sensei....
Non capisco, i meccanismi di lock che conosco non fanno mai roll-back. Se
un'applicazione è scritta male, prende un lock, fa un mezzo update, lo
scrive (e c'è chi lo fa, ah se lo fanno!) e si schianta prima di terminarlo,
la consistenza che fine fa? KTM rilascia il lock e fa il roll-back
automatico.

[Transactional NTFS]
Post by Ottavio Campana
insomma, è un distributed lock manager. nulldi nuovo, sebbene comodo.
Linkami un lock manager distribuito con capacità di roll-back e di
effettuare operazioni atomiche su set di file locali e remoti e concorderò
che non è nulla di nuovo. :-) Sicuramente è nuovo per il mondo Windows, e
già non è poco.


SALUTONI,

WindoM
Ottavio Campana
2007-05-31 02:16:02 UTC
Permalink
Post by Fabio Fioretti - WindoM
Post by Ottavio Campana
se il problema è software allora è bug di windows e la feature è un taccone.
Ottavio, basta un driver bacato, basta un bug di un layer sotto il file
system come RAID...
e allora il self healing è un taccone. Invece che fare un programma che
cerca di mettere una pezza agli errori di un altro programma e che per
quanto possa essere bravo non può darti il 100% di garanzia, è meglio
fissare il layer sottostante che fa schifo.

anche perché gli errori del filesystem sono subdoli spesso e se ne
stanno lì un bel po' prima di apparire e se poi li correggi puoi
nascondere altri problemi. Se ti si rompe la ram (mi è successo per la
prima volta due mesi fa) senza farti crepare la macchina perché magari è
in una zona non usata non te ne accorgi fino a quando invece di
sputtanare un pezzettino di fs non sputtani il contenuto della libc e a
quel punto prendi il server e lo tiri nel cesso (maledetto upgrade
all'ultima stable di debian che per una volta ha fatto usare tutta la
ram al server...)
Post by Fabio Fioretti - WindoM
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Qualche tempo fa, il server principale di kernel.org s'è schiantato per
problemi di corruzione del file system a livello di RAID. Ext3 non ha
potuto farci niente. Self-healing NTFS avrebbe potuto limitare i danni,
riparare la corruzione a runtime segnalando prontamente il problema
e permetterne la risoluzione senza mandare a farfalle tutto il file
system.
no, se il danno è hardware non ci sono nè santi nè madonne. Come fai a
sapere che il contenuto dei volumi sia integro? E' triste, è una rottura
immensa di palle, ma se si schianta un volume prendi il backup e vivrai
meglio. Chi te lo fa fare di prendere, curare, poi prendere il backup
controllare i file, e ripristinare quelli dubbio senza avere la certezza
di averli presi tutti?
Bada che è il RAID software ad essere impazzito in questo caso, dovrebbero
esserci tracce del fattaccio su LKML. Un check a livello di file system
avrebbe potuto rattoppare gran parte dei danni del caso.
una gran parte, non tutti. Scusa eh, ma in ottica sistemistica io devo
garantire il 100% dei file, non il 99%. (vedi sotto)
Post by Fabio Fioretti - WindoM
"Recently the main server for kernel.org, which hosts several years' worth
of Linux kernel archives, suffered file system corruption at the RAID level;
running fsck on the (journaling) ext3 file system took over a week, more
than the time required to restore the entire file system from backup. In
addition, two of our primary design targets, desktops and laptops, so far
have not been attractive markets for RAID."
http://www.usenix.org/events/hotdep06/tech/prelim_papers/henson/henson_html/node2.html
io uno così l'avrei licenziato o almeno incarnato fisso. Tempo perso e
non certezza del corretto recupero dei file (vogliamo controllare che il
LWZ di tutte le tarball sia corretto? ma siamo scemi!?!)
Post by Fabio Fioretti - WindoM
Post by Ottavio Campana
insomma, è un distributed lock manager. nulldi nuovo, sebbene comodo.
Linkami un lock manager distribuito con capacità di roll-back e di
effettuare operazioni atomiche su set di file locali e remoti e concorderò
che non è nulla di nuovo. :-) Sicuramente è nuovo per il mondo Windows, e
già non è poco.
coda? non ha proprio il rollback ma comunque delle euristiche per
risolvere i problemi del fs distribuito. Anche intermezzo ha una policy
per questo tipo di conflitti. E lustre parla proprio di transactions.

Poi c'è anche da dire che vorrei vedere cosa sia un rollback di una
transaction in una write. Dopotutto o scrivi o non scrivi.... Ammetto
che non programmo sotto win, ma rimango basito da quella che spero che
sia una feature inutile, perché se serve una roba del genere vuol dire
che la maggior parte dei programmatori per win non ha idea di cosa sia
il locking.....
Fabio Fioretti - WindoM
2007-05-31 14:54:35 UTC
Permalink
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Ottavio, basta un driver bacato, basta un bug di un layer sotto il file
system come RAID...
e allora il self healing è un taccone.
Kernel.org con quel taccone avrebbe forse evitato una settimana di grane.
Post by Ottavio Campana
Invece che fare un programma che
cerca di mettere una pezza agli errori di un altro programma e che per
quanto possa essere bravo non può darti il 100% di garanzia, è meglio
fissare il layer sottostante che fa schifo.
Grazie al cavolo, ma non puoi fare mai assunzioni su tutto quello che hai
sotto il file system e, in ogni caso, fidarsi è bene ma non fidarsi è
meglio. E' meglio che un file system si schianti al primo errore o è meglio
dotarlo di una sentinella a runtime in modo che si accorga dei problemi, li
segnali e li ripari? Poi è ovvio che il sistemista accorto indaghi sulle
cause e risolva i problemi nel più breve tempo possibile, con la piccola
differenza di ritrovarsi un file system consistente, senza il bisogno di
fsck o backup. Tra l'altro, anche ZFS prevede un meccanismo simile.

Comunque Self-Healing NTFS fa diverse cose:
http://technet2.microsoft.com/windowsserver2008/en/library/6f883d0d-3668-4e15-b7ad-4df0f6e6805d1033.mspx?mfr=true
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Bada che è il RAID software ad essere impazzito in questo caso,
dovrebbero esserci tracce del fattaccio su LKML. Un check a
livello di file system avrebbe potuto rattoppare gran parte dei
danni del caso.
una gran parte, non tutti.
Questo è tutto da dimostrare.
Post by Ottavio Campana
Scusa eh, ma in ottica sistemistica io devo
garantire il 100% dei file, non il 99%. (vedi sotto)
Tra lo 0% e il 99% io preferisco il 99%.
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
http://www.usenix.org/events/hotdep06/tech/prelim_papers/henson/henson_html/node2.html
io uno così l'avrei licenziato o almeno incarnato fisso. Tempo perso e
non certezza del corretto recupero dei file (vogliamo controllare che il
LWZ di tutte le tarball sia corretto? ma siamo scemi!?!)
Appunto, magari Self-Healing NTFS sarebbe riuscito a mantenere il file
system consistente o a limitare le parti di file system da riparare offline.
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Post by Ottavio Campana
insomma, è un distributed lock manager. nulldi nuovo, sebbene comodo.
Linkami un lock manager distribuito con capacità di roll-back e di
effettuare operazioni atomiche su set di file locali e remoti e
concorderò che non è nulla di nuovo. :-) Sicuramente è nuovo per
il mondo Windows, e già non è poco.
coda? non ha proprio il rollback ma comunque delle euristiche per
risolvere i problemi del fs distribuito. Anche intermezzo ha una policy
per questo tipo di conflitti. E lustre parla proprio di transactions.
Va be', se vai a prendere i file system distribuiti non vale... io voglio un
lock manager (integrato in un OS a scelta) con capacità di roll-back e di
effettuare operazioni atomiche su set di file locali e remoti, con tanto di
API accessibili sia da processi in user-space che in kernel-space. Ovvero,
voglio un file system transazionale.
Post by Ottavio Campana
Poi c'è anche da dire che vorrei vedere cosa sia un rollback di una
transaction in una write. Dopotutto o scrivi o non scrivi....
Su un set di file, magari remoti? Scrivi o non scrivi? Senza un transaction
manager puoi scriverne la metà e lasciare gli altri in stato inconsistente:
addio!
Post by Ottavio Campana
Ammetto
che non programmo sotto win, ma rimango basito da quella che spero che
sia una feature inutile, perché se serve una roba del genere vuol dire
che la maggior parte dei programmatori per win non ha idea di cosa sia
il locking.....
Da come ne parli sembra molto più probabile che tu non abbia idea di cosa
sia una transazione.

Altrimenti ti prego di indicarmi un DBMS robusto senza roll-back.


SALUTONI,

WindoM
Ottavio Campana
2007-05-31 15:52:42 UTC
Permalink
Post by Fabio Fioretti - WindoM
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Ottavio, basta un driver bacato, basta un bug di un layer sotto il file
system come RAID...
e allora il self healing è un taccone.
Kernel.org con quel taccone avrebbe forse evitato una settimana di grane.
riprendendo dal backup avrebbe fatto molto prima. e meglio.
Post by Fabio Fioretti - WindoM
Post by Ottavio Campana
Invece che fare un programma che
cerca di mettere una pezza agli errori di un altro programma e che per
quanto possa essere bravo non può darti il 100% di garanzia, è meglio
fissare il layer sottostante che fa schifo.
Grazie al cavolo, ma non puoi fare mai assunzioni su tutto quello che hai
sotto il file system e, in ogni caso, fidarsi è bene ma non fidarsi è
meglio. E' meglio che un file system si schianti al primo errore o è meglio
dotarlo di una sentinella a runtime in modo che si accorga dei problemi, li
segnali e li ripari? Poi è ovvio che il sistemista accorto indaghi sulle
cause e risolva i problemi nel più breve tempo possibile, con la piccola
differenza di ritrovarsi un file system consistente, senza il bisogno di
fsck o backup. Tra l'altro, anche ZFS prevede un meccanismo simile.
http://technet2.microsoft.com/windowsserver2008/en/library/6f883d0d-3668-4e15-b7ad-4df0f6e6805d1033.mspx?mfr=true
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Bada che è il RAID software ad essere impazzito in questo caso,
dovrebbero esserci tracce del fattaccio su LKML. Un check a
livello di file system avrebbe potuto rattoppare gran parte dei
danni del caso.
una gran parte, non tutti.
Questo è tutto da dimostrare.
sei tu che devi dimostrare che recuperi tutto. Dire che hai la certezza
di recuperare tutto è una affermazione molto forte ed è un caso
particolare della mia.
Post by Fabio Fioretti - WindoM
Post by Ottavio Campana
Scusa eh, ma in ottica sistemistica io devo
garantire il 100% dei file, non il 99%. (vedi sotto)
Tra lo 0% e il 99% io preferisco il 99%.
mi auguro tu non sia un professionista.
Post by Fabio Fioretti - WindoM
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
http://www.usenix.org/events/hotdep06/tech/prelim_papers/henson/henson_html/node2.html
io uno così l'avrei licenziato o almeno incarnato fisso. Tempo perso e
non certezza del corretto recupero dei file (vogliamo controllare che il
LWZ di tutte le tarball sia corretto? ma siamo scemi!?!)
Appunto, magari Self-Healing NTFS sarebbe riuscito a mantenere il file
system consistente o a limitare le parti di file system da riparare offline.
ma se ti si corrompe il fs va rifatto. basta. Ma questo non centra col
sistema operativo, centra con la professionalità del sistemista. E se
fai le cose fatte bene riesci ad avere tempi molto ridotti di down,
tendenti al nullo.
Post by Fabio Fioretti - WindoM
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Post by Ottavio Campana
insomma, è un distributed lock manager. nulldi nuovo, sebbene comodo.
Linkami un lock manager distribuito con capacità di roll-back e di
effettuare operazioni atomiche su set di file locali e remoti e
concorderò che non è nulla di nuovo. :-) Sicuramente è nuovo per
il mondo Windows, e già non è poco.
coda? non ha proprio il rollback ma comunque delle euristiche per
risolvere i problemi del fs distribuito. Anche intermezzo ha una policy
per questo tipo di conflitti. E lustre parla proprio di transactions.
Va be', se vai a prendere i file system distribuiti non vale... io voglio un
lock manager (integrato in un OS a scelta) con capacità di roll-back e di
effettuare operazioni atomiche su set di file locali e remoti, con tanto di
API accessibili sia da processi in user-space che in kernel-space. Ovvero,
voglio un file system transazionale.
guarda che il locking coi file, vecchio di decine di anni era
distribuito e faceva fare operazioni atomiche se usato bene.
Post by Fabio Fioretti - WindoM
Post by Ottavio Campana
Poi c'è anche da dire che vorrei vedere cosa sia un rollback di una
transaction in una write. Dopotutto o scrivi o non scrivi....
Su un set di file, magari remoti? Scrivi o non scrivi? Senza un transaction
addio!
ma non è vero! coda, intermezzo e lustre hanno il supporto per
l'operatività offline!
Post by Fabio Fioretti - WindoM
Post by Ottavio Campana
Ammetto
che non programmo sotto win, ma rimango basito da quella che spero che
sia una feature inutile, perché se serve una roba del genere vuol dire
che la maggior parte dei programmatori per win non ha idea di cosa sia
il locking.....
Da come ne parli sembra molto più probabile che tu non abbia idea di cosa
sia una transazione.
Altrimenti ti prego di indicarmi un DBMS robusto senza roll-back.
sei tu che non capisci quello che intendo. Sto cercando di dirte che le
semantiche di scirttura su un volume non sono la stessa cosa che una
transazione in un db.

Tra avere un rollback nella scrittura di un file e avere una write che
ritorna uno 0 e riscrivere non cambia nulla, ai fini pratici. Se tu
apri n file, sciriv un po' in uno, poi un po' in un altro e così vie e
poi torni al primo, allora forse come programmatore hai dei problemi.
Non crederai che le transazioni sul fs faranno bene alle performance, vero?
Fabio Fioretti - WindoM
2007-05-31 16:38:13 UTC
Permalink
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Kernel.org con quel taccone avrebbe forse evitato una settimana di grane.
riprendendo dal backup avrebbe fatto molto prima. e meglio.
Meglio forse, prima no.
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Post by Ottavio Campana
Invece che fare un programma che
cerca di mettere una pezza agli errori di un altro programma e che per
quanto possa essere bravo non può darti il 100% di garanzia, è meglio
fissare il layer sottostante che fa schifo.
Grazie al cavolo, ma non puoi fare mai assunzioni su tutto quello che hai
sotto il file system e, in ogni caso, fidarsi è bene ma non fidarsi è
meglio. E' meglio che un file system si schianti al primo errore o è
meglio dotarlo di una sentinella a runtime in modo che si accorga dei
problemi, li segnali e li ripari? Poi è ovvio che il sistemista accorto
indaghi sulle cause e risolva i problemi nel più breve tempo possibile,
con la piccola differenza di ritrovarsi un file system consistente, senza
il bisogno di fsck o backup. Tra l'altro, anche ZFS prevede un meccanismo
simile.
A questo non hai risposto.
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Bada che è il RAID software ad essere impazzito in questo caso,
dovrebbero esserci tracce del fattaccio su LKML. Un check a
livello di file system avrebbe potuto rattoppare gran parte dei
danni del caso.
una gran parte, non tutti.
Questo è tutto da dimostrare.
sei tu che devi dimostrare che recuperi tutto.
Ovviamente neanch'io posso dimostrarlo, e neanche lo sostengo, leggo solo la
documentazione della tecnologia e mi faccio un'idea su quello che vorrebbe e
potrebbe fare. Di questo stiamo parlando.
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Post by Ottavio Campana
Scusa eh, ma in ottica sistemistica io devo
garantire il 100% dei file, non il 99%. (vedi sotto)
Tra lo 0% e il 99% io preferisco il 99%.
mi auguro tu non sia un professionista.
Lo sono. :-) Un professionista professionale, di quelli che se possono
salvare il 99% dei dati li salvano pagando la licenza di un sistema
operativo con un file system che offra qualche garanzia in più. :-P
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Appunto, magari Self-Healing NTFS sarebbe riuscito a mantenere il file
system consistente o a limitare le parti di file system da riparare offline.
ma se ti si corrompe il fs va rifatto. basta. Ma questo non centra col
sistema operativo, centra con la professionalità del sistemista.
Quale parte di "Self-Healing NTFS è fatto per mantenere il file system
consistente o limitare le parti di file system da riparare offline" non ti è
chiara?
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Va be', se vai a prendere i file system distribuiti non vale... io voglio
un lock manager (integrato in un OS a scelta) con capacità di roll-back e
di effettuare operazioni atomiche su set di file locali e remoti, con
tanto di API accessibili sia da processi in user-space che in
kernel-space. Ovvero, voglio un file system transazionale.
guarda che il locking coi file, vecchio di decine di anni era
distribuito e faceva fare operazioni atomiche se usato bene.
Insisti? Lock != transazione. Il lock non prevede roll-back.
http://it.wikipedia.org/wiki/Transazione_(database)

Per inciso, "se usato bene" è bellissimo.
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Post by Ottavio Campana
Poi c'è anche da dire che vorrei vedere cosa sia un rollback di una
transaction in una write. Dopotutto o scrivi o non scrivi....
Su un set di file, magari remoti? Scrivi o non scrivi? Senza un
transaction manager puoi scriverne la metà e lasciare gli altri in stato
inconsistente: addio!
ma non è vero! coda, intermezzo e lustre hanno il supporto per
l'operatività offline!
Continua a sfuggirti il concetto di transazione, o almeno la sua
applicazione a un file system.
Post by Ottavio Campana
Tra avere un rollback nella scrittura di un file e avere una write che
ritorna uno 0 e riscrivere non cambia nulla, ai fini pratici.
Scherzi vero? Riesci a pensare solo a singole write su processi immortali?
Post by Ottavio Campana
Se tu
apri n file, sciriv un po' in uno, poi un po' in un altro e così vie e
poi torni al primo, allora forse come programmatore hai dei problemi.
Non ti sfiora l'idea che i processi possono terminare inaspettatamente?
Immagina di dover modificare n file di configurazione. A metà delle
scritture il tuo processo muore. Addio consistenza.
Post by Ottavio Campana
Non crederai che le transazioni sul fs faranno bene alle performance, vero?
Il primo paper che ho trovato sull'argomento (2004):
Transactional File Systems Can Be Fast
http://www.pmg.csail.mit.edu/pubs/liskov04transactional-abstract.html

L'impatto in termini di performace dichiarata da Microsoft:
"We have done benchmarks to measure the performance impact of Transactions
on non-transactional file-system work-loads. It's very low, in the range of
1-2%."
http://channel9.msdn.com/Showpost.aspx?postid=142120

Inoltre, ti ricordo che l'uso delle transazioni è *opzionale*, a discrezione
del programmatore.


SALUTONI,

WindoM
Ottavio Campana
2007-05-31 17:55:03 UTC
Permalink
Post by Fabio Fioretti - WindoM
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Kernel.org con quel taccone avrebbe forse evitato una settimana di grane.
riprendendo dal backup avrebbe fatto molto prima. e meglio.
Meglio forse, prima no.
senti, vuoi che ci mettiamo a fare i conti di quanti giga fai in un
giorno con un dat ultrium?

Non farai mica i backup al lavoro sui cd, vero?
Post by Fabio Fioretti - WindoM
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Bada che è il RAID software ad essere impazzito in questo caso,
dovrebbero esserci tracce del fattaccio su LKML. Un check a
livello di file system avrebbe potuto rattoppare gran parte dei
danni del caso.
una gran parte, non tutti.
Questo è tutto da dimostrare.
sei tu che devi dimostrare che recuperi tutto.
Ovviamente neanch'io posso dimostrarlo, e neanche lo sostengo, leggo solo la
documentazione della tecnologia e mi faccio un'idea su quello che vorrebbe e
potrebbe fare. Di questo stiamo parlando.
eh no, il mio punto di vista è ben diverso: essere il sistemista che
deve garantire l'integrità di *tutti* i dati *sempre*.
Post by Fabio Fioretti - WindoM
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Post by Ottavio Campana
Scusa eh, ma in ottica sistemistica io devo
garantire il 100% dei file, non il 99%. (vedi sotto)
Tra lo 0% e il 99% io preferisco il 99%.
mi auguro tu non sia un professionista.
Lo sono. :-) Un professionista professionale, di quelli che se possono
salvare il 99% dei dati li salvano pagando la licenza di un sistema
operativo con un file system che offra qualche garanzia in più. :-P
pagare non è un problema. Il problema è che devi garantire il 100%. Se
non puoi farlo hai un problema con gli strumenti che usi. ripeto, non
stiamo discutendo della solita diatriba win/lin, stiamo parlando della
deontologia professionale. Il tool in questione fa comodo, ma io non mi
fiderei mai di esso in produzione.
Post by Fabio Fioretti - WindoM
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Appunto, magari Self-Healing NTFS sarebbe riuscito a mantenere il file
system consistente o a limitare le parti di file system da riparare offline.
ma se ti si corrompe il fs va rifatto. basta. Ma questo non centra col
sistema operativo, centra con la professionalità del sistemista.
Quale parte di "Self-Healing NTFS è fatto per mantenere il file system
consistente o limitare le parti di file system da riparare offline" non ti è
chiara?
che nella descrizione del primo link è scritto che slava le strutture
dati del fs e non i dati stesso. E che fsck o simili non recuperano
sempre al 100%. fsck durerà meno, ma non aumenta la sicurezza dei dati.
Post by Fabio Fioretti - WindoM
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Post by Ottavio Campana
Poi c'è anche da dire che vorrei vedere cosa sia un rollback di una
transaction in una write. Dopotutto o scrivi o non scrivi....
Su un set di file, magari remoti? Scrivi o non scrivi? Senza un
transaction manager puoi scriverne la metà e lasciare gli altri in stato
inconsistente: addio!
ma non è vero! coda, intermezzo e lustre hanno il supporto per
l'operatività offline!
Continua a sfuggirti il concetto di transazione, o almeno la sua
applicazione a un file system.
sì. dai, che forse ci capiamo. Io sostengo due cose:

1) le idee dei db non pssono essere copiate stereotipicamente per il
filesystem. Quindi il rollback per un filesystem imho non ha molto
senso, se non la possibilità di fare snapshot.

2) da un punto di vista di programmazione, tra un locking ben gestito e
le semantiche delle transazioni per serializzare gli accessi non vedo
questi grandi vantaggi innovativi. E se un programma crasha sono cazzi
del programma, non del sistema operativo. O almeno dovrebbe esserlo.
Certo che se poi M$ ha scelto un registro binario in cui tutti i
programmi mettono un mare di merda, viene fuori che la scelta del
registro unico binario forse non è stata la più felice.
Post by Fabio Fioretti - WindoM
Post by Ottavio Campana
Tra avere un rollback nella scrittura di un file e avere una write che
ritorna uno 0 e riscrivere non cambia nulla, ai fini pratici.
Scherzi vero? Riesci a pensare solo a singole write su processi immortali?
Post by Ottavio Campana
Se tu
apri n file, sciriv un po' in uno, poi un po' in un altro e così vie e
poi torni al primo, allora forse come programmatore hai dei problemi.
Non ti sfiora l'idea che i processi possono terminare inaspettatamente?
Immagina di dover modificare n file di configurazione. A metà delle
scritture il tuo processo muore. Addio consistenza.
ma allora vedi che il problema è del software? le transazioni a questo
punto servono più che altro come taccone per mettere un paracadute a chi
fa programmi buggati.
Post by Fabio Fioretti - WindoM
Post by Ottavio Campana
Non crederai che le transazioni sul fs faranno bene alle performance, vero?
Transactional File Systems Can Be Fast
http://www.pmg.csail.mit.edu/pubs/liskov04transactional-abstract.html
"We have done benchmarks to measure the performance impact of Transactions
on non-transactional file-system work-loads. It's very low, in the range of
1-2%."
http://channel9.msdn.com/Showpost.aspx?postid=142120
Inoltre, ti ricordo che l'uso delle transazioni è *opzionale*, a discrezione
del programmatore.
ok che è opzionale, però non sono per niente certo della cosa. E
soprattutto per via dei programmatori che faranno uso della feature...
Fabio Fioretti - WindoM
2007-05-31 18:35:34 UTC
Permalink
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Meglio forse, prima no.
senti, vuoi che ci mettiamo a fare i conti di quanti giga fai in un
giorno con un dat ultrium?
Non hai capito: puoi anche teletrasportare tutti i dati dal backup al
sistema in tre nanosecondi, ci avrai sempre messo più tempo che se non
avessi avuto la necessità di fare il ripristino.
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Ovviamente neanch'io posso dimostrarlo, e neanche lo sostengo, leggo solo
la documentazione della tecnologia e mi faccio un'idea su quello che
vorrebbe e potrebbe fare. Di questo stiamo parlando.
eh no, il mio punto di vista è ben diverso: essere il sistemista che
deve garantire l'integrità di *tutti* i dati *sempre*.
Che poi è la responsabilità primaria di ogni sistemista degno di tale
qualifica...
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Lo sono. :-) Un professionista professionale, di quelli che se possono
salvare il 99% dei dati li salvano pagando la licenza di un sistema
operativo con un file system che offra qualche garanzia in più. :-P
pagare non è un problema. Il problema è che devi garantire il 100%. Se
non puoi farlo hai un problema con gli strumenti che usi. ripeto, non
stiamo discutendo della solita diatriba win/lin, stiamo parlando della
deontologia professionale. Il tool in questione fa comodo, ma io non mi
fiderei mai di esso in produzione.
Non capisco perché tu abbia dei pregiudizi nei confronti di una tecnologia
che in realtà potrebbe esserti parecchio d'aiuto.

Confidando solo nel backup non garantirai mai il 100%: per quanto recente
sarà il tuo backup, gli ultimi dati mancheranno sempre all'appello.
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Quale parte di "Self-Healing NTFS è fatto per mantenere il file system
consistente o limitare le parti di file system da riparare offline" non
ti è chiara?
che nella descrizione del primo link è scritto che slava le strutture
dati del fs e non i dati stesso. E che fsck o simili non recuperano
sempre al 100%. fsck durerà meno, ma non aumenta la sicurezza dei dati.
Ma è chiaro! Niente sostituirà mai niente, sono strati di una stessa
cipolla:

- in caso di problemi, Self-Healing NTFS cerca di evitare di obbligarti a
fare un check offline del file system;

- quando non ci riesce, fsck cerca di evitare di farti recuperare dati dal
backup (che, per quanto recente, comporta una *perdita* degli ultimi dati);

- se va male anche questa, usi il backup.

Se vai dritto al backup ci sono tre opzioni:

1- tratti dati che valgono poco o niente (per cui perdere qualche ora/giorno
di aggiornamenti non è critico);

2 - fai backup in tre nanosecondi (nel qual caso dicci cosa usi);

3 - sei matto.
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Continua a sfuggirti il concetto di transazione, o almeno la sua
applicazione a un file system.
1) le idee dei db non pssono essere copiate stereotipicamente per il
filesystem. Quindi il rollback per un filesystem imho non ha molto
senso, se non la possibilità di fare snapshot.
Perché tu sostenga questa cosa, quando i file system transazionali sono
realtà già da un po', non me lo spieghi. Vai a sensazioni?
Post by Ottavio Campana
2) da un punto di vista di programmazione, tra un locking ben gestito e
le semantiche delle transazioni per serializzare gli accessi non vedo
questi grandi vantaggi innovativi. E se un programma crasha sono cazzi
del programma, non del sistema operativo. O almeno dovrebbe esserlo.
Se il sistema operativo è in grado di ripristinare i dati del programma (che
magari sono condivisi col sistema stesso o con altri programmi) a uno stato
consistente, a me pare una gran cosa. In sistemi complessi e distribuiti,
le cose che possono andare storte sono tante, non parliamo solo di bug... va
giù un segmento di rete e sei fregato. Roll-back e non è successo niente. Se
ti piace così tanto il backup perché ti fa tanto schifo il roll-back? :-)
Post by Ottavio Campana
Certo che se poi M$ ha scelto un registro binario in cui tutti i
programmi mettono un mare di merda, viene fuori che la scelta del
registro unico binario forse non è stata la più felice.
Per il Registry le transazioni tornano molto utili!
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Non ti sfiora l'idea che i processi possono terminare inaspettatamente?
Immagina di dover modificare n file di configurazione. A metà delle
scritture il tuo processo muore. Addio consistenza.
ma allora vedi che il problema è del software? le transazioni a questo
punto servono più che altro come taccone per mettere un paracadute a chi
fa programmi buggati.
Io ho capito il tuo discorso, ma non è granché logico... tu fai programmi
bug-free? Se un programma usa le transazioni significa che non è notepad ma
qualcosa di vagamente più complesso. Perché i DBMS usano le transazioni e
non usano solo il locking?
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Inoltre, ti ricordo che l'uso delle transazioni è *opzionale*, a
discrezione del programmatore.
ok che è opzionale, però non sono per niente certo della cosa. E
soprattutto per via dei programmatori che faranno uso della feature...
Va be', hai pregiudizi. :-P


SALUTONI,

WindoM
Ottavio Campana
2007-05-31 19:03:20 UTC
Permalink
Post by Fabio Fioretti - WindoM
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Meglio forse, prima no.
senti, vuoi che ci mettiamo a fare i conti di quanti giga fai in un
giorno con un dat ultrium?
Non hai capito: puoi anche teletrasportare tutti i dati dal backup al
sistema in tre nanosecondi, ci avrai sempre messo più tempo che se non
avessi avuto la necessità di fare il ripristino.
non hai capito tu: il self healing non ti dà la garanzia di poterlo evitare.
Post by Fabio Fioretti - WindoM
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Ovviamente neanch'io posso dimostrarlo, e neanche lo sostengo, leggo solo
la documentazione della tecnologia e mi faccio un'idea su quello che
vorrebbe e potrebbe fare. Di questo stiamo parlando.
eh no, il mio punto di vista è ben diverso: essere il sistemista che
deve garantire l'integrità di *tutti* i dati *sempre*.
Che poi è la responsabilità primaria di ogni sistemista degno di tale
qualifica...
ti definisci sistemista senza esserne degno? ;-P

(no dai, prendila come scherzo :-) )
Post by Fabio Fioretti - WindoM
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Lo sono. :-) Un professionista professionale, di quelli che se possono
salvare il 99% dei dati li salvano pagando la licenza di un sistema
operativo con un file system che offra qualche garanzia in più. :-P
pagare non è un problema. Il problema è che devi garantire il 100%. Se
non puoi farlo hai un problema con gli strumenti che usi. ripeto, non
stiamo discutendo della solita diatriba win/lin, stiamo parlando della
deontologia professionale. Il tool in questione fa comodo, ma io non mi
fiderei mai di esso in produzione.
Non capisco perché tu abbia dei pregiudizi nei confronti di una tecnologia
che in realtà potrebbe esserti parecchio d'aiuto.
perché mi è successo di avere un filesystem con le strutture dati
corrette e i contenuti dei file no. Sfiga? Sì, purtroppo.
Post by Fabio Fioretti - WindoM
Confidando solo nel backup non garantirai mai il 100%: per quanto recente
sarà il tuo backup, gli ultimi dati mancheranno sempre all'appello.
eh, basta organizzare bene le repliche dei dati per ridurle al minimo ;-)

per stare in casa M$: dfs.
Post by Fabio Fioretti - WindoM
1- tratti dati che valgono poco o niente (per cui perdere qualche ora/giorno
di aggiornamenti non è critico);
2 - fai backup in tre nanosecondi (nel qual caso dicci cosa usi);
3 - sei matto.
ci sarebbe un quarto punto:

4 - Il tempo perso per validare i dati e il fermo dell'attività che deve
usare quei dati è maggiore dell'intervallo di tempo tra un backup e l'altro.
Post by Fabio Fioretti - WindoM
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Continua a sfuggirti il concetto di transazione, o almeno la sua
applicazione a un file system.
1) le idee dei db non pssono essere copiate stereotipicamente per il
filesystem. Quindi il rollback per un filesystem imho non ha molto
senso, se non la possibilità di fare snapshot.
Perché tu sostenga questa cosa, quando i file system transazionali sono
realtà già da un po', non me lo spieghi. Vai a sensazioni?
guardala da questo punto: una appicazione deve scrivere sul disco. Se
non ci riesce perché la write torna 0 o perché fallisce la transazione,
sempre riscrivere deve.
Post by Fabio Fioretti - WindoM
Se il sistema operativo è in grado di ripristinare i dati del programma (che
magari sono condivisi col sistema stesso o con altri programmi) a uno stato
consistente, a me pare una gran cosa. In sistemi complessi e distribuiti,
le cose che possono andare storte sono tante, non parliamo solo di bug... va
giù un segmento di rete e sei fregato. Roll-back e non è successo niente. Se
ti piace così tanto il backup perché ti fa tanto schifo il roll-back? :-)
eh no, ci sono filesystem che già prevedono la funzionalità offline. te
ne ho citati 3 con questa caratteristica.
Post by Fabio Fioretti - WindoM
Post by Ottavio Campana
Certo che se poi M$ ha scelto un registro binario in cui tutti i
programmi mettono un mare di merda, viene fuori che la scelta del
registro unico binario forse non è stata la più felice.
Per il Registry le transazioni tornano molto utili!
sì, concordo. Ma allora forse il problema sta anche nel registry se devi
inserire un layer in più per evitare di corromperlo.

Tanti piccoli file saranno meno belli, ma hanno il vantaggio della
diversità, e spalmi le possibili rogne su tanti file.
Post by Fabio Fioretti - WindoM
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Non ti sfiora l'idea che i processi possono terminare inaspettatamente?
Immagina di dover modificare n file di configurazione. A metà delle
scritture il tuo processo muore. Addio consistenza.
ma allora vedi che il problema è del software? le transazioni a questo
punto servono più che altro come taccone per mettere un paracadute a chi
fa programmi buggati.
Io ho capito il tuo discorso, ma non è granché logico... tu fai programmi
bug-free? Se un programma usa le transazioni significa che non è notepad ma
qualcosa di vagamente più complesso. Perché i DBMS usano le transazioni e
non usano solo il locking?
guardala dal punto di vista dell'applicazione: lei vede sempre che la
scrittura fallisce e deve riprovare. Con la sfiga che il programmatore
dice "che me ne frega del locking e simili, se c'è un problema tanto
roll-backo e me ne posso fregare..."
Post by Fabio Fioretti - WindoM
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Inoltre, ti ricordo che l'uso delle transazioni è *opzionale*, a
discrezione del programmatore.
ok che è opzionale, però non sono per niente certo della cosa. E
soprattutto per via dei programmatori che faranno uso della feature...
Va be', hai pregiudizi. :-P
non lo so, probabilmente hai ragione, ma ho visto programmi che voi
umani.... ;-)

Ciao
Fabio Fioretti - WindoM
2007-05-31 20:04:19 UTC
Permalink
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Non hai capito: puoi anche teletrasportare tutti i dati dal backup al
sistema in tre nanosecondi, ci avrai sempre messo più tempo che se non
avessi avuto la necessità di fare il ripristino.
non hai capito tu: il self healing non ti dà la garanzia di poterlo evitare.
La garanzia no, la possibilità si! E' uno strato in più sulla tua cipolla!
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Non capisco perché tu abbia dei pregiudizi nei confronti di una
tecnologia che in realtà potrebbe esserti parecchio d'aiuto.
perché mi è successo di avere un filesystem con le strutture dati
corrette e i contenuti dei file no. Sfiga? Sì, purtroppo.
Purtroppo non è così raro, quando il journaling è solo sui metadati. Però
Self-Healing NTFS cerca di salvare i dati oltre che i metadati:

"Preserves data. Self-healing NTFS preserves as much data as possible, based
on the type of corruption detected."
http://technet2.microsoft.com/windowsserver2008/en/library/6f883d0d-3668-4e15-b7ad-4df0f6e6805d1033.mspx?mfr=true

Spero che in futuro esca qualche documento più dettagliato in merito.
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Confidando solo nel backup non garantirai mai il 100%: per quanto recente
sarà il tuo backup, gli ultimi dati mancheranno sempre all'appello.
eh, basta organizzare bene le repliche dei dati per ridurle al minimo ;-)
per stare in casa M$: dfs.
Ok, però qualcosa perdi, prima parlavi di preservare *tutti i dati*! ;-P
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
1- tratti dati che valgono poco o niente (per cui perdere qualche
ora/giorno di aggiornamenti non è critico);
2 - fai backup in tre nanosecondi (nel qual caso dicci cosa usi);
3 - sei matto.
4 - Il tempo perso per validare i dati e il fermo dell'attività che deve
usare quei dati è maggiore dell'intervallo di tempo tra un backup e l'altro.
Giusto. Ed è proprio nell'evitare il fermo dell'attività che lo strato di
cipolla di Self-Healing NTFS può esserti d'aiuto. :-)
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Perché tu sostenga questa cosa, quando i file system transazionali sono
realtà già da un po', non me lo spieghi. Vai a sensazioni?
guardala da questo punto: una appicazione deve scrivere sul disco. Se
non ci riesce perché la write torna 0 o perché fallisce la transazione,
sempre riscrivere deve.
Avevo già capito questa tua osservazione, ma guardala dal punto di vista dei
dati (in fin dei conti è di quelli che ti preoccupi, no?): non importa se
l'applicazione è bacata, se il layer RAID sta impazzendo o se cade un
segmento di rete, voglio che i dati restino consistenti. Un comportamento
transazionale del file system può essere di grosso aiuto. Dal punto di vista
dell'applicazione non cambia niente, se fallisce la write o fallisce la
transazione è la stessa cosa; per i dati c'è una bella differenza.
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Se il sistema operativo è in grado di ripristinare i dati del programma
(che magari sono condivisi col sistema stesso o con altri programmi) a
uno stato consistente, a me pare una gran cosa. In sistemi complessi e
distribuiti, le cose che possono andare storte sono tante, non parliamo
solo di bug... va giù un segmento di rete e sei fregato. Roll-back e non
è successo niente. Se ti piace così tanto il backup perché ti fa tanto
schifo il roll-back? :-)
eh no, ci sono filesystem che già prevedono la funzionalità offline. te
ne ho citati 3 con questa caratteristica.
Ho capito, ma quelli sono file system distribuiti, è ovvio che abbiano
quella roba! Ma poi, sono davvero transazionali? Hanno il roll-back attivo
su tutto il file system? Performance? (chiedo perché non li conosco bene, se
hai link simpatici sono tutt'occhi)
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Per il Registry le transazioni tornano molto utili!
sì, concordo. Ma allora forse il problema sta anche nel registry se devi
inserire un layer in più per evitare di corromperlo.
Mah, il Registry è un database gerarchico senza il concetto di
transazione... forse avrebbero dovuto pensarlo transazionale dall'inizio, ma
all'epoca...
Post by Ottavio Campana
Tanti piccoli file saranno meno belli, ma hanno il vantaggio della
diversità, e spalmi le possibili rogne su tanti file.
Con alcuni svantaggi però, tant'è vero che qualcuno, da qualche anno a
questa parte, scopiazza l'idea del Registry (chi ha detto GNOME? :-P).
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Va be', hai pregiudizi. :-P
non lo so, probabilmente hai ragione, ma ho visto programmi che voi
umani.... ;-)
LOL!


SALUTONI,

WindoM
Ottavio Campana
2007-05-31 20:51:11 UTC
Permalink
Post by Fabio Fioretti - WindoM
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Non hai capito: puoi anche teletrasportare tutti i dati dal backup al
sistema in tre nanosecondi, ci avrai sempre messo più tempo che se non
avessi avuto la necessità di fare il ripristino.
non hai capito tu: il self healing non ti dà la garanzia di poterlo evitare.
La garanzia no, la possibilità si!
ok. Per me questo *non* è sufficiente.
Post by Fabio Fioretti - WindoM
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Non capisco perché tu abbia dei pregiudizi nei confronti di una
tecnologia che in realtà potrebbe esserti parecchio d'aiuto.
perché mi è successo di avere un filesystem con le strutture dati
corrette e i contenuti dei file no. Sfiga? Sì, purtroppo.
Purtroppo non è così raro, quando il journaling è solo sui metadati. Però
"Preserves data. Self-healing NTFS preserves as much data as possible, based
on the type of corruption detected."
http://technet2.microsoft.com/windowsserver2008/en/library/6f883d0d-3668-4e15-b7ad-4df0f6e6805d1033.mspx?mfr=true
Spero che in futuro esca qualche documento più dettagliato in merito.
nell'altro documento dicono

| "So if there's a corruption detected someplace in the data structure,
| an NTFS worker thread is spawned," Russinovich explained

lui parla di strutture dati, non dati. Anche fosse però sui dati,
avviano il thread e non possono garantirti nulla. Se i file sono stati
sovrascritti?
Post by Fabio Fioretti - WindoM
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Confidando solo nel backup non garantirai mai il 100%: per quanto recente
sarà il tuo backup, gli ultimi dati mancheranno sempre all'appello.
eh, basta organizzare bene le repliche dei dati per ridurle al minimo ;-)
per stare in casa M$: dfs.
Ok, però qualcosa perdi, prima parlavi di preservare *tutti i dati*! ;-P
no, ok, perdi le ultime modifiche, però dei dati che hai devi anche
garantirli.
Post by Fabio Fioretti - WindoM
Post by Ottavio Campana
4 - Il tempo perso per validare i dati e il fermo dell'attività che deve
usare quei dati è maggiore dell'intervallo di tempo tra un backup e l'altro.
Giusto. Ed è proprio nell'evitare il fermo dell'attività che lo strato di
cipolla di Self-Healing NTFS può esserti d'aiuto. :-)
senti, da come Russinovich lo racconta non è così.
Post by Fabio Fioretti - WindoM
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Perché tu sostenga questa cosa, quando i file system transazionali sono
realtà già da un po', non me lo spieghi. Vai a sensazioni?
guardala da questo punto: una appicazione deve scrivere sul disco. Se
non ci riesce perché la write torna 0 o perché fallisce la transazione,
sempre riscrivere deve.
Avevo già capito questa tua osservazione, ma guardala dal punto di vista dei
dati (in fin dei conti è di quelli che ti preoccupi, no?): non importa se
l'applicazione è bacata, se il layer RAID sta impazzendo o se cade un
segmento di rete, voglio che i dati restino consistenti. Un comportamento
transazionale del file system può essere di grosso aiuto. Dal punto di vista
dell'applicazione non cambia niente, se fallisce la write o fallisce la
transazione è la stessa cosa; per i dati c'è una bella differenza.
ok, però cosa succede se invece la transazione ha successo ma i dati
sono sbagliati?
Post by Fabio Fioretti - WindoM
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Se il sistema operativo è in grado di ripristinare i dati del programma
(che magari sono condivisi col sistema stesso o con altri programmi) a
uno stato consistente, a me pare una gran cosa. In sistemi complessi e
distribuiti, le cose che possono andare storte sono tante, non parliamo
solo di bug... va giù un segmento di rete e sei fregato. Roll-back e non
è successo niente. Se ti piace così tanto il backup perché ti fa tanto
schifo il roll-back? :-)
eh no, ci sono filesystem che già prevedono la funzionalità offline. te
ne ho citati 3 con questa caratteristica.
Ho capito, ma quelli sono file system distribuiti, è ovvio che abbiano
quella roba! Ma poi, sono davvero transazionali? Hanno il roll-back attivo
su tutto il file system? Performance? (chiedo perché non li conosco bene, se
hai link simpatici sono tutt'occhi)
se vuoi investrie un po' di tempo su www.lustre.org ci sono degli
articoli che ne parlano.
Post by Fabio Fioretti - WindoM
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Per il Registry le transazioni tornano molto utili!
sì, concordo. Ma allora forse il problema sta anche nel registry se devi
inserire un layer in più per evitare di corromperlo.
Mah, il Registry è un database gerarchico senza il concetto di
transazione... forse avrebbero dovuto pensarlo transazionale dall'inizio, ma
all'epoca...
io penso che molti programmi ne abbiano abusato.
Post by Fabio Fioretti - WindoM
Post by Ottavio Campana
Tanti piccoli file saranno meno belli, ma hanno il vantaggio della
diversità, e spalmi le possibili rogne su tanti file.
Con alcuni svantaggi però, tant'è vero che qualcuno, da qualche anno a
questa parte, scopiazza l'idea del Registry (chi ha detto GNOME? :-P).
sì, però il registro di gnome non è un unico file. e non ha problemi per
sputtanamenti. O meglio, io una volta l'ho sputtanato, stavo
programmando una applet gnome e ho fatto un casino infinito perché non
sapevo quello che stavo facendo.... ma se uno fa rm -rf / non è colpa
del sistema operativo....
Fabio Fioretti - WindoM
2007-05-31 21:16:37 UTC
Permalink
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
La garanzia no, la possibilità si!
ok. Per me questo *non* è sufficiente.
Allora dimmi, cosa ti dà la garanzia? Il backup non te la dà perché perdi
una fetta di dati. Fsck non te la dà perché non funziona sempre come
dovrebbe. Self-Healing non ti ispira fiducia. La cosa più vicina alla
garanzia che cerchi è usare tutti e tre i sistemi in contemporanea (ripeto:
cipolla!).
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
"Preserves data. Self-healing NTFS preserves as much data as possible,
based on the type of corruption detected."
Spero che in futuro esca qualche documento più dettagliato in merito.
nell'altro documento dicono
| "So if there's a corruption detected someplace in the data structure,
| an NTFS worker thread is spawned," Russinovich explained
lui parla di strutture dati, non dati.
Occhio però, data structure != metadata structure. Bisognerebbe
contestualizzare la frase.

Detto questo, mi fido più della documentazione ufficiale che delle
chiacchiere di Russinovich raccontate da BetaNews.
Post by Ottavio Campana
Anche fosse però sui dati,
avviano il thread e non possono garantirti nulla. Se i file sono stati
sovrascritti?
Non lo so, spero escano altri succosi dettagli sul funzionamento effettivo.
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Avevo già capito questa tua osservazione, ma guardala dal punto di vista
dei dati (in fin dei conti è di quelli che ti preoccupi, no?): non
importa se
l'applicazione è bacata, se il layer RAID sta impazzendo o se cade un
segmento di rete, voglio che i dati restino consistenti. Un comportamento
transazionale del file system può essere di grosso aiuto. Dal punto di
vista dell'applicazione non cambia niente, se fallisce la write o
fallisce la
transazione è la stessa cosa; per i dati c'è una bella differenza.
ok, però cosa succede se invece la transazione ha successo ma i dati
sono sbagliati?
Cioè il programma ha scritto dati sbagliati? Te li tieni così, ma è tutto un
altro paio di maniche. Ci servirebbe il file system semantico per rilevare
errori del genere. :-)
Post by Ottavio Campana
se vuoi investrie un po' di tempo su www.lustre.org ci sono degli
articoli che ne parlano.
Studierò, grazie.
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Mah, il Registry è un database gerarchico senza il concetto di
transazione... forse avrebbero dovuto pensarlo transazionale dall'inizio,
ma all'epoca...
io penso che molti programmi ne abbiano abusato.
Sicuramente si.
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Con alcuni svantaggi però, tant'è vero che qualcuno, da qualche anno a
questa parte, scopiazza l'idea del Registry (chi ha detto GNOME? :-P).
sì, però il registro di gnome non è un unico file.
Neanche il Registry è un unico file.
Post by Ottavio Campana
e non ha problemi per
sputtanamenti.
Considera che il 99,99% dei problemi del Registry di Windows dipendono da
applicazioni scritte in modo orripilante. Il registro di GNOME soffre e
soffrirà degli stessi problemi, se proseguirà su quella strada insanguinata.
Post by Ottavio Campana
O meglio, io una volta l'ho sputtanato, stavo
programmando una applet gnome e ho fatto un casino infinito perché non
sapevo quello che stavo facendo.... ma se uno fa rm -rf / non è colpa
del sistema operativo....
Non sono d'accordo, il sistema operativo non dovrebbe permettere alle
applicazioni di minare la propria consistenza o quella di sue componenti
chiave come il Registry.


SALUTONI,

WindoM
Ottavio Campana
2007-06-01 02:39:38 UTC
Permalink
Post by Fabio Fioretti - WindoM
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
La garanzia no, la possibilità si!
ok. Per me questo *non* è sufficiente.
Allora dimmi, cosa ti dà la garanzia? Il backup non te la dà perché perdi
una fetta di dati. Fsck non te la dà perché non funziona sempre come
dovrebbe. Self-Healing non ti ispira fiducia. La cosa più vicina alla
cipolla!).
il backup mi da la garanzia dei dati fino alla momento del backup.
Post by Fabio Fioretti - WindoM
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
"Preserves data. Self-healing NTFS preserves as much data as possible,
based on the type of corruption detected."
Spero che in futuro esca qualche documento più dettagliato in merito.
nell'altro documento dicono
| "So if there's a corruption detected someplace in the data structure,
| an NTFS worker thread is spawned," Russinovich explained
lui parla di strutture dati, non dati.
Occhio però, data structure != metadata structure. Bisognerebbe
contestualizzare la frase.
lo concedo
Post by Fabio Fioretti - WindoM
Considera che il 99,99% dei problemi del Registry di Windows dipendono da
applicazioni scritte in modo orripilante. Il registro di GNOME soffre e
soffrirà degli stessi problemi, se proseguirà su quella strada insanguinata.
mettiamola così: però ora il registro di gnome non ha tutte quelle
chiavi come il registro di win.
Post by Fabio Fioretti - WindoM
Post by Ottavio Campana
O meglio, io una volta l'ho sputtanato, stavo
programmando una applet gnome e ho fatto un casino infinito perché non
sapevo quello che stavo facendo.... ma se uno fa rm -rf / non è colpa
del sistema operativo....
Non sono d'accordo, il sistema operativo non dovrebbe permettere alle
applicazioni di minare la propria consistenza o quella di sue componenti
chiave come il Registry.
bah, dipende.... Imho è in linea con la teoria dell'evoluzione
darwiniana :-)

E poi la potenza di unix si vede anche dal fatto che con 7 carattere
puoi fottere tutto, ma proprio tutto il sistema. :-)
Vax Headroom
2007-06-01 14:05:19 UTC
Permalink
Interfacciandosi alla mia unita' neurale, Fabio Fioretti - WindoM disse:

[cut]
Post by Fabio Fioretti - WindoM
Non sono d'accordo, il sistema operativo non dovrebbe permettere alle
applicazioni di minare la propria consistenza o quella di sue componenti
chiave come il Registry.
Mi permetto di obiettare: il sistema operativo deve OBBEDIRE, se poi io
sono matto o sbadato sono solo cazzi miei !!! Nel primo caso saró (sarei)
licenziato, nel secondo impareró a tenere a bada i ditini ed a pensare una
volta di piú prima di agire !!!

Saluti
--
| Almeno tu che puoi fuggi via canto
\|/ ____ \|/ \ ||_| | nomade questa cella e` piena della
"@'/ ,. \`@" \|| | | mia disperazione tu che puoi non
/_| \__/ |_\ Vax Headroom | farti prendere.
\__U_/ | BMS
Di passaggio a nord ovest
2007-06-04 19:41:21 UTC
Permalink
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Non hai capito: puoi anche teletrasportare tutti i dati dal backup al
sistema in tre nanosecondi, ci avrai sempre messo più tempo che se non
avessi avuto la necessità di fare il ripristino.
non hai capito tu: il self healing non ti dà la garanzia di poterlo evitare.
La garanzia no, la possibilità si!
ok. Per me questo *non* è sufficiente.
Partito preso?
Ottavio Campana
2007-06-04 21:33:27 UTC
Permalink
Post by Di passaggio a nord ovest
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Non hai capito: puoi anche teletrasportare tutti i dati dal backup al
sistema in tre nanosecondi, ci avrai sempre messo più tempo che se non
avessi avuto la necessità di fare il ripristino.
non hai capito tu: il self healing non ti dà la garanzia di poterlo evitare.
La garanzia no, la possibilità si!
ok. Per me questo *non* è sufficiente.
Partito preso?
no, serietà. Ed è indipendente dal sistema operativo.
Di passaggio a nord ovest
2007-06-04 21:39:57 UTC
Permalink
Post by Ottavio Campana
Post by Di passaggio a nord ovest
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Post by Ottavio Campana
Post by Fabio Fioretti - WindoM
Non hai capito: puoi anche teletrasportare tutti i dati dal backup al
sistema in tre nanosecondi, ci avrai sempre messo più tempo che se non
avessi avuto la necessità di fare il ripristino.
non hai capito tu: il self healing non ti dà la garanzia di poterlo evitare.
La garanzia no, la possibilità si!
ok. Per me questo *non* è sufficiente.
Partito preso?
no, serietà. Ed è indipendente dal sistema operativo.
Eh magari vivessimo in un mondo deterministico ;_)

Rossano Orlandini
2007-05-29 06:55:45 UTC
Permalink
On Tue, 29 May 2007 02:33:32 +0200, "Fabio Fioretti - WindoM"
Post by Fabio Fioretti - WindoM
http://www.betanews.com/article/Top_10_New_Features_in_Windows_Server_2008/1180045346
#10: The self-healing NTFS file system.
#9: Parallel session creation.
#8: Clean service shutdown.
#7: Kernel Transaction Manager.
#6: SMB2 network file system.
#5: Address Space Load Randomization (ASLR).
#4: Windows Hardware Error Architecture (WHEA).
#3: Windows Server Virtualization.
#2: PowerShell.
#1: Server Core.
Calcolando che di cose nuove Windows Server 2008 ne apporta almeno il
triplo.
--
Rossano Orlandini
Fabio Fioretti - WindoM
2007-05-29 13:30:25 UTC
Permalink
Post by Rossano Orlandini
Calcolando che di cose nuove Windows Server 2008 ne apporta almeno il
triplo.
Sentiti libero di aggiungere nuovi elementi alla lista di BetaNews.


SALUTONI,

WindoM
Rossano Orlandini
2007-05-29 18:54:38 UTC
Permalink
On Tue, 29 May 2007 15:30:25 +0200, "Fabio Fioretti - WindoM"
Post by Fabio Fioretti - WindoM
Post by Rossano Orlandini
Calcolando che di cose nuove Windows Server 2008 ne apporta almeno il
triplo.
Sentiti libero di aggiungere nuovi elementi alla lista di BetaNews.
Miglioramenti all'Active Directory (Auditing, Password Policies, nuove
GPO, Read-Only Domain Controllers, Restartable Domain Services, Snapshot
viewer), miglioramenti ai Federation Services e Rights Management
Services, nuovo backup, miglioramenti ai terminal Services con nuove
funzionalità, funzionalità di NAP (Network Access Policy), nuovo web
server (IIS 7), nuovi Sharepoint Services, miglioramenti al Clustering,
miglioramenti all'intero stack TCP/IP, crittografia dei drive con
BitLocker
--
Rossano Orlandini
dalai lamah
2007-05-29 11:24:07 UTC
Permalink
Post by Fabio Fioretti - WindoM
#10: The self-healing NTFS file system.
Io credevo che un journaling file system dovesse essere self-healing by
design, ma evidentemente mi sbagliavo.
--
emboliaschizoide.splinder.com
Fabio Fioretti - WindoM
2007-05-29 13:42:17 UTC
Permalink
Post by dalai lamah
Post by Fabio Fioretti - WindoM
#10: The self-healing NTFS file system.
Io credevo che un journaling file system dovesse essere self-healing by
design, ma evidentemente mi sbagliavo.
Si e no... il journaling serve principalmente ad evitare lunghi check
offline su tutto il file system, con relativo fermo macchina, ma da solo
(soprattutto se limitato ai soli metadati) non garantisce contro la perdita
di dati, pur limitandone la magnitudine.


SALUTONI,

WindoM
Ottavio Campana
2007-05-29 15:34:07 UTC
Permalink
Post by Fabio Fioretti - WindoM
Si e no... il journaling serve principalmente ad evitare lunghi check
offline su tutto il file system, con relativo fermo macchina, ma da solo
(soprattutto se limitato ai soli metadati) non garantisce contro la perdita
di dati, pur limitandone la magnitudine.
ma nell'articolo non parlano del flush dei dati veri e propri, loro
parlano delle strutture dati di ntfs. Poi a dire il vero l'ho letto di
fretta, però mi sembrava così...
dalai lamah
2007-05-29 17:27:30 UTC
Permalink
Post by Fabio Fioretti - WindoM
Post by dalai lamah
Post by Fabio Fioretti - WindoM
#10: The self-healing NTFS file system.
Io credevo che un journaling file system dovesse essere self-healing by
design, ma evidentemente mi sbagliavo.
Si e no... il journaling serve principalmente ad evitare lunghi check
offline su tutto il file system, con relativo fermo macchina
E non è questa l'essenza del 'self-healing'? Il senso dei jfs è appunto
quello di rimanere consistenti in ogni caso. Non capisco cosa abbiano
aggiunto all'NTFS che non avesse già di suo.
Post by Fabio Fioretti - WindoM
ma da solo
(soprattutto se limitato ai soli metadati) non garantisce contro la perdita
di dati, pur limitandone la magnitudine.
Questo è ovvio, nessun file system può garantire contro la perdita dei
dati: se il crash avviene prima che i dati siano scritti, non importa
quanto fault-tolerant sia il tuo file system, li hai persi comunque.
--
emboliaschizoide.splinder.com
Rossano Orlandini
2007-05-29 18:54:45 UTC
Permalink
Post by dalai lamah
Post by Fabio Fioretti - WindoM
Post by dalai lamah
Post by Fabio Fioretti - WindoM
#10: The self-healing NTFS file system.
Io credevo che un journaling file system dovesse essere self-healing by
design, ma evidentemente mi sbagliavo.
Si e no... il journaling serve principalmente ad evitare lunghi check
offline su tutto il file system, con relativo fermo macchina
E non è questa l'essenza del 'self-healing'? Il senso dei jfs è appunto
quello di rimanere consistenti in ogni caso. Non capisco cosa abbiano
aggiunto all'NTFS che non avesse già di suo.
Rif:
Self-healing NTFS attempts to correct corruptions of the NTFS file
system online, without requiring Chkdsk.exe to be run. The enhancements
to the NTFS kernel code base help to correct disk inconsistencies and
allow this feature to function without negative impacts to the system.
--
Rossano Orlandini
unknown
2007-05-30 09:35:27 UTC
Permalink
Post by dalai lamah
E non è questa l'essenza del 'self-healing'? Il senso dei jfs è appunto
quello di rimanere consistenti in ogni caso. Non capisco cosa abbiano
aggiunto all'NTFS che non avesse già di suo.
La consistenza del FS non implica la non perdita di dati pero`, o la
correzione di errori. Implica il ritorno ad uno stato leggibile e
valido in (quasi) ogni situazione.
--
Sensei <senseiwa at Apple's mac dot com>

$ cd /pub
$ more beer
Fabio Fioretti - WindoM
2007-05-30 11:05:40 UTC
Permalink
Post by dalai lamah
Post by Fabio Fioretti - WindoM
Si e no... il journaling serve principalmente ad evitare lunghi check
offline su tutto il file system, con relativo fermo macchina
E non è questa l'essenza del 'self-healing'? Il senso dei jfs è appunto
quello di rimanere consistenti in ogni caso. Non capisco cosa abbiano
aggiunto all'NTFS che non avesse già di suo.
Hanno aggiunto la capacità di controllare e mantenere la consistenza online,
senza bisogno di smontare il volume.


SALUTONI,

WindoM
dalai lamah
2007-05-30 18:15:21 UTC
Permalink
Post by Fabio Fioretti - WindoM
Hanno aggiunto la capacità di controllare e mantenere la consistenza online,
senza bisogno di smontare il volume.
Un file system journaled dovrebbe mantenere *sempre* la consistenza, non
dovrebbe esserci nulla da controllare o smontare. Tutte le operazioni di
scrittura sono eseguite con transazioni che possono essere considerate
atomiche, come in un DBMS. E' proprio questa la differenza fra i journaled
filesystem e i filesystem che richiedono un check.

In tanti anni che uso NTFS non credo di ricordare una singola volta in cui
ho visto partire dei check all'avvio, se escludo un paio di casi
"catastrofici" (RAM e CPU difettose) che non possono essere imputati
all'OS: se è l'hardware stesso che gli passa delle informazioni errate, c'è
poco da fare.
--
emboliaschizoide.splinder.com
Fabio Fioretti - WindoM
2007-05-30 19:09:50 UTC
Permalink
Post by dalai lamah
Post by Fabio Fioretti - WindoM
Hanno aggiunto la capacità di controllare e mantenere la consistenza
online, senza bisogno di smontare il volume.
Un file system journaled dovrebbe mantenere *sempre* la consistenza, non
dovrebbe esserci nulla da controllare o smontare.
Teoricamente si, nella pratica purtroppo non è così. Al di là di bug del
file system stesso, che chiaramente trarrebbero in inganno anche il
journaling, ci sono layer al di sotto del file system (per esempio RAID) che
possono introdurre errori, con o senza la complicità dell'harware. Molti di
questi errori, se non critici, possono essere risolti online da self-healing
NTFS.

Qualche info in più:
http://technet2.microsoft.com/windowsserver2008/en/library/6f883d0d-3668-4e15-b7ad-4df0f6e6805d1033.mspx?mfr=true

Cerca con Google in merito a corruzioni di file system journaled, troverai
cupe testimonianze. :-)
Post by dalai lamah
Tutte le operazioni di
scrittura sono eseguite con transazioni che possono essere considerate
atomiche, come in un DBMS. E' proprio questa la differenza fra i journaled
filesystem e i filesystem che richiedono un check.
Occhio che anche i journaled file system richiedono un check, spesso
offline; il vantaggio è che è molto più rapido rispetto a quello dei file
system tradizionali.
Post by dalai lamah
In tanti anni che uso NTFS non credo di ricordare una singola volta in cui
ho visto partire dei check all'avvio, se escludo un paio di casi
"catastrofici" (RAM e CPU difettose) che non possono essere imputati
all'OS
Lo stesso vale per me.


SALUTONI,

WindoM
Continua a leggere su narkive:
Loading...