Mam nowy dysk SSD, nie chcę go zużywać, ale nadal chcę go używać do przechowywania plików danych razem ze starym dyskiem twardym

Kupiłem nowy dysk SSD Samsung 850 EVO o pojemności 250 GB dla mojego laptopa, którego chcę używać jako podstawowego urządzenia magazynującego, wraz ze starym, ale wciąż działającym dyskiem twardym o pojemności 250 GB 7500 obr./min, który włożyłem do dawnej wnęki DVD z caddy adaptera.

Obecnie dysk twardy ma tylko jedną dużą partycję ext4 zawierającą system operacyjny, aplikacje i pliki danych. Chcę używać dysku twardego do przechowywania danych, ale nie chcę przegapić okazji do poprawy szybkości SSD.

Chcę połączyć powiedzmy 50 GB lub nawet mniejszą partycję na dysku SSD i połączyć ją z partycją na dysku twardym, aby najmniej zmodyfikowane pliki, do których najczęściej uzyskiwano dostęp, były automatycznie przenoszone na dysk SSD.

Patrzyłem na bufory takie jak EnancheIO i Bcache , ale nie wydają się tego, czego chcę, ponieważ (popraw mnie, jeśli się mylę):

Miejsce zajmowane przez partycję pamięci podręcznej jest odejmowane od ilości dostępnego miejsca.
Pamięć podręczna przyspiesza dostęp do najczęściej uzyskiwanych plików, niezależnie od tego, czy są one również najrzadziej modyfikowane, co jest sprzeczne z celem polegającym na tym, aby nie chcieć zużywać dysku SSD.

Czy powyższe informacje są prawidłowe, czy może pamięć podręczna (która z tych dwóch?) Może pomóc mi osiągnąć cel? Jeśli powyższe informacje są poprawne, czy znasz jakieś inne realne rozwiązanie?

Czy pomocny byłby tutaj system plików unii , taki jak OverlayFS ? Jeśli monitorujesz dysk twardy pod kątem najczęściej używanych plików ( atimecodziennie je śledzisz) i identyfikujesz najmniej zmodyfikowane spośród nich (śledząc ich mtime), teoretycznie możesz przenieść te pliki na dysk SSD, zwalniając miejsce na HDD, podczas gdy unijny system plików może uczynić to wszystko przejrzystym dla użytkownika.

Czy to zadziała?

— Fabio A.
źródło

Teoretycznie twoje wymagania są wykonalne. Najbardziej realnym rozwiązaniem jest opublikowanie żądania funkcji w narzędziu do śledzenia błędów bcache z prośbą o inną strategię przechowywania plików na bcache.

— Adam Ryczkowski,

... I tak, rozmiar partycji bcache zostanie „zjedzony” z dala od całkowitej dostępnej pamięci. Jest to zgodne z projektem, ponieważ bcache jest agnostyczny dla systemu plików. Ten projekt daje dodatkową zaletę przechowywania tylko najczęściej zmienianej części pliku , co powinno być korzystne np. W przypadku danych z bazy danych.

— Adam Ryczkowski,

Zobacz także projekt, który można łatwo zmodyfikować, aby dopasować do twoich potrzeb (lub nawet może być obsługiwany po wyjęciu z pudełka): romanrm.net/mhddfs

— Adam Ryczkowski

@Fabio: bez komentarza, bez akceptacji, ale jesteś online. Masz problemy z odpowiedzią poniżej?

— Fabby,

@Fabby, właśnie teraz miałem czas na przejrzenie odpowiedzi i komentarzy, mimo że byłem online, nie mogłem spędzić czasu na robieniu tego. Przejdę teraz do tego.

— Fabio A.,

Masz kilka opcji w zależności od tego, co próbujesz osiągnąć:

Zastosowanie bcache: Będziesz mógł zjeść swoje ciasto, ale go nie zatrzymasz.

Tak, ilość miejsca zarezerwowanego na buforowanie będzie dokładnie odwrotna do pliku wymiany: określona przez ciebie ilość zostanie „zabrana” z całkowitej ilości miejsca na dysku i przekazana podsystemowi pamięci, który będzie używany jako bufory dla drugi dysk twardy.
Aby kontrolować, które pliki mają być buforowane, użyj czegoś takiego, vmtouchaby dostroić bcachebuforowanie.
Użyj LVM: Dostaniesz ciasto, ale go nie zjesz.

Za pomocą Menedżera woluminów logicznych można utworzyć wolumin zawierający zarówno dysk SSD, jak i dysk twardy, tworząc duży /homewolumin zawierający przestrzeń z obu, ale:
1. Nie będziesz mieć kontroli nad tym, który plik znajduje się na dysku SSD, a który na dysku twardym
2. Jeśli stracisz jeden z dwóch dysków, stracisz wszystkie dane i będziesz musiał je przywrócić z kopii zapasowej !!!
Użyj systemu ręcznego: będziesz mógł zatrzymać ciasto i zjeść je.

Podziel dysk na osobne systemy plików: włóż /dysk SSD i /homedysk twardy. Ponadto powinieneś umieścić wszystkie pliki, do których chcesz szybko przejść, /media/FastDatai dowiązać oryginały do /media/FastData tych plików/home , jeśli i tylko jeśli te pliki znajdują się w twoim pliku (w przeciwnym razie i tak już znajdują się na dysku SSD)

^{Uwaga 1: Mam mały dysk SSD i duży dysk twardy, więc używam jeszcze jednego systemu: /na dysku SSD i /homena dysku twardym i nie zawracam sobie głowy dalszą optymalizacją ...}
_{Uwaga 2: Unijny system plików nie pomoże więcej niż system ręczny ...}
_{Uwaga 3: Oto kilka dodatkowych wskazówek, aby nie zużywać dysku SSD od punktu 4 i dalej}

— Fabby
źródło

Ponieważ nigdy wcześniej nie akceptowałeś odpowiedzi na tej stronie: Jeśli ta odpowiedź ci pomogła, nie zapomnij kliknąć szarego ☑ po lewej stronie tego tekstu, co oznacza , że tak, ta odpowiedź jest poprawna ! ;-)

— Fabby,

Dodatkowe wskazówki zawarte w dodatkowej notatce! ;-)

— Fabby,

Dzięki za odpowiedź i wskaźnik do vmtouch, ale - żeby nie być niegrzeczny - poza tym nie widzę żadnych dodatkowych informacji na temat tego, co powiedziałem w samym pytaniu, prawda? Pomysł użycia Union FS polegał na tym, że użytkownik byłby wówczas przejrzysty dla miejsca, w którym pliki zostały umieszczone - czy to na dysku SSD, czy na dysku twardym - na podstawie procesu przenoszenia plików z jednego nośnika na inne byłyby całkowicie automatyczne. Myśląc o tym, można go również wdrożyć za pomocą dowiązań symbolicznych, które mogą okazać się łatwiejsze do wdrożenia.

— Fabio A.

Podsumowując, wydaje się, że nie ma właściwego rozwiązania mojego pytania, ale zaakceptuję twoją odpowiedź jako ważną, ponieważ pomogłeś wyjaśnić, że na razie nie ma właściwego rozwiązania. Dziękuję Ci.

— Fabio A.

@FabioA. To zależy od twojej definicji „właściwego”. Symlinkowanie działa „transparentnie” dla użytkownika końcowego (po skonfigurowaniu go przez administratora) ... mhddfsma te same wady mojego lvmrozwiązania. Grazie mille za akceptację i łaskę wrócił: Q głosował! ;-)

— Fabby