Mam domowy serwer plików z dyskiem HDD i systemem plików XFS oraz system na dysku SSD M.2.
Czy jest sens robić LVM z cache na dysku SSD?
Jakie niesie to za sobą niebezpieczeństwa?
Czy nie będzie problemów z montowaniem i odczytem danych z dysku HDD w innym komputerze w razie jakiś problemów?
Moim zdaniem nie ma.
Kiedyś próbowałem kilku rozwiązań i zatoczyłem pełne koło dochodząc do wniosku, że w większości przypadków “kaszowanie” nie ma sensu. Zamiast tego w fazie projektowania danego systemu trzeba podjąć męską decyzję, które dane warte są trzymania na szybkim nośniku i jak duży będzie potrzebny. Często okazuje się, że tych kluczowych danych jest niewiele bo większość i tak działa z RAMu (oczywiście zależy co robisz). Zmieniło się wtedy moje podejście np. do nośnika z którego uruchamiam hypervisora - dziś jest to HDD (przeważnie RAID choć nie zawsze jest możliwość). Wtedy okazało się np., że w przypadku mojego ówczesnego serwera najlepszym (kompromis koszta-wydajność) rozwiązaniem był hybrydowy (SSD+HDD) RAID1.
Ogólnie nawet sprzętowe wynalazki typu SSHD czy Intel SRT umarły śmiercią naturalną (ktoś tego używa? - pomijając nieświadomych użytkowników co taki wynalazek dostali w gratisie z zainstalowanym Windows).
Testowałeś różnice w wydajności z obu nośników?
Jak duża i czy w ogóle jest różnica? Może wąskie gardło jest gdzie indziej, jak np. 1Gb LAN to mało?
Może napisz na czym dokładnie polega problem?
To bardziej fanaberia niż potrzeba.
Generalnie wszystko chodzi dobrze, tylko mam około 400GB wolnej przestrzeni na dysku SSD, na którym jest system i zastanawiałem się czy można to jakoś wykorzystać.
1 Gbit lan jest ograniczeniem, ale mam zamiar przejść na 2,5 Gbit.
Ramu mam 16GB to i tak przy małych plikach raczej w pamięci siedzą.
Mam 2 dyski HDD. Jeden na XFS, drugi EXT4.
Przy testach wydajności ext4 wypada lepiej przy zapisie, tak jakby chętniej korzystał z cache w RAM, natomiast XFS jest na teoretycznie szybszym dysku, ale zapis ma wolniejszy, tak jakby bardziej asekuracyjnie z RAMu korzystał.
Dla celów edukacyjnych nie zaszkodzi. 
Możesz też przetestować bcache.
Nawiązując do wątka z UPS/NUT/Cockpit możesz na tym SSD postawić kilka wirtualek.
Jaki OS na tym serwerze? Może w ogóle na tym serwerze postawić Proxmoxa a na nim MicroOS+Podman? Ja nie wyobrażam sobie życia bez takiego rozwiązania.
Na serwerze mam Leap 16.
MicroOS mnie przerósł.
Chciałbym mieć tyle czasu na hobby aby przetestować wirtualki.
Generalnie na moje potrzeby serwer śmiga, więc chyba nie będę dotykał tego co działa, w szczególności jak może to przynieść więcej problemów niż korzyści.
Czasem dziwię się, że ludzie w ogóle mają na cokolwiek czas bez wirtualizacji.
Może faktycznie w tym wypadku Proxmox to przerost formy nad treścią i z braku laku Leap musi dać radę.
Dam Ci przepis na odpalenie virtualki w góra 10 minut wliczając w to czas ściągnięcia obrazu dysku. Duuuuuużo więcej czasu zajęło mi napisanie tego wszystkiego.
Założenie: Masz sprawnie działający Leap+Cockpit+kvm/qemu/virtlib. By to spełnić wystarczy zainstalować to co jest w systemowych patterns.
Pierwsze co zrobisz to stwórz sobie jakiś roboczy folder na SSD i tam ściągnij minimalny obraz Leap16 (16.1 w chwili gdy to piszę są jeszcze niedostępne, zresztą z czasem będziesz wolał zrobić własny szablon do tego dojdą combustion, ignitions, itd. Będzie jeszcze szybciej bo automatycznie. Tak czy siak to co jest w folderach /appliances danej dystrybucji jest praktycznie gotowe do odpalenia.
Ogólnie jak poszukasz to znajdziesz gotowce na wszystko - dosłownie.
wget -c https://download.opensuse.org/distribution/leap/16.0/appliances/Leap-16.0-Minimal-VM.x86_64-kvm-and-xen.qcow2
Następnie stworzysz VM używając ten obraz. Oczywiście ustawienia zmień wedle upodobań. W zasadzie to nie ma co tu tłumaczyć. Wszystko widać.
virt-install --virt-type kvm --name leap_test --memory 2048 --vcpus 2 --disk ./Leap-16.0-Minimal-VM.x86_64-kvm-and-xen.qcow2 --import --os-variant opensuse16.0
Po tym kroku powinien odpalić się virt-viewer z działającym Leap16.
Przechodzisz przez proces zakończenia instalacji, tj. hasło root, TZ, user+pass (ten proces można zautomatyzować - wspomniane combustion / ignitions; instalacja dodatkowego softu także).
Twój VM powinien być widoczny w cockpit hosta.
Logujesz cię do tego VM Leap i instalujesz Cockpit (nie ma znaczenia czy dalej w virt-viewer czy też w termnalu w cockpit hosta (tu uwaga, po zakończonej instalacji można wyłączyć grafikę całkowicie - przy dużej ilości wirtualek będzie szybciej; Innym trikiem jest użycie kernela kvmsmall, ale to temat na inną bajkę) Dla przypomnienia instalacja cockpit dla Leap (jako root):
zypper in cockpit
systemctl enable --now cockpit.socket
firewall-cmd --permanent --zone=public --add-service=cockpit
firewall-cmd --reload
reboot
Teraz jedyny problem to ten sam port 9090 dla obu systemów. By to zmienić logujesz się do cockpit na Twoim hoscie i w zakładce Virtual machines wybierasz leap_test i tam w Network interfaces wybierasz edit i ustawiasz forward z 9090 na 9096 (oczywiście 9096 można zmienić; jak na screen-shocie).
Save and reboot VM.
Brawo! Masz działające dwa systemy. Do wirtualnego cockpitu logujesz się pod tym samym IP co Twój lokalny cockpit tyle, że nie port 9090 tylko 9096 (wszystko to możesz sobie ustawić po swojemu w cockpit hosta).
Teraz już tylko backup / spashoot VM i możesz do woli “psuć”.
Snapshoot łatwo zrobisz w tym samym oknie ustawień co wcześniej Network interfaces, dokładnie poniżej.
Oczywiście można to zrobić inaczej, ale to już sobie w miarę upływu czasu doszlifujesz po swojemu. Zwłaszcza rzeczy jak networks.
“Wesołego jajka” już teraz bo pewnie będę zajęty do końca następnego tygodnia - tak przynajmniej planuję
Dzięki.
Będę musiał teraz to przetestować 