NTFS e differenze di prestazioni rispetto ad altri file system

[feyd]

Ciao,
prima che prendiate questo post come un flame sappiate che
- ho comunque un po' di esperienza con i sistemi operativi
- in ufficio uso con estrema soddisfazione linux
- a casa uso in maniera altrettanto soddisfacente vista business
- mi capita sovente di mettere le mani sul mac (ed a breve probabilmente ne comprero' uno)

volevo avere un parere sensato sul fs di windows NTFS (e qui scatta il potenziale flame ).

per mia esperienza le sue prestazioni sono veramente uno schifo. Vi sottopongo questo test:
Per lavoro sviluppo in java. La compilazione della mia applicazione (estremamente complessa) gira sui 3 sistemi operativi.
Ha una parte CPU intensive e diverse parti FS intensive.
L'esito (+o- costante e' il seguente)
---------------------------------------------------------------
Hp Dv3650 8600@2.4GHz 4GB DDR2 HD 320GB@5400rpm

Windows Vista Home Premium (sistema operativo pulito, cioe' fornito col pc rimossi diversi applicativi memory resident, no antivirus) ---> 138 secondi per l'intero processo.

Linux Ubuntu 8.10 kernel aggiornato e FS ext3 --> 20 secondi!!!!! (cioe' 7 volte piu' veloce!)
(sullo stesso PC)

--------------------------
Mac Book 13.3" 2.0GHz 2GB DDR3 250GB@5400rpm
OSX 10.5.7 --> 40 secondi (cioe' il doppio di linux su una CPU + potente ma comunque 100 secondi in meno di Windows!!!).

Considerate che:
- l'esito finale e' il metesimo
- il jdk ufficiale sun sotto linux gira circa dal 30% al 50% + veloce che su windows.
- mac usa un jdk scaricato dal repository apple e buildato da apple ma comqune certificato.
Dai miei test e' evidente un divario CLAMOROSO nella velocita del fs.

La Microsoft rimpiazzera' mai quel cesso di FS?

ciao feyd

[LeaderGL2]

La tua applicazione legge, scrive, o legge e scrive files sul disco?

In che modo leggi e/o scrivi questi file? Quanti KB per volta fai leggere e/o scrivere?

[Khronos]

io ho notato una semplice cosa. Le API di browsing file system M$ hanno una lentezza abbastanza esasperante quando devono locare, aprire, chiudere e passare ad altri file DOVE questi file risiedono in varie cartelle/sottocartelle annidate, e siano parecchi file molto piccoli.
ciò non sembra verificarsi se, ad esempio, l'API che usa NTFS è NTFS-3g (è molto più veloce a far copie di file piccoli sotto linux anche in quel file system).
non è colpa del file system, secondo me. è la programmazione del layer sopra. alla fine la velocità del disco fisso è sempre quella, e il file system è solo una sorta di cassetto. invece di cambiar cassetto, vediamo di metter a posto le mani che ci frugano dentro.

[feyd]

Originariamente inviato da LeaderGL2

La tua applicazione legge, scrive, o legge e scrive files sul disco?

In che modo leggi e/o scrivi questi file? Quanti KB per volta fai leggere e/o scrivere?

Leggo diverse centinaia di files via java. questi poi a loro volta producono altri file. Le dimensioni girano da 1K a 10K per cui nulla di significativo.

I files poi vengono compilati (via ant) e spostati via (via batch files sotto win e shell scripts sotto linux/mac)

I rallentamenti palesemente misurabili sono nello spostamento dei files (e quindi script di sistema operativo).
Questo mi fa tagliare fuori l'ipotesi, abbastanza infondata peraltro che sia il diverso jdk.

[feyd]

Originariamente inviato da Khronos

io ho notato una semplice cosa. Le API di browsing file system M$ hanno una lentezza abbastanza esasperante quando devono locare, aprire, chiudere e passare ad altri file DOVE questi file risiedono in varie cartelle/sottocartelle annidate, e siano parecchi file molto piccoli.
ciò non sembra verificarsi se, ad esempio, l'API che usa NTFS è NTFS-3g (è molto più veloce a far copie di file piccoli sotto linux anche in quel file system).
non è colpa del file system, secondo me. è la programmazione del layer sopra. alla fine la velocità del disco fisso è sempre quella, e il file system è solo una sorta di cassetto. invece di cambiar cassetto, vediamo di metter a posto le mani che ci frugano dentro.

Non programmo con le API M$ ma come gia' detto nella risposta precedente i rallentamenti sono ben visibili sugli script batch.

Aggiungo che anche l'io comunque e' piu' lento in maniera misurabile.

Come anche tu rilevi la velocita' del disco e' sempre quella.
Nei miei script uso direttamente batch e shell per cui la sola differenza e' imputabile sia alle api di accesso del FS (stiamo comunque parlando del kernel per cui dal mio punto di vista queste api sono parte integrante del FS visto che un FS in cui non puoi leggere e scrivere serve a ben poco) ma anche all'architettura del FS che risulta in prestazioni non piu' al passo con la concorrenza (il divario su linux e' clamoroso)

Considera inotlre che ext4 (che secondo me e' ad oggi inadatto ai desktop per gli eccessivi rischi in caso di crash) pare essere molto piu' efficiente di ext3 (ma non l'ho testato).

ext3 mi sembra inoltre piu' veloce in generale pero' non ho mai misurato nulla per cui e' un discorso soggettivo che lascerei fuori

[Khronos]

tanto per dirne una.
NTFS è rimasto invariato per 9 anni.
EXT ha avuto una versione ogni quanto? EXT4 è appena uscito... mi pare abbastanza normale un'incremento di prestazioni.

[LeaderGL2]

Originariamente inviato da Khronos

tanto per dirne una.
NTFS è rimasto invariato per 9 anni.
EXT ha avuto una versione ogni quanto? EXT4 è appena uscito... mi pare abbastanza normale un'incremento di prestazioni.

beh questo non è propriamente vero, dato che NTFS ha subito evoluzioni durante il suo arco di vita che a noi sono arrivate per mezzo dei vari sistemi operativi.

XP aveva una versione nuova di NTFS, vista ha ancora una nuova versione di NTFS, non so Windows 7; ma il fatto che si chiami solo NTFS significa poco..al momento credo siamo alla "versione 6.0".


-------- EDIT --------
Fonte: Wikipedia inglese

NTFS has five released versions:

* v1.0 with NT 3.1,[citation needed] released mid-1993
* v1.1 with NT 3.5,[citation needed] released fall 1994
* v1.2 written by NT 3.51 (mid-1995) and NT 4 (mid-1996) (occasionally referred to as "NTFS 4.0", because OS version is 4.0)
* v3.0 from Windows 2000 ("NTFS V5.0")
* v3.1 from Windows XP (autumn 2001; "NTFS V5.1"), Windows Server 2003 (spring 2003; occasionally "NTFS V5.2"), Windows Vista (mid-2005) (occasionally "NTFS V6.0") and Windows Server 2008

V1.0 and V1.1 (and newer) are incompatible: that is, volumes written by NT 3.5x cannot be read by NT 3.1 until an update on the NT 3.5x CD is applied to NT 3.1, which also adds FAT long file name support.[6] V1.2 supports compressed files, named streams, ACL-based security, etc.[1] V3.0 added disk quotas, encryption, sparse files, reparse points, update sequence number (USN) journaling, the $Extend folder and its files, and reorganized security descriptors so that multiple files which use the same security setting can share the same descriptor.[1] V3.1 expanded the Master File Table (MFT) entries with redundant MFT record number (useful for recovering damaged MFT files).

Windows Vista introduced Transactional NTFS, NTFS symbolic links, partition shrinking and self-healing functionality[7] though these features owe more to additional functionality of the operating system than the file system itself.

[hexaae]

@feyd
Anche dando per probabile che l'NTFS non dia grandi prestazioni non sono sicuro che il test che hai eseguito possa essere una cartina tornasole del FS... Potrebbe dipendere da mille altre cose come i driver, la gestione della rete (se i file sono in rete) e la programmazione della jdk che invece dai per scontata...
Per farti un parallelo... hai mai visto come gira iTunes sul Mac e su Windows? Un'altro mondo anche quello. Sarà un caso poi che Sun è più orientata al mondo Unix e essa stessa ha il suo OpenSolaris (per dire), e Apple il suo MacOS per cui ad essere maliziosi si potrebbe pensare che lo facciano apposta a non ottimizzare nulla per Win?

EDIT:
Certo che se aggiungi anche questo

I files poi vengono compilati (via ant) e spostati via (via batch files sotto win e shell scripts sotto linux/mac)

I rallentamenti palesemente misurabili sono nello spostamento dei files (e quindi script di sistema operativo).

in effetti... Però la differenza da te riscontrata mi pare davvero esagerata. Sarei curioso anch'io di trovare un valido sistema di benchmarking per i FS...
Un'idea potrebbe essere di provare anche su chiavetta USB da Windows, una volta in NTFS e l'altra in FAT32 o ExFAT...

[hexaae]

NTFS su Technet: http://technet.microsoft.com/en-us/l.../cc767961.aspx

[ezio]

Non ho conoscenze tecniche relative alla programmazione in java e non esprimo considerazioni in merito, però credo che le differenze di prestazioni da te riscontrate non possano rappresentare un fattore di misurazione corretto, proprio perchè si tratta di un singolo applicativo (non escludendo che NTFS possa essere realmente meno veloce di ext3 e altri).

Comunque discussione interessante, vi seguo
Titolo modificato.

[hexaae]

Nel frattempo ho trovato anche questo: http://www.fs-driver.org/index.html e quest'altro: http://www.ext2fsd.com/
Per montare gratuitamente partizioni EXT2 (e EXT3) in Windows (Vista supportato) e quindi leggere/scrivere in partizioni Linux con quel FS...

@Feyd
Prova a rieseguire il test dentro Windows ma su partizone EXT3...

Può essere interessante anche l'esperimento di spostare il file di page di Windows su partizione EXT2/3 e vedere se si hanno migliori prestazioni http://www.fs-driver.org/ScreenPagingFile.html

[Khronos]

uuu no no no non fare niente del genere, un mio amico all'uni ha bruciato 2 partizioni ext3 con quei bridge, ocio. è naturale che lo abbia tenuto come cavia, stavo per installare anchio quel coso.

[feyd]

Originariamente inviato da hexaae

@feyd
Anche dando per probabile che l'NTFS non dia grandi prestazioni non sono sicuro che il test che hai eseguito possa essere una cartina tornasole del FS... Potrebbe dipendere da mille altre cose come i driver, la gestione della rete (se i file sono in rete) e la programmazione della jdk che invece dai per scontata...
Per farti un parallelo... hai mai visto come gira iTunes sul Mac e su Windows? Un'altro mondo anche quello. Sarà un caso poi che Sun è più orientata al mondo Unix e essa stessa ha il suo OpenSolaris (per dire), e Apple il suo MacOS per cui ad essere maliziosi si potrebbe pensare che lo facciano apposta a non ottimizzare nulla per Win?

EDIT:
Certo che se aggiungi anche questo

in effetti... Però la differenza da te riscontrata mi pare davvero esagerata. Sarei curioso anch'io di trovare un valido sistema di benchmarking per i FS...
Un'idea potrebbe essere di provare anche su chiavetta USB da Windows, una volta in NTFS e l'altra in FAT32 o ExFAT...

Rispondo un po' a tutti ma principalmente a questo post che e' quello che fa meglio il punto della situazione.

Il mio test non e' un test preciso ma un de-facto di cosa comporta per me lavorare sotto linux o windows o osx.
Produco un'ear java di grosse dimensioni in maniera ingegnerizzata e la realta' e' che i tempi di questo processo sono enormente maggiori sotto windows.
Non ho parlato dei test del jdk volutamente. Quello sun e' stato testato ampiamente in ogni salsa proprio per tirare fuori numeri precisi... in estrema sintesi su linux si dimostra un 30, 50% piu' veloce: come qualcuno ha giustamente osservato la sun lavora meglio su sistemi *nix di quando non faccia con windows. Io ho tagliato fuori ongni ipotesi suila jvm e jdk perche' chiunque potrebbe trovarne test per dire tutto ed il contrario di tutto.

Cio non di meno qualche numero il mio processo di produzione dell'ear lo da anche a me il risultato e' che le grosse variazioni sono legate all'accesso sia per lettura, scrittura che spostamento.

Ho anche premesso che il sistema era cosi come fornito dalla casa salvo la rimozione di applicazioni del cavolo o servizi che non mi servono e consumano solo risorse (questo vale su entrambi i sistemi linux ed ubu 8.10 anche se linux di solito e' piu pulito di per se.

Non posso eseguire test di varia natura perche' quella e' la mia macchina da lavoro e dunque non posso rischiare nulla ne tantomeno perdere tempo invece di lavorare.

Questo test mi e' venuto gratis e la differenza in secondi finali per fare la stessa cosa eranro troppo eclatante per essere taciuta per cui mi e' sembrato carino proporvelo.

Qualcuno ha osservato che i FS linux si sono evoluti... vero!!!!... infatti il mio post si interrogava quando la Microsoft abbandonera' un carrozzone non al passo coi tempi o continuera' a farsi del male da sola.
Stesso discorso si potrebbe fare per le mfc che sono ormai alla canna del gas da tempo e ci vorrebbe un bel lavoro di reingegnerizzazione in una libreria NUOVA per applicativi NUOVI... la apple lo ha fatto e lo switch verso cocoa non lascia dubbi sulla validita' della scelta.

Vi assicuro che la prima volta che ho fatto girare gli script con successo sotto linux in una vmware sotto windows e la macchina virtuale ci ha messo 1/3 dello stesso pc host ho pensato che qualcosa non avesse funzionato e che avevo saltato dei passaggi perche' gli script bash erano rotti.
Solo il mettere l'ear sotto jboss, avviare il tutto e farmi un giro nell'applicativo con il debugger collegato mi ha convinto che invece tutto era andato alla perfezione!

feyd

[hexaae]

Come suggerivo, sarebbe a questo punto interessante rifare tutto da Windows ma su EXT2 ad esempio in una partizione di prova...
Se puoi fare questa prova fai sapere perché sarebbe la dimostrazione definitiva che il fs è il vero collo di bottiglia.
Sarebbe anche interessante il contrario: da Linux in una partizione NTFS...

P.S.:
Detto tra noi anch'io credo che l'NTFS 6.0 (se non sbaglio) sia un fs sicuro per molti aspetti e dalle buone funzionalità ma lento, però non ci sono mai stati benchmark seri per dimostrarlo...
Ho sempre trovato fastidioso il legame a doppio filo tra l'OS e l'fs con Windows che di fatto impedisce di adottare altri fs magari più performanti e sicuri.

[feyd]

Il legame OS/FS (evvai di sigle) purtroppo ce l'hai con tutte le soluzioni proprietarie (almeno in ambito desktop) visto che anche per apple e' lo stesso.

Con linux comunque ad oggi l'unica alternativa sensata in ambito desktop e' ext3 (onestamente con Hans Reiser in galera per il reiserfs io non vedo futuro) per cui di fatto il problema e' relativo.

Se ci riesco provo a far girare i test linux con ntfs via ntfs-3g ma non sono sicuro di aver disponibile una piattaforma per questo test.

[WarDuck]

Ma Vista è aggiornato a SP2 con tutte le ultime patch?

Cmq sarebbe interessante fare un test simile usando C# (e il corrispettivo mono su Linux).

NTFS 6.0 è molto evoluto in termini di features, e al contrario di quello che la gente pensa non si deframmenta molto rispetto ad altri file system (anche perché ad esempio ha gli Extents, che sono stati introdotti solo su ext4 insieme alla delayed allocation).

Tra l'altro come misuri le prestazioni dell'I/O?

[hexaae]

Originariamente inviato da feyd

Il legame OS/FS (evvai di sigle) purtroppo ce l'hai con tutte le soluzioni proprietarie (almeno in ambito desktop) visto che anche per apple e' lo stesso.

Esistono altri OS indipendenti ma proprietari e closed che cmq possono cambiare l'fs a piacimento come AmigaOS etc.

Se ci riesco provo a far girare i test linux con ntfs via ntfs-3g ma non sono sicuro di aver disponibile una piattaforma per questo test.

Fai sapere in caso...

[feyd]

Originariamente inviato da WarDuck

Ma Vista è aggiornato a SP2 con tutte le ultime patch?

Cmq sarebbe interessante fare un test simile usando C# (e il corrispettivo mono su Linux).

NTFS 6.0 è molto evoluto in termini di features, e al contrario di quello che la gente pensa non si deframmenta molto rispetto ad altri file system (anche perché ad esempio ha gli Extents, che sono stati introdotti solo su ext4 insieme alla delayed allocation).

Tra l'altro come misuri le prestazioni dell'I/O?

Tegno sempre vista aggiornatissimo, non appena windows update mi propone un'aggiornamento lo applico.

1) Purtroppo non sviluppo in C# per cui non posso essere di aiuto cmq non ritengo mono una soluzione valida per ambito produttivo per cui gia' questo (a me) basta per togliere ogni senso al test.

2) Infatti non ho nulla da ridire sulle features ma solo sulle prestazioni. ext4 e' inadeguato ad oggi in ambiti desktop per il rischio assurdamente alto di perdere dati in caso di crash dal mio punto di vista intollerabile.

3) Come gia' detto in non misuro in maniera sistematica l'I/O ma porto un caso reale. Il processo di build dell'ear si limita a prendere il (tempo finale - tempo iniziale) dei vari passi. Non mi interessano i millesimi di secondo ma un dato ben piu' grossolano... e un risultato eclatante come 138 sec contro 20 per fare la STESSA IDENTICA COSA non passa inosservato.

Ora se fossi un fanatico (niubbo) di linux verrei qui a menarla per il naso a tutti gli utenti windows ma in realta' sono anche un felice utilizzatore di windows e windows stravince in mille altri fronti (i giochi ad esempio).

La realta' pero' e' che nel mio caso la produttivita' sotto linux e' enormemente maggiore... questo mi da da pensare: perche' microsoft continua a menarsela per accelerare lo startup del pc (peraltro a me non e' che cambi la vita se all'avvio che faccio 1 volta al giorno ci mette 10 secondi o 1 minuto) e non innova veramente il sistema operativo reingegnerizzando fs e librerie (mfc su tutte)?
Questo mi ha fatto divagare troppo e sono completamente OT scusate.

feyd

[feyd]

Originariamente inviato da hexaae

Esistono altri OS indipendenti ma proprietari e closed che cmq possono cambiare l'fs a piacimento come AmigaOS etc.


Fai sapere in caso...

Non te la prendere (anche io ero amighista e l'ho ancora nel cuore) ma AmigaOS, BeOS o altro possono anche essere sistemi operativi ma utilizzarli in ambito produttivo mi sembra una utopia.

[hexaae]

Originariamente inviato da feyd

Non te la prendere (anche io ero amighista e l'ho ancora nel cuore) ma AmigaOS, BeOS o altro possono anche essere sistemi operativi ma utilizzarli in ambito produttivo mi sembra una utopia.

[OT]...solo perché manca certo software però, non perché non abbiano tecnicamente le carte in regola
L'Haiku (vedi firma) sta venendo su bene e appare decisamente migliore anche del caotico Linux, ma ci vorrano ancora alcuni anni... Sono sistemi 10 volte più leggeri in quanto a consumo di risorse (che a tanti piace siano minime... ma questa è un'altra storia che mette a confronto le 2 filosofie dello "sfrutto tutto ciò che il mondo moderno offre" o "mi mantengo al minimo, come era richiesto 10-20 anni fa perché l'HW costava tanto..." ) e reattività rispetto a distro Linux o Windows[/OT]