PDA

View Full Version : Microsoft inizia lo sviluppo di Windows Redstone


Redazione di Hardware Upg
13-10-2015, 13:01
Link alla notizia: http://www.hwupgrade.it/news/sistemi-operativi/microsoft-inizia-lo-sviluppo-di-windows-redstone_59165.html

La compagnia di Redmond sembra aver iniziato i lavori su Windows Redstone, con ingegneri e tecnici che hanno iniziato a stilare le prime righe di codice

Click sul link per visualizzare la notizia.

Riccardo82
13-10-2015, 13:17
domanda stupida?

sono a pagamento questi upgrade ??

adaant
13-10-2015, 13:19
Quante ere dobbiamo aspettare per avere un degno successore del ntfs? :D

inkpapercafe
13-10-2015, 13:55
Quanti trolls arriveranno adesso? Quanta gente ancora ripeterà sempre la stessa domanda a cui è stata data sempre la stessa risposta migliaia di volte?

SI. sono gratuiti. :D

Ma non c'era il tasto cerca un volta nel forum? Non esisteva Google? Misterio muy misterioso...

DanieleG
13-10-2015, 14:01
Quante ere dobbiamo aspettare per avere un degno successore del ntfs? :D

Cosa manca a ntfs? Perchè sto discorso si ripropone continuamente ma senza mai un fondamento solido...

FirePrince
13-10-2015, 14:13
NTFS fu pensato per hard disk meccanici quando gli SSD neanche esistevano; sicuramente manca molto per poterlo definire ideale in un'epoca in cui si assiste al progressivo rimpiazzo dei primi con i secondi.

Riccardo82
13-10-2015, 15:33
uè inkpapercafe non sono mica come te che sto qua tutto il giorno a leggere notizie di windows

ho fatto una domanda cortese e mi rispondi cortese.
Mi frega un cazzo dei troll di google e di tutte le cazzate che scrivi.

¿Entiende amigo?

SoulKeeper
13-10-2015, 15:35
NTFS fu pensato per hard disk meccanici quando gli SSD neanche esistevano; sicuramente manca molto per poterlo definire ideale in un'epoca in cui si assiste al progressivo rimpiazzo dei primi con i secondi.

partendo dal presupposto che sto chiedo informazioni:

cosa centra ssd o meccanici?
puoi aumentare il numero di caratteri, la dimensione massima file, la gestione dei metadati, journaling, o l'allocazione file e deframmentazione che a questo punto non è più un problema visto parliamo di ssd (quindi un vantaggio)

https://en.wikipedia.org/wiki/Comparison_of_file_systems

se arriverà una risposta che mi faccia capire ringrazio in anticipo.

!fazz
13-10-2015, 16:28
uè inkpapercafe non sono mica come te che sto qua tutto il giorno a leggere notizie di windows

ho fatto una domanda cortese e mi rispondi cortese.
Mi frega un cazzo dei troll di google e di tutte le cazzate che scrivi.

¿Entiende amigo?

Entendí muy bien, dos semanas de vacaciones

bobafetthotmail
13-10-2015, 17:46
cosa centra ssd o meccanici? Che un SSD ha già implementato il grosso della roba che avrebbe dovuto implementare il file system (NTFS o altro) utilizzando un controller relativamente potente e un firmware più o meno merdacchioso (ricordo i casini di certi SSD Samsung).

Gli SSD gestiscono autonomamente wear leveling, garbage collection, compressione dei dati per occupare meno spazio fisico, algoritmi di predizione varia per il caching nella loro cache interna, integrità dei dati scritti, eccetera.

L'OS vede una astrazione, quello che il firmware gli fa vedere.

Anche per i dischi meccanici vale la stessa cosa (per quanto facciano molto meno comunque, tipo tutto il wear leveling/garbage collection serve a nulla), ma avendo limitazioni grosse per altri versi, anche ottimizzando meglio questa roba non cambia un granchè.

Per gli SSD invece potrebbe valere la pena avere degli SSD con un controller minimo dove tutte quelle funzioni di cui sopra sono gestite direttamente da un driver e quindi dalla CPU/OS del PC/Server.
http://www.linuxplumbersconf.org/2014/ocw/sessions/2079
Qui delle slides. http://events.linuxfoundation.org/sites/events/files/slides/LightNVM-Vault2015.pdf

Ma si parla di server. Mercato consumer già andare oltre gli SSD sata3 non ha senso, quindi è bello parlarne ma nulla più.


Uno si chiede, ma che c'entra un driver per usare un SSD con un filesystem? Beh, il grosso delle features nuove di NTFS sono aggiunte dal driver, non dal filesystem in sè. Quindi sempre di driver si parla.
Ad esempio il data deduplication (vedi sotto) è implementato nel driver NTFS di Windows server e basta.

Cosa manca a ntfs? Perchè sto discorso si ripropone continuamente ma senza mai un fondamento solido...
-Atomic COW snapshots (capacità di fare uno snapshot del disco nello stesso identico stato in cui si trova anche se sta scrivendo, questo snapshot occupa lo stesso spazio che occupano i dati cambiati. Cioè se dopo lo snapshot aggiungo 50 MB di files, su disco ho una immagine disco completa + i miei dati e quei 50 MB in più. Questo è a mezza via tra una immagine disco e un System Restore di Windows, solo che se ripristino uno snapshot io sto facendo un restore di una immagine disco che quindi va sempre se il disco non è danneggiato, mentre un punto di ripristino di Win magari fallisce e poi bestemmio)
-Per-block checksumming (capacità di controllare l'integrità dei dati, per beccare e correggere file corrotti da bit-rot ed errori hardware. Considerando che sempre più roba è stoccata a livello digitale, questo inizia ad essere un problema. Il livello del controllo è fatto più basso possibile, non per ogni file ma per ogni blocco del file-system, quindi correggere eventuali errori è veloce e viene fatto mentre legge i file)
-Self-healing redundant arrays (capacità di gestire raid software in modo molto più flessibile e sicuro di una scheda raid convenzionale)
-Volume management (tipo gestione delle partizioni di un disco, ma senza perdere tempo a cambiare dimensioni di una partizione e puoi farlo anche live, senza dover riavviare.
-Asynchronous incremental replication (quando mandi un backup dell'immagine disco creata precedentemente e la mandi al tuo NAS o server, il sistema gestisce automaticamente quali parti mandare e quali no.
Se sul sistema bersaglio mancano chessò 200 MB ma il resto dei dati li ha già, ad esempio se è un backup incrementale quindi sul sistema bersaglio ho già varie altre immagini disco, con la AIR solo quei 200 MB di dati nuovi viaggiano, non X TB di backup completo del disco.
-Data Deduplication (rimappare copie dello stesso file/blocco su un file/blocco per risparmiare spazio. Se copiate 50 volte lo stesso file e poi lanciate un data deduplication, lo spazio occupato da quei 50 file diventa lo stesso spazio occupato da uno solo. Molto utile se avete una valanga di macchine virtuali dello stesso OS con poche differenze tra loro, o molti file con parti in comune)
-Compressione decente dei dati (comprime i dati su disco con un rapporto di compressione che rende la compressione interessante da usare, e lo fa senza incastrare altra roba)


MS ha un suo pretendente come Next Generation File System, ma è tuttora in sviluppo.

Gli altri file system che offrono questa roba sono ZFS, e btrfs (che per ora non gestisce RAID5 e 6 ma è in sviluppo al soldo di Facebook)

Fonte:
http://arstechnica.com/information-technology/2014/01/bitrot-and-atomic-cows-inside-next-gen-filesystems/2/

Ah, se a leggere questa roba pensate "e chissenefrega", avete la risposta al perchè MS ha lasciato il NTFS.

Sistemisti e admin ci sbavano su sta roba, l'utente consumer.... no. :D

Marco71
13-10-2015, 19:56
...ci "sbavano" anche i power user a metà strada tra il cosiddetto "consumer" ed i sistem administrators.
NTFS è ormai con molti anni alle spalle...

Marco71.

Rubberick
13-10-2015, 21:51
Beh la deduplication sarebbe una manna, ma poi come fanno a vendere gli hd ai niubbi? :sofico:

rockroll
14-10-2015, 00:11
Beh la deduplication sarebbe una manna, ma poi come fanno a vendere gli hd ai niubbi? :sofico:

Questa della mancata deduplication mi è nuova: se riscrivo lo stessso file, non recupera lo spazio, quindi alla fine mi potrebe dire che il disco è pieno anche se è quasi vuoto? E se prima deleto poi scrivo, che dovrebbe essere equivalente...
Complimenti NTFS. Altra perla da aggiungere alle cavolate che M$ non correggerà mai (però per arzigogolare su implementazioni praticamente inutili per non dire ostili che nessuno le ha chiesto e di cui nessuno sente il bisogno il tempo lo trova eccome).

the_joe
14-10-2015, 06:03
Questa della mancata deduplication mi è nuova: se riscrivo lo stessso file, non recupera lo spazio, quindi alla fine mi potrebe dire che il disco è pieno anche se è quasi vuoto? E se prima deleto poi scrivo, che dovrebbe essere equivalente...
Complimenti NTFS. Altra perla da aggiungere alle cavolate che M$ non correggerà mai (però per arzigogolare su implementazioni praticamente inutili per non dire ostili che nessuno le ha chiesto e di cui nessuno sente il bisogno il tempo lo trova eccome).

http://www.techrepublic.com/blog/10-things/10-things-you-should-know-about-data-deduplication/

Complimenti rockroll direi per la continua disinformazione.

Se copi lo stesso file in posti diversi il data deduplication può aiutare perché in evita al costo di utilizzare la cpu per i calcoli di copiare gli stessi dati, nel caso che riscrivi più volte lo stesso file nel solito posto non ci sono problemi, inoltre come ha già scritto bob..... è utile soprattutto nel caso si faccia uso di diverse virtual machine, perché per altri tipi di file tipo la musica o le foto o i video dove i dati sono già "compressi" l'utilità è scarsa/nulla.

bobafetthotmail
14-10-2015, 09:10
Questa della mancata deduplication mi è nuova: se riscrivo lo stessso file, non recupera lo spazio, quindi alla fine mi potrebe dire che il disco è pieno anche se è quasi vuoto?Se il file system non ha la deduplication, ogni file viene gestito come una cosa a sè, quindi una copia di un file occupa lo stesso spazio su disco che il file originale.

Non è che il disco è "quasi vuoto", il disco è pieno di copie dello stesso identico file.

I file system di nuova generazione gestiscono la deduplicazione comunque non a livello di file ma di blocco di dati, ogni file viene scritto come tanti blocchi di dati in un file system.

Questo gli permette di fare deduplication anche su file completamente diversi, visto che dove trovano 2 o più blocchi di dati uguali (magari corrispondenti a parti diverse del file, chissenefrega), rimappano tutto su 1 blocco fisico sul disco e gli altri li tolgono.

Oppure se abbiamo un file grosso formato da sequenze ripetute. Ogni volta che lo stesso file presenta la stessa sequenza ripetuta a livello di blocco, quei blocchi vengono rimappati su uno e gli altri spariscono.
In questo modo si avrebbe anche un effetto simile alla compressione, per quanto l'effetto dipende molto dal tipo di file.

Ma si parla di database o documenti, quindi all'utente medio frega poco.

E se prima deleto poi scrivo, che dovrebbe essere equivalente... Se cancelli il file di partenza sparisce e hai solo la copia, quindi lo spazio occupato è solo quello della copia.

il data deduplication può aiutare perché in evita al costo di utilizzare la cpu per i calcoli di copiare gli stessi dati,La dedup carica il processore, visto che per sapere se un blocco è già scritto o no deve fare dei checksum o comunque far girare algoritmi per capirlo.

Se il file system implementa la dedup PRIMA della scrittura dei dati (quindi nella cache di scrittura nella RAM), diminuisce il traffico da/verso i dischi, perchè tutti i dati già presenti non li torna a scrivere ma scrive solo dei link ad essi.

Quindi copiare file di grosse dimensioni all'interno della stessa partizione è dannatamente rapido, visto che nella realtà non sta copiando una mazza ma solo mettendo dei link in giro agli stessi dati.

In genere, il processore è molto più veloce del disco in questa operazione, quindi conviene.

Anche la compressione citata sopra ha lo stesso scopo, cioè ridurre il traffico da/verso i dischi, non tanto occupare meno spazio.

Nella maggioranza dei casi, il processore comprime/decomprime un file molto più velocemente del tempo che ci mette un disco a leggerlo/scriverlo.

inoltre come ha già scritto bob..... è utile soprattutto nel caso si faccia uso di diverse virtual machine,O anche per sistemi di versioning, cioè che tengono automaticamente e in modo trasparente e SICURO (dagli utonti) uno storico dei file che sono stati modificati nel tempo per permetterti di tornare alla versione precedente con facilità senza doversi sbattere a fare copie a mano ogni nuova modifica e chiamarle nel tradizionale modo stupido e inutile a posteriori come
-documento1
-documento1new
-documento1new1
-documento1new1new

eccetera, che appena li copi in blocco perdi la data di modifica quindi poi quale di questi è la versione in data X?


In questo caso, hai file che sono composti in (gran) parte da roba che c'è già (quindi rimappata), e in parte da roba nuova.

Ad esempio Dropbox che tiene uno storico di 30 giorni di modifiche ai file con possibilità di tornare indietro. O anche OwnCloud che lo fa in locale.

Totix92
14-10-2015, 10:01
Quante ere dobbiamo aspettare per avere un degno successore del ntfs? :D

ancora con sta storia... :doh:
cos'ha ntfs che non va? anche windows phone 8/8.1 e 10 utilizzano ntfs per la memoria di sistema degli smartphone e hanno memorie flash come gli SSD eppure nessuno si è lamentato delle prestazioni della memoria sui windows phone...
ntfs funziona benisimo, non vedo il motivo di cambiare, e poi si è anche evoluto negli anni.

bobafetthotmail
14-10-2015, 10:50
ancora con sta storia... :doh:
cos'ha ntfs che non va?ed ecco uno che non legge il thread prima di commentare. :D

e hanno memorie flash come gli SSDma usano uno max 2 chip mentre un SSD ne usa vari.

Un SSD può usare chip più lenti ma più capienti visto che funziona tipo RAID quindi scrive/legge contemporaneamente su tutti (se è furbo), un dispositivo mobile no. O usa un chip veloce o sticazzi, non c'è spazio. E anche tutte le ottimizzazioni e i giochini che fa il controller lasciano il tempo che trovano, visto che c'è solo un chip.

In quel caso a parte il wear leveling in scrittura la velocità di utilizzo dipende semplicemente da quanto spinge il singolo chip flash/eMMC. (il trim/garbage collection gira per i fatti suoi)
Un pò come le schedine SD o le chiavette USB (3.0)

Infatti un SSD decente straccia un dispositivo mobile, a parità di file system.

eppure nessuno si è lamentato delle prestazioni della memoria sui windows phone...sì vabbè. un OS mobile/embedded vive nella RAM, scrive solo il minimo indispensabile e usa abbondantemente il caching in RAM.
Io non lo userei come metro di paragone per un file system.

Se paragoni la flash di bordo (eMMC) diciamo del surface 3 che ha eMMC con un surface 3 pro che ha un SSD (quindi l'OS è Windows, non winphone), vediamo chi vince?
http://www.anandtech.com/show/9219/the-surface-3-review/6
Compared to a true SSD, the eMMC performance leaves a lot to be desired. In fact, most of the time when I was using the tablet and I found it slow, such as installing software, or loading programs, it was mostly disk bound.

Ovviamente il reviewer condfronta SSD e eMMC.
Se paragonato ad un disco meccanico vola anche il surface3 normale, e comunque c'è di MOLTO edico MOLTO peggio anche come eMMC.

*aLe
14-10-2015, 11:05
ancora con sta storia... :doh:
cos'ha ntfs che non va?Già solo la data deduplication, soprattutto visto che gli SSD con alte capacità costano ancora uno sproposito, sarebbe un buon motivo per aspettare (e accogliere a braccia spalancate) un eventuale erede di NTFS. :asd:

the_joe
14-10-2015, 11:10
Già solo la data deduplication, soprattutto visto che gli SSD con alte capacità costano ancora uno sproposito, sarebbe un buon motivo per aspettare (e accogliere a braccia spalancate) un eventuale erede di NTFS. :asd:

Non ho capito, ma voi avete migliaia di copie degli stessi files sparsi per tutte le directory dell'HD?

*aLe
14-10-2015, 11:24
Non ho capito, ma voi avete migliaia di copie degli stessi files sparsi per tutte le directory dell'HD?Vuoi che ti dica la mia? Ci sono alcuni ambiti (non necessariamente professionali) in cui sarebbe utile.

Ad esempio, io mi diverto a fare modding sui videogiochi che uso di più quindi attualmente ho due/tre cartelle di FIFA 16: una per l'online (rigorosamente non toccata), una di test (della serie "se si rompe la cestino e riparto con una copia di quella stabile") e una per l'offline stabile (dove di volta in volta integro le cose che ho provato con l'installazione di "test").
La più piccola delle tre cartelle (quella untouched, che serve per l'online) "pesa" 13 GB, a regime quella di test e quella per l'offline andranno a pesare 20/25 GB l'una probabilmente.
Di quei 20/25 GB ben 13 sono composti comunque dai file "originali" (che durante il modding non vengono toccati), sarebbe comodo avere un file system che per conto suo riconosca che ci sono 3 copie identiche degli stessi file e che quindi risparmi il dovuto spazio.
Certo ora FIFA non l'ho installato su SSD perché capirai, solo le tre cartelle me ne porterebbero via tre quarti. Ma in un futuro, se sapessi che "costa" solo 20/25 GB avere le tre cartelle (invece degli attuali 50+), potrei anche pensare di farlo.

E questo è solo un esempio di uso "amatoriale". Sicuramente a livello professionale servirà molto di più.

Se venisse fatto su Windows Phone, per esempio, aiuterebbe a diminuire (automaticamente, si intende) lo spazio occupato da foto e video ricevuti tramite Whatsapp (visto che ora magari ricevi 4/5 volte gli stessi video e le stesse immagini da gruppi differenti e devi star lì a cancellarteli a mano).
Certo non sono dati "grossi", ma su 8 GB di storage (di cui ben 3 liberi, wow) avere 5 volte lo stesso video da 15 MB magari può dare fastidio. Soprattutto se il video non è uno ma diventano 5 o 6 o 7.

the_joe
14-10-2015, 11:38
Vuoi che ti dica la mia? Ci sono alcuni ambiti (non necessariamente professionali) in cui sarebbe utile.

Ad esempio, io mi diverto a fare modding sui videogiochi che uso di più quindi attualmente ho due/tre cartelle di FIFA 16: una per l'online (rigorosamente non toccata), una di test (della serie "se si rompe la cestino e riparto con una copia di quella stabile") e una per l'offline stabile (dove di volta in volta integro le cose che ho provato con l'installazione di "test").
La più piccola delle tre cartelle (quella untouched, che serve per l'online) "pesa" 13 GB, a regime quella di test e quella per l'offline andranno a pesare 20/25 GB l'una probabilmente.
Di quei 20/25 GB ben 13 sono composti comunque dai file "originali" (che durante il modding non vengono toccati), sarebbe comodo avere un file system che per conto suo riconosca che ci sono 3 copie identiche degli stessi file e che quindi risparmi il dovuto spazio.
Certo ora FIFA non l'ho installato su SSD perché capirai, solo le tre cartelle me ne porterebbero via tre quarti. Ma in un futuro, se sapessi che "costa" solo 20/25 GB avere le tre cartelle (invece degli attuali 50+), potrei anche pensare di farlo.

E questo è solo un esempio di uso "amatoriale". Sicuramente a livello professionale servirà molto di più.

Sicuramente si.

Anche se ci sono i pro e i contro come per ogni soluzione, qua c'è da considerare l'utilizzo della CPU e la relativa lentezza nelle operazioni sui files, ogni volta che si cancella o copia o comunque si modifica un file, devono essere riaggiornati i riferimenti anche di tutti i file che vi fanno riferimento, e al limite può esserci un errore dovuto al fatto che possono generarsi HASH uguali per parti di file diverse che portano alla corruzione dei file coinvolti.....

bobafetthotmail
14-10-2015, 11:53
e la relativa lentezza nelle operazioni sui files, ogni volta che si cancella o copia o comunque si modifica un file, devono essere riaggiornati i riferimenti anche di tutti i file che vi fanno riferimento,Scusa un attimo eh, ma si fa prima a modificare un registro del file system (na tabella) o a movimentare fisicamente i dati?

e al limite può esserci un errore dovuto al fatto che possono generarsi HASH uguali per parti di file diverse che portano alla corruzione dei file coinvolti.....Se usi un algoritmo dimmerda sicuramente.
Se usi chessò un SHA256 è una eventualità che avviene UNA volta ogni 2^256 hash diversi.
Oramai tutti i processori hanno acceleratori per SHA, quindi i controlli se li smazza l'acceleratore, non la CPU.

E comunque se non ti serve live, puoi anche fare un dedup sicuro, sarà più lento, ma non è che lo lanci ogni 3 minuti.
è tipo un defrag su XP.
https://blogs.oracle.com/bonwick/entry/zfs_dedup

If you accept the mathematical claim that a secure hash like SHA256 has only a 2\^-256 probability of producing the same output given two different inputs, then it is reasonable to assume that when two blocks have the same checksum, they are in fact the same block. You can trust the hash. An enormous amount of the world's commerce operates on this assumption, including your daily credit card transactions. However, if this makes you uneasy, that's OK: ZFS provies a 'verify' option that performs a full comparison of every incoming block with any alleged duplicate to ensure that they really are the same, and ZFS resolves the conflict if not. To enable this variant of dedup, just specify 'verify' instead of 'on':

EDIT avevo scambiato AES con SHA, distrazione. si ringrazia WarDuck

the_joe
14-10-2015, 13:13
Scusa un attimo eh, ma si fa prima a modificare un registro del file system (na tabella) o a movimentare fisicamente i dati?


Dipende, da qualche parte i dati fisici ci sono e quando li modifichi, devi comunque controllare tutti i riferimenti e aggiornare quelli per tutti i file collegati, quindi oltre a movimentare fisicamente di dati, devi anche controllare tutti i riferimenti.

Inoltre c'è da considerare la sicurezza, se copio un file in due diverse cartelle oggi ho 2 file e se se ne dovesse corrompere 1 ho la copia, nel caso del data deduplication, se si corrompe la parte dove sta fisicamente scritto il file di riferimento buonanotte al secchio :O

bobafetthotmail
14-10-2015, 14:09
Dipende, da qualche parte i dati fisici ci sono e quando li modifichi, devi comunque controllare tutti i riferimenti e aggiornare quelli per tutti i file collegati, quindi oltre a movimentare fisicamente di dati, devi anche controllare tutti i riferimenti.????? Se modifichi un file deduplicato il file system lascia lì quello originale coi suoi link agli altri e scrive blocchi aggiuntivi dove ci vanno solo le modifiche.

Inoltre c'è da considerare la sicurezza, se copio un file in due diverse cartelle oggi ho 2 file e se se ne dovesse corrompere 1 ho la copia, nel caso del data deduplication, se si corrompe la parte dove sta fisicamente scritto il file di riferimento buonanotte al secchio :OChe è totalmente irrilevante visto che una copia di file sullo stesso disco non costituisce un backup affidabile. :rolleyes:

Per-block checksumming (rileva gli errori e basta) + Self-healing redundant arrays (tiene automaticamente i dati di parità necessari alla correzione su un array di più dischi, come un RAID5 o 6 o RAID1)

E questo è gestito in automatico, non devo controllare a mano decine di migliaia di file e/o ore di filmati

WarDuck
14-10-2015, 21:56
Microsoft ha già pensato ad una alternativa per NTFS: http://blogs.msdn.com/b/b8/archive/2012/01/16/building-the-next-generation-file-system-for-windows-refs.aspx

Attualmente mi pare sia supportato solo su Windows Server, ma chissà...

@bobafett: AES non c'entra una mazza, non è una funzione hash ma un algoritmo di cifratura, al massimo usi SHA nelle sue varianti migliori.

Data deduplication probabilmente non interessa la maggior parte delle persone, in ogni caso mi piacerebbe avere una statistica sull'effettivo guadagno.

Misurare viene prima di ogni altra cosa.

bobafetthotmail
14-10-2015, 22:32
Microsoft ha già pensato ad una alternativa per NTFS: http://blogs.msdn.com/b/b8/archive/2012/01/16/building-the-next-generation-file-system-for-windows-refs.aspx
é in sviluppo a dargliela buona, alcune cose citate nel mio post sopra che ZFS ha (anche btrfs ha) non sono implementate (tipo ad esempio non ha il data deduplication o cache aggiuntive, manco la faccenda degli snapshot atomici) o hanno FORTE impatto sulle performance, tipo i checksum per l'integritá dei dati.
Almeno l'ultima volta che avevo guardato un anno fa.

ZFS resta meglio, non che ci fossero dubbi, in quanto è maturo. http://www.networkcomputing.com/storage/microsoft-refs-and-oracle-zfs-how-they-compare/a/d-id/1234318?

@bobafett: AES non c'entra una mazza, non è una funzione hash ma un algoritmo di cifratura, al massimo usi SHA nelle sue varianti migliori.Li scambio sempre :stordita: . gli acceleratori hardware dei processori gestiscono sia AES che SHA comunque quindi poco male.

Data deduplication probabilmente non interessa la maggior parte delle persone,Come non interessano o possono fare anche a meno della maggioranza delle features di NTFS. In quanti usano i symlink? Mh?

Alla maggior parte delle persone basta un FAT32 che non ha limite di 4 GB a file. Quindi exFAT. Ma a tanti tanti tanti basta anche FAT32.

(per quelli che non lo sanno, Fat32 scala fino a 8 TB a partizione, è solo Windows che mette limiti quando formatti)

in ogni caso mi piacerebbe avere una statistica sull'effettivo guadagno.Senza offesa, ma non riesci a scriverlo da Google e leggere un articolo a caso? Da quando hanno aggiunto la dedup al NTFS di Winserver2012 (quello basato su win8) ci sono tizi che postano test, articoli sui blog e siti di MS.

A livello server é una feature mica da poco e la strombazzano come tale. qui c'è un tool di MS che calcola quanto potresti deduplicare (va estratto da Winserver) http://blog.fosketts.net/2012/02/29/microsoft-data-deduplication-ddpeval-windows-server-2012/

Su Zfs va,http://www.edplese.com/blog/2009/11/24/zfs-deduplication-with-ntfs/
qui su NTFS http://www.happysysadm.com/2013/01/real-world-data-deduplication-savings.html

WarDuck
15-10-2015, 12:08
Come non interessano o possono fare anche a meno della maggioranza delle features di NTFS. In quanti usano i symlink? Mh?

Alla maggior parte delle persone basta un FAT32 che non ha limite di 4 GB a file. Quindi exFAT. Ma a tanti tanti tanti basta anche FAT32.

(per quelli che non lo sanno, Fat32 scala fino a 8 TB a partizione, è solo Windows che mette limiti quando formatti)


Quello che interessa è principalmente l'affidabilità, NTFS si è dimostrato affidabile, sicuramente più di FAT32.


Senza offesa, ma non riesci a scriverlo da Google e leggere un articolo a caso? Da quando hanno aggiunto la dedup al NTFS di Winserver2012 (quello basato su win8) ci sono tizi che postano test, articoli sui blog e siti di MS.

A livello server é una feature mica da poco e la strombazzano come tale. qui c'è un tool di MS che calcola quanto potresti deduplicare (va estratto da Winserver) http://blog.fosketts.net/2012/02/29/microsoft-data-deduplication-ddpeval-windows-server-2012/

Su Zfs va,http://www.edplese.com/blog/2009/11/24/zfs-deduplication-with-ntfs/
qui su NTFS http://www.happysysadm.com/2013/01/real-world-data-deduplication-savings.html

Senza offesa ma ho anche altre cose da fare che stare a cercare su Google la qualsiasi... se dovessi cercare ogni cosa che mi viene in mente sarei disoccupato :asd:

bobafetthotmail
15-10-2015, 12:28
Quello che interessa è principalmente l'affidabilità, NTFS si è dimostrato affidabile, sicuramente più di FAT32.????? Prove? Guarda che Fat32 è ancora stra-usato eh? Ha solo limitazioni strutturali, l'affidabilità che c'entra?

Senza offesa ma ho anche altre cose da fare che stare a cercare su Google la qualsiasi...Quindi non ti lamenterai se la prossima volta non sono gentile e non ti posto i link.

WarDuck
15-10-2015, 13:41
????? Prove? Guarda che Fat32 è ancora stra-usato eh? Ha solo limitazioni strutturali, l'affidabilità che c'entra?


https://en.wikipedia.org/wiki/NTFS#Journaling

Tanto per dirne una...

Non vedo perché si dovrebbe usare FAT32 su Windows... Credevo che questo fosse un discorso chiuso da tempo, invece a quanto pare c'è qualche nostalgico...

Quindi non ti lamenterai se la prossima volta non sono gentile e non ti posto i link.

Se per gentilezza intendi scrivere "senza offesa ma non riesci a cercarlo su Google?" allora posso farne tranquillamente a meno :rolleyes:

bobafetthotmail
15-10-2015, 15:44
https://en.wikipedia.org/wiki/NTFS#JournalingTanto per dirne una...No, prove che l'affidabilità di NTFS fosse richiesta dall'utenza normale.

Esattamente come il grosso delle features di NTFS sono richieste dalle aziende, anche i next generation file systems hanno features per un pubblico non di massa. Tra cui una MOLTO maggiore affidabilità e flessibilità.

ho citato i symlink perchè quelli sono un salvaculo mica da poco per me, ma fuori dall'ambito supporto tecnico e smanettamento ti guardano come se fossi un alieno.

Secondo la tua logica non avrebbero dovuto esistere.

Non vedo perché si dovrebbe usare FAT32 su Windows...Perchè chiavette USB, schede SD, compatt fresh, eccetera devono essere lette da altri dispositivi che non sempre hanno/avevano driver ntfs decenti.

Se per gentilezza intendiNo, leggi con più attenzione.

WarDuck
15-10-2015, 17:48
No, prove che l'affidabilità di NTFS fosse richiesta dall'utenza normale.


È il minimo sindacale da chiedere ad un file system.

In ambito domestico quanto aziendale, considerato che la cosa più preziosa sono i dati, anche per gli utenti "normali" o poco esperti.


Esattamente come il grosso delle features di NTFS sono richieste dalle aziende, anche i next generation file systems hanno features per un pubblico non di massa. Tra cui una MOLTO maggiore affidabilità e flessibilità.

ho citato i symlink perchè quelli sono un salvaculo mica da poco per me, ma fuori dall'ambito supporto tecnico e smanettamento ti guardano come se fossi un alieno.


Non puoi mettere le due cose sullo stesso piano dell'affidabilità.

Senza symlink si può campare, senza journaling se salta la corrente (esempio) c'è un rischio più elevato di perdere i dati.


Secondo la tua logica non avrebbero dovuto esistere.


Veramente ho detto che ai più non interesserebbe, questo non implica che non debba esistere, hai tratto una conclusione tutta tua francamente.

Allo stato attuale è una mancanza tollerabile, di certo più di una eventuale assenza del journaling.

In ogni caso le chiacchere stanno a zero perché MS non lo introdurrà neanche in ReFS.

E se hanno fatto questa scelta avranno avuto i loro buoni motivi.


Perchè chiavette USB, schede SD, compatt fresh, eccetera devono essere lette da altri dispositivi che non sempre hanno/avevano driver ntfs decenti.

Ovvio che si è costretti per forza di cose ad usare un certo formato è una cosa diversa. Non a caso MS ha tirato fuori exFAT per quel genere di dispositivi.

Inoltre c'è da dire che SD e USB spesso sono usati come dispositivi di "trasporto" più che altro...

Voglio ben sperare che non ci sia nessuno che abbia HD di backup con FAT32.

das
15-10-2015, 19:49
Cosa manca a ntfs? Perchè sto discorso si ripropone continuamente ma senza mai un fondamento solido...

Manca l'opportunità di inserire delle parole chiave abbinate al file. In modo da poterlo ritrovare più rapidamente.

Manca l'opportunità di salvare più versioni dello stesso file con lo stesso nome. In modo da non dover ogni volta aggiungere _1, _2, _3 in fondo al nome.
Già adesso ntfs uò salvare più streams sullo stesso nome di file ma la loro gestione è macchinosa e non sono mai utilizzati a livello pratico. Anche perchè se copi il file su un altro filesystem, ti perdi tutti gli streams aggiuntivi e nemmeno te ne accorgi.

WarDuck
15-10-2015, 21:39
Manca l'opportunità di inserire delle parole chiave abbinate al file. In modo da poterlo ritrovare più rapidamente.

Manca l'opportunità di salvare più versioni dello stesso file con lo stesso nome. In modo da non dover ogni volta aggiungere _1, _2, _3 in fondo al nome.
Già adesso ntfs uò salvare più streams sullo stesso nome di file ma la loro gestione è macchinosa e non sono mai utilizzati a livello pratico. Anche perchè se copi il file su un altro filesystem, ti perdi tutti gli streams aggiuntivi e nemmeno te ne accorgi.

Bisogna vedere se esistono reali vantaggi nel mettere tutte queste cose all'interno del filesystem.

In particolare il versioning è sicuramente una comodità, ma può essere realizzato da un layer posto sopra il file system.

bobafetthotmail
16-10-2015, 07:46
Senza symlink si può campare, senza journaling se salta la corrente (esempio) c'è un rischio più elevato di perdere i dati.NTFS fa il journaling solo dei metadata (infrastrutture del filesystem), ma non dei dati.

Quindi in caso di interruzione improvvisa di corrente i dati hanno la stessa sicurezza di FAT32, mentre al contrario di FAT il filesystem non richiede un checkdisk al riavvio.

ext4 di default fa uguale. Ma puoi dargli l'opzione data=journal quando monti la partizione (o nello fstab), che attiva il journaling anche dei dati.

Cioè, che prima scrive il journal con i dati e metadati, POI fa la modifica vera ai dati nel file system. In caso di interruzione di corrente questo garantisce la sicurezza dei dati.

La ragione per cui su linux non è di default attivo il journaling dei dati, è che l'impatto sulle performance è abbastanza pesante (visto che raddoppi ogni scrittura nel disco).
http://www.phoronix.com/scan.php?page=article&item=ext4_linux35_tuning&num=2

Btrfs e ZFS sono COW (copy on write) quindi usano un sistema diverso, più veloce, per proteggere i dati in caso di crash/spegnimento improvviso. http://www.qnx.com/developers/docs/660/topic/com.qnx.doc.neutrino.sys_arch/topic/fsys_COW_filesystem.html

In ogni caso le chiacchere stanno a zero perché MS non lo introdurrà neanche in ReFS.Ti deve essere sfuggito che ReFS è in sviluppo, se anche attivare una cosa basilare come il checksum dei dati rende inutilizzabile il file system, figurati se perdono tempo ad implementare la deduplicazione adesso.

Ovvio che si è costretti per forza di cose ad usare un certo formato è una cosa diversa. Non a caso MS ha tirato fuori exFAT per quel genere di dispositivi.Già, proprio quando quasi tutti i dispositivi leggono/scrivono anche ntfs, MS se ne esce con exFAT che richiede un nuovo driver e delle nuove licenze e rende illeggibile il supporto a tutti i dispositivi già presenti sul mercato.
Per offrire udite udite, FAT32 senza le limitazioni strutturali, e basta.

Infatti exFAT ha avuto un successone, se non veniva adottato come standard per le SDXC non se lo cagava nessuno (non che abbia sto forte successo anche adesso)

Inoltre c'è da dire che SD e USB spesso sono usati come dispositivi di "trasporto" più che altro...il journaling anche solo dei metadati ridurrebbe di brutto il rompimento che ogni volta che connetti una chiavetta ti chiede di correggere il file system.

das
16-10-2015, 09:41
Bisogna vedere se esistono reali vantaggi nel mettere tutte queste cose all'interno del filesystem.

In particolare il versioning è sicuramente una comodità, ma può essere realizzato da un layer posto sopra il file system.

Sì in particolare per il versioning esistono dei programmi che lo simulano. Averlo a livello di filesystem però avrebbe il vantaggio di essere uno standard e di poter passare da una macchina all'altra senza problemi.

Ma anche le parole chiave avrebbero senso secondo me. Immagina di salvare un file e quando vai a scegliere il nome (giornale.pdf ad esempio) puoi anche aggiungere parole (jobs act, doping etc.) che ti consentono una ricerca immediata. Infatti giá ora esistono programmi che ti consentono ciò ma hanno il problema di non essere standard. Quindi se trasferisci i file su un altro pc ti perdi tutto.

Penso che a livello di programmazione siano funzionalità semplici, con 4 righe di codice le mettono. E sarebbero utilissime per un sacco di gente