FileSystem in Linux e non solo...

[retalv]

Mi scuso anticipatamente se troverete la stessa domanda su altro forum... ricevendo risposte lacunose causa il carattere prettamente tecnico della domanda, provo a rinnovarla qui...

La domanda riguarda il supporto di NTFS in Linux... mi spiego...

NTFS da parecchio tempo è supportato nativamente da Linux ma nel tempo NTFS è cambiato, in altre parole da Windows 8 il LogFileSystem è passato dalla v1.1 (Windows 7 e Vista sicuramente) alla v2.0 ...

Il passaggio a LFS 2.0 (se si usa il disco su una macchina equipaggiata con Win10) è automatico, trasparente e indolore nei riguardi dell'utenza, però se si sposta il disco su una macchina che usa il buon vecchio Windows 7 per leggere-scrivere un volume NTFS formattato o convertito da Windows 8-10 alla prima lettura con Win7 va in errore e in scrittura il FS va in "pappa" causa il suddetto motivo e alla fine dei conti chiede di riformattare il volume.

Volendo essere coinciso, per "risolvere" problema in Windows 10 bisogna disabilitare il NTFS Log File Upgrade via registry tramite il parametro "NtfsDisableLfsUpgrade” nella chiave [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\FileSystem\]: dopo riavvio Win10 userà esclusivamente LFS v1.1.

La domada (spiego di seguito il motivo) è se Linux riconosce automaticamente la differente specifica del FS e si autoadatta al volume in cui va a scrivere... alias se in scrittura mantiene (come suppongo) il LFS in essere senza fare pasticci.

La motivazione è semplice: ho un "magazzino" esterno via USB3 da 6TB in Raid5 NTFS pieno al 70% e un disco a singolo volume NTFS (sempre esterno su USB3) usato come backup per il Raid5.

Forzatamente per mantenere "vivo" il volume singolo di backup, ogni 4-6 mesi eseguo un refresh della traccia con DiskFresh (Puransoftware.com) per avere qualche possibilità in più di non perdere dati causa smagnetizzazione dei dati più vecchi. Non conoscendo alternative linux al problema della smagnetizzazione, penso di essere costretto a mantenere il disco di backup con FS NTFS per poterlo mantenere "vivo" nel tempo.

Il disco di backup NTFS (LFS 1.1) fin tanto non viene collegato a una macchina Win10 rimarrà con le vecchie specifiche ma non escludo a priori che possa "domani" essere letto via porte SATA da Linux o da Windows 10 e nel secondo caso venir convertito con le specifiche attuali (e magari quelle che verranno) quindi sto cercando di adattarmi alle più svariate eventualità per tentare comunque ad avere accesso ai dati con entrambi i sistemi operativi.

Avevo già pensato a "traslare" la base dati su FAT32 o exFAT, ma ho scartato entrambi per i seguenti soliti motivi: entrambi non hanno quelle funzionalità di sicurezza che sono proprie di NTFS (o Ext3-4 linux), FAT32 ha il limite 4GB per file (sarebbe una impresa elefantiaca splittare i files e comunque improponibile per alcuni casi...) e exFAT oltre al essere "fragile" ancor più di FAT32 e a non essere supportato nativamente da Linux è difficile da "recuperare" (le poche utility di recupero come REMO Recovery o Eassos PartitionGuru esistono esclusivamente il ambiente Windows... dubito esista qualcosa per Linux che ancora oggi relega e motivatamente questo FS a livello utente...).

Idee e considerazioni sull'argomento sono ovviamente apprezzate...

[pabloski]

Mi pare di capire che e' una modifica non retrocompatibile. Per cui o la versioni di NTFS-3g ( quello per Linux ) supporta la nuova funzionalita', oppure ti ritroverai con gli stessi problemi che hai su Windows.

[retalv]

Esatto, non è retro compatibile, ma mi suonerebbe "strano" che linux non consideri il fatto e la semplice differenza di accesso... qualcuno ha avuto modo di provare se un DISCO NTFS creato con WIN10 viene letto scritto con Linux senza problemi?

Per capire con quale LFS è dotato il volume NTFS basta seguire questa semplice guida-considerazione di ben 5 anni fa...

https://social.technet.microsoft.com...f-windows.aspx

[pabloski]

Originariamente inviato da retalv

Esatto, non è retro compatibile, ma mi suonerebbe "strano" che linux non consideri il fatto e la semplice differenza di accesso... qualcuno ha avuto modo di provare se un DISCO NTFS creato con WIN10 viene letto scritto con Linux senza problemi?

Per capire con quale LFS è dotato il volume NTFS basta seguire questa semplice guida-considerazione di ben 5 anni fa...

https://social.technet.microsoft.com...f-windows.aspx

Ah ma e' quella cosa del boot ibrido? Nel qual caso e' un problema noto e l'unica via e' disabiltarlo da Windows. Poi riavviare e spegnere come si deve, in modo che il journal del fs sia completamente committed.

In caso contrario si finisce per perdere dati.

[retalv]

Originariamente inviato da pabloski

Ah ma e' quella cosa del boot ibrido?

Non stiamo parlando di Windows ma dell'uso-abuso del FS NTFS in Linux.
Nell'articolo si parla anche di boot ibrido nello scenario dei sistemi Multi Boot, quindi si legge anche della problematica del caching ma riguardo al problema in evidenza tutto questo non è interessante.

I capitoli di interesse riguardanti il LFS NTFS sono:

Determining if your volume has been upgraded to Logfile version 2.0
e
Disabling NTFS Log File Upgrade

[pabloski]

Originariamente inviato da retalv

Non stiamo parlando di Windows ma dell'uso-abuso del FS NTFS in Linux.

Purtroppo il boot ibrido e' interessante ai fini del tuo problema, per la seguente ragione

When an NTFS volume is cleanly dismounted (such as on a full shutdown, a reboot, or a safe remove), NTFS will “downgrade” the log file structure and version number to one that is recognized by all prior versions of Windows.

Cioe' disabilitare il boot ibrido in Windows 8 e 10, rende il volume leggibile senza problemi da Windows 7 e inferiori e ovviamente da NTFS-3g.

Il punto ( per questo citavo Windows 7 ) e' che NTFS-3g non supporta la v2.0 di LFS ( sono andato a guardare il codice ).

Considerando che il comportamento di default in casi di incosistenze e' di ripulire il journal ( log file ), direi che usare NTFS-3g per leggere simili volumi e' un biglietto di sola andata per un disastro.

[retalv]

Originariamente inviato da pabloski

Cioe' disabilitare il boot ibrido in Windows 8 e 10, rende il volume leggibile senza problemi da Windows 7 e inferiori e ovviamente da NTFS-3g.

Il problema è che dai per scontato che io stia usando Win8-8.1-10. Ma cosi non è ... (e non lo trovi scritto da nessuna parte del post iniziale): usando Linux Mint e Win7 quello del boot ibrido è un problema inesistente.

Il mio dubbio è...
"Se dovessi forzatamente collegare direttamente a una macchina Linux un volume NTFS con LFS 2.0 riuscirei a leggerlo (e magari a sciverlo) senza i problemi che avrei facendo la stessa cosa con Win7?"

Originariamente inviato da pabloski

NTFS-3g non supporta la v2.0 di LFS

Forse sbaglio, ma l'implementazione di NTFS-3g di Tuxera (2017), quella implementata attualmente nella distribuzione Linux Mint e (credo) da tutte le altre distro comuni, cita la piena compatibilità con Windows XP, Windows Server 2003, Windows 2000, Windows Vista, Windows Server 2008, Windows 7, Windows 8 and Windows 10 e non mi meraviglierebbe considerato che il rilascio di Win10 è del 2015.

C'è da dire però che conoscendo l'andazzo prima di prendere per oro colato quanto trovo scritto vorrei avere un riscontro oggettivo sull'argomento senza bisogno di formattare un disco in NTFS con Win10 e poi collegarlo via SATA a linux "...per vedere l'effetto che fa...", ma mi sa che mi toccherà farlo...

[pabloski]

Originariamente inviato da retalv

Forse sbaglio, ma l'implementazione di NTFS-3g di Tuxera (2017), quella implementata attualmente nella distribuzione Linux Mint e (credo) da tutte le altre distro comuni, cita la piena compatibilità con Windows XP, Windows Server 2003, Windows 2000, Windows Vista, Windows Server 2008, Windows 7, Windows 8 and Windows 10 e non mi meraviglierebbe considerato che il rilascio di Win10 è del 2015.

Eh si, mi sa che hanno ragione. Ho riguardato i sorgenti ed effettivamente nel file libntfs-3g/logfile.c c'e' scritto

/*
	 * We only know how to handle version 1.1 and 2.0, though
	 * version 2.0 is probably related to cached metadata in
	 * Windows 8, and we will refuse to mount.
	 * Nevertheless, do all the relevant checks before rejecting.
	 */

[retalv]

Originariamente inviato da pabloski

Eh si, mi sa che hanno ragione. Ho riguardato i sorgenti ed effettivamente nel file libntfs-3g/logfile.c c'e' scritto...

Bene e molte grazie!!!

Mi hai risparmiato una prova che ormai disperavo dover fare...

"Il Re è morto, lunga vita al Re!"

[zappy]

non ho capito: ntfs-3g quindi supporta anche le ultime vers? di ntfs o no?

a proposito del refresh dei dati (DiskFresh ecc.), AFAIK è una funzionalità che svolge già di suo l'elettronica dell'hd, mentre è in idle, in modo del tutto trasparente al SO. Non ci metto la mano sul fuoco, non so come verificarlo, ma mi risultava così

[pabloski]

Originariamente inviato da zappy

non ho capito: ntfs-3g quindi supporta anche le ultime vers? di ntfs o no?

Si.

[zappy]

Originariamente inviato da pabloski

Si.

ok, grazie
in effetti devo dire che non ho mai avuto problemi, neanche con formattazioni ntfs un po' "esotiche" con cluster "maggiorati"