|
|||||||
|
|
|
 |
|
|
Strumenti |
21-03-2019, 11:15
|
#1 |
|
Member
Iscritto dal: May 2006
Messaggi: 84
|
FileSystem in Linux e non solo...
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...
|
|
|
|
21-03-2019, 11:56
|
#2 |
|
Senior Member
Iscritto dal: Jan 2008
Messaggi: 8406
|
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.
|
|
|
|
|
21-03-2019, 12:21
|
#3 |
|
Member
Iscritto dal: May 2006
Messaggi: 84
|
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 |
|
|
|
|
21-03-2019, 13:20
|
#4 | |
|
Senior Member
Iscritto dal: Jan 2008
Messaggi: 8406
|
Quote:
In caso contrario si finisce per perdere dati. |
|
|
|
|
|
21-03-2019, 15:37
|
#5 | |
|
Member
Iscritto dal: May 2006
Messaggi: 84
|
Quote:
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 |
|
|
|
|
|
21-03-2019, 17:03
|
#6 | ||
|
Senior Member
Iscritto dal: Jan 2008
Messaggi: 8406
|
Quote:
Quote:
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. |
||
|
|
|
|
21-03-2019, 22:51
|
#7 | ||
|
Member
Iscritto dal: May 2006
Messaggi: 84
|
Quote:
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?" Quote:
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...
Ultima modifica di retalv : 21-03-2019 alle 22:56. |
||
|
|
|
|
22-03-2019, 09:43
|
#8 | |
|
Senior Member
Iscritto dal: Jan 2008
Messaggi: 8406
|
Quote:
Codice:
/* * 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. */ Ultima modifica di pabloski : 22-03-2019 alle 09:47. |
|
|
|
|
|
22-03-2019, 10:30
|
#9 | |
|
Member
Iscritto dal: May 2006
Messaggi: 84
|
Quote:
  Mi hai risparmiato una prova che ormai disperavo dover fare... "Il Re è morto, lunga vita al Re!"
Ultima modifica di retalv : 22-03-2019 alle 11:17. |
|
|
|
|
|
28-03-2019, 12:23
|
#10 |
|
Senior Member
Iscritto dal: Oct 2001
Messaggi: 19913
|
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ì 
__________________
Mai discutere con un idiota. Ti trascina al suo livello e ti batte con l'esperienza (O.W.) |
|
|
|
|
28-03-2019, 13:57
|
#11 | |
|
Senior Member
Iscritto dal: Jan 2008
Messaggi: 8406
|
Quote:
|
|
|
|
|
|
28-03-2019, 17:47
|
#12 | |
|
Senior Member
Iscritto dal: Oct 2001
Messaggi: 19913
|
Quote:
in effetti devo dire che non ho mai avuto problemi, neanche con formattazioni ntfs un po' "esotiche" con cluster "maggiorati" 
__________________
Mai discutere con un idiota. Ti trascina al suo livello e ti batte con l'esperienza (O.W.) |
|
|
|
|
|
|
| Strumenti | |
|
|
Tutti gli orari sono GMT +1. Ora sono le: 06:22.
