Ho un nuovo SSD, non voglio logorarlo, ma voglio ancora usarlo per archiviare i file di dati insieme al vecchio HDD

Ho acquistato un nuovo SSD Samsung 850 EVO da 250 GB per il mio laptop che desidero utilizzare come dispositivo di archiviazione principale, insieme al vecchio ma ancora funzionante HDD da 75 GB RPM da 250 GB che ho inserito nell'ex alloggiamento DVD con un adattatore.

Al momento l'HDD ha solo una grande partizione ext4 contenente il sistema operativo, le applicazioni e i file di dati. Voglio utilizzare l'HDD per l'archiviazione dei dati, ma non voglio perdere l'occasione di ottenere il miglioramento della velocità dell'SSD in questo modo.

Voglio combinare diciamo una partizione da 50 GB o anche più piccola sull'unità SSD e unirla con la partizione sull'HDD in modo che il file meno modificato tra i file più accessibili venga automaticamente spostato sull'unità SSD.

Ho guardato cache come EnancheIO e Bcache , ma non sembrano quello che voglio, perché (correggimi se sbaglio):

Lo spazio occupato dalla partizione della cache viene sottratto dalla quantità di spazio disponibile.
La cache accelera l'accesso ai file più accessibili indipendentemente dal fatto che siano anche i meno modificati, il che va contro l'obiettivo di non voler consumare l'SSD.

Quanto sopra è corretto o una cache (quale di questi due?) Può aiutarmi a raggiungere il mio obiettivo? Se quanto sopra è corretto, conosci qualche altra soluzione praticabile?

Un filesystem sindacale , come OverlayFS , sarebbe utile qui? Se hai monitorato l'HDD per i file più accessibili (tenendo traccia dei loro atimesu base giornaliera) e identificato quelli meno modificati tra loro (tenendo traccia dei loro mtime), in teoria potresti spostare quei file sull'SSD, liberando spazio sul HDD, mentre il filesystem union potrebbe rendere tutto ciò trasparente per l'utente.

Funzionerebbe?

— Fabio A.
fonte

In teoria i tuoi requisiti sono fattibili. La soluzione più fattibile è pubblicare una richiesta di funzionalità sul tracker dei bug di bcache che richiede un'altra strategia di memorizzazione dei file su bcache.

— Adam Ryczkowski il

... E sì, la dimensione della partizione di bcache verrà "mangiata" lontano dalla memoria disponibile totale. È in base alla progettazione, perché bcache è indipendente dal file system. Questo design ti dà il vantaggio di archiviare solo una parte di file modificata più frequentemente , il che dovrebbe essere vantaggioso, ad esempio, con i dati del database.

— Adam Ryczkowski il

Dai un'occhiata anche al progetto, che può essere facilmente modificato in base alle tue esigenze (o può persino supportarlo immediatamente

— Adam Ryczkowski,

@Fabio: nessun commento, nessuna accettazione, ma sei stato online. Problemi con la risposta qui sotto?

— Fabby,

@Fabby, proprio ora ho avuto il tempo di rivedere le risposte e i commenti, anche se ero online non potevo passare il tempo a farlo. Ci arrivo adesso.

— Fabio A.

Hai alcune opzioni a seconda di ciò che stai cercando di realizzare:

Usa bcache: Sarai in grado di mangiare la tua torta, ma non di conservarla.

Sì, la quantità di spazio riservata per la memorizzazione nella cache sarà esattamente come l'opposto di un file di scambio: la quantità specificata verrà "tolta" dalla quantità totale di spazio su disco e assegnata al sottosistema di memoria da utilizzare come buffer per l'altro disco rigido.
Per controllare quali file vengono memorizzati nella cache, utilizzare qualcosa di simile vmtouchper ottimizzare la bcachememorizzazione nella cache.
Usa LVM: riuscirai a conservare la tua torta, ma non a mangiarla.

È possibile utilizzare Logical Volume Manager per creare un volume che contiene sia SSD che HDD creando un /homevolume di grandi dimensioni che contiene lo spazio di entrambi, ma:
1. Non avrai alcun controllo su quale file va sull'SSD e quale sull'HDD
2. Se si perde una delle due unità, si perdono tutti i dati e sarà necessario ripristinare dal backup !!!
Usa un sistema manuale: sarai in grado di conservare la tua torta e mangiarla.

Partizionare l'unità in file system separati: inserire /l'SSD e /homel'HDD. Inoltre, dovresti mettere tutti i file in cui vuoi andare veloce /media/FastDatae collegare gli originali a quelli in /media/FastData se e solo se questi file risiedono nel tuo/home (altrimenti risiedono comunque sull'SSD)

^{Nota 1: ho un piccolo SSD e un grande HDD, quindi uso ancora un altro sistema: /sull'SSD e /homesull'HDD e non mi preoccupo di ottimizzare ulteriormente ...}
_{Nota 2: Un file system union non ti aiuterà più del sistema manuale ...}
_{Nota 3: Ecco alcuni suggerimenti per non consumare il tuo SSD dal punto 4 in poi}

— fabby
fonte

Dato che non hai mai accettato una risposta su questo sito prima: se questa risposta ti ha aiutato, non dimenticare di fare clic sul grigio ☑ a sinistra di questo testo, il che significa Sì, questa risposta è valida ! ;-)

— Fabby,

Ulteriori suggerimenti forniti in una nota aggiuntiva! ;-)

— Fabby,

Grazie per la risposta e il puntatore a vmtouch, ma - per non essere scortese - a parte questo, non vedo informazioni aggiuntive su ciò che mi sono dichiarato nella domanda stessa, vero? L'idea di utilizzare un sindacato FS era che sarebbe stato quindi trasparente all'utente in merito al luogo in cui i file sono stati collocati, sia sull'SSD che sull'HDD, sulla base del fatto che il processo di spostamento dei file da un supporto al l'altro sarebbe totalmente automatico. Pensandoci, potrebbe anche essere implementato con collegamenti simbolici, che potrebbero rivelarsi più facili da implementare.

— Fabio A.,

Tutto sommato, sembra che non ci sia una soluzione adeguata alla mia domanda, ma accetterò la tua risposta valida poiché hai aiutato a chiarire che non esiste ancora una soluzione adeguata. Grazie.

— Fabio A.,

@FabioA. Bene, questo dipende dalla tua definizione di "corretto". Il collegamento simbolico fa il trucco "in modo trasparente" per l'utente finale (una volta che l'amministratore lo ha impostato) ... mhddfspresenta gli stessi svantaggi della mia lvmsoluzione. Grazie mille per l'accettazione e il favore restituito: Q votato! ;-)

— Fabby,