<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Ssd on Morfitronik</title>
    <link>https://morfikov.github.io/tags/ssd/</link>
    <description>Recent content in Ssd on Morfitronik</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>pl-PL</language>
    <lastBuildDate>Thu, 22 Jan 2026 14:55:00 +0100</lastBuildDate><atom:link href="https://morfikov.github.io/tags/ssd/feed.xml" rel="self" type="application/rss+xml" />
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Jak Video DownloadHelper (VDH) zabija dyski SSD (Firefox/Chrome)</title>
      <link>https://morfikov.github.io/post/jak-video-downloadhelper-vdh-zabija-dyski-ssd-firefox-chrome/</link>
      <pubDate>Thu, 22 Jan 2026 14:55:00 +0100</pubDate>
      
      <guid>https://morfikov.github.io/post/jak-video-downloadhelper-vdh-zabija-dyski-ssd-firefox-chrome/</guid>
      <description>&lt;p&gt;Jakiś już czas temu naskrobałem kawałek artykułu na temat &lt;a href=&#34;https://morfikov.github.io/post/trim-discard-przy-luks-lvm-na-dysku-ssd-pod-debian-linux/&#34;&gt;mechanizmu Trim/discard w kontekście
LUKS/LVM na dysku SSD pod Debian linux&lt;/a&gt;, przy okazji poruszając tam kwestie nieco daleko
idącej &lt;a href=&#34;https://morfikov.github.io/post/trim-discard-przy-luks-lvm-na-dysku-ssd-pod-debian-linux/#odci%C4%85%C5%BCenie-dysku-ssd-przez-wykorzystanie-ramdysk%C3%B3w&#34;&gt;optymalizacji systemu pod kątem przedłużenia żywotności tego typu dyskom opartym o
technologię flash&lt;/a&gt;. Opisane w tym powyższym artykule zabiegi sprawiły, że zapis danych na tym
dysku systemowym waha się w okolicy 3 GiB na dzień (średnia za rok 2024 i 2025). Gdyby ten stan
rzeczy utrzymać, to ten dysk SSD posłużyłby jeszcze przez około 160 lat i taka żywotność nośnika
SSD mnie jak najbardziej zadowala... Przez te dwa ostatnie lata tylko kilka aplikacji chciało
zapisywać ogromne ilości danych na dysku systemowym bez wyraźnej przyczyny, np &lt;a href=&#34;https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1058022&#34;&gt;QuiteRSS&lt;/a&gt;, a tak
poza tym, to ten dysk SSD nie wykazywał większych odchyłów od normy w kwestii zapisu danych.
Niestety ten stan rzeczy uległ zmianie kilka dni temu. Szukając przyczyny udało się zawęzić krąg
podejrzanych do przeglądarki Firefox (ewentualnie też Google Chrome i Chromium). Okazało się, że
jeden z jej dodatków, a konkretnie &lt;a href=&#34;https://github.com/aclap-dev/video-downloadhelper&#34;&gt;Video DownloadHelper&lt;/a&gt; (VDH), z jakiegoś powodu zapisuje
ogromne ilości danych w katalogu profilu tej przeglądarki (tj. w &lt;code&gt;~/.mozilla/firefox/&lt;/code&gt; ).
Pobierając dużo materiałów audio/video, np. z YouTube czy CDA, bardzo szybko nam taki dysk SSD
padnie i to bez znaczenia czy docelowy katalog zapisu pobranych danych z internetu mamy ustawiony,
np. na osobnym dysku HDD. Czy istnieje zatem jakiś sposób, który by powstrzymał dodatek Video
DownloadHelper od zniszczenia nam dysku SSD?&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>TRIM/UNMAP w dyskach SSD podłączonych via adapter USB-SATA na linux</title>
      <link>https://morfikov.github.io/post/trim-unmap-w-dyskach-ssd-podlaczonych-via-adapter-usb-sata-na-linux/</link>
      <pubDate>Sun, 16 Jun 2024 16:30:00 +0200</pubDate>
      
      <guid>https://morfikov.github.io/post/trim-unmap-w-dyskach-ssd-podlaczonych-via-adapter-usb-sata-na-linux/</guid>
      <description>&lt;p&gt;Jakiś czas temu opisywałem &lt;a href=&#34;https://morfikov.github.io/post/trim-discard-przy-luks-lvm-na-dysku-ssd-pod-debian-linux/&#34;&gt;jak na Debianie włączyć obsługę mechanizmu TRIM&lt;/a&gt; (realizowanego
przez polecenie &lt;code&gt;fstrim&lt;/code&gt; ) na podpiętych do komputera dyskach SSD. Problem w tym, że dyski SSD, z
którymi będziemy wchodzić w interakcję, nie zawsze będą podłączane do dedykowanych portów
SATA/mSATA. Jak zachowa się zatem nasz linux, gdy będziemy chcieli podłączyć po portu USB
zewnętrzny dysk SSD? Przez zewnętrzny dysk USB nie mam na myśli dedykowanych zewnętrznych dysków
USB, bo te raczej nie powinny sprawiać kłopotów. Chodzi mi bardziej o wewnętrzne dyski SSD (np. ze
starego laptopa), które zamkniemy w dedykowanej obudowie USB, lub też będziemy taki dysk podłączać
na krótko za pomocą adaptera USB-SATA. W takich przypadkach zwykle kernel linux&#39;a nie odważy się
włączyć wsparcia dla TRIM dla nośników SSD i tak właśnie się stało w przypadku mojego nowo
zakupionego dysku od Goodram, a konkretnie jest to model &lt;code&gt;SSDPR-CX400-02T-G2&lt;/code&gt; , który to został
podłączony do portu USB3 mojego Raspberry PI (i Debiana) przy pomocy kabelka USB-SATA (Unitek
USB3.1 USB-A to 2.5&amp;quot; SATA6G). Przez kilka miesięcy dysk sprawował się bez zarzutu ale ostatnio przy
próbie wgrania na niego danych (przez sieć), transfer spadł do dosłownie pojedynczych MiB/s.
Poszukałem trochę informacji i okazało się, że dla tego typu nośników &lt;a href=&#34;https://www.jeffgeerling.com/blog/2020/enabling-trim-on-external-ssd-on-raspberry-pi&#34;&gt;trzeba ręcznie włączyć
TRIM&lt;/a&gt;, o ile będzie to w ogóle możliwe.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Przestrzeń wymiany SWAP tylko na potrzebny hibernacji w Debian linux</title>
      <link>https://morfikov.github.io/post/przestrzen-wymiany-swap-tylko-na-potrzebny-hibernacji-w-debian-linux/</link>
      <pubDate>Wed, 10 Jan 2024 20:05:00 +0100</pubDate>
      
      <guid>https://morfikov.github.io/post/przestrzen-wymiany-swap-tylko-na-potrzebny-hibernacji-w-debian-linux/</guid>
      <description>&lt;p&gt;W obecnych czasach, rola przestrzeni wymiany w zasadzie ograniczyła się z grubsza do umożliwienia
nam przeprowadzenia procesu hibernacji. Inne aspekty pracy systemu, w których SWAP brał udział
zostały albo zepchnięte na margines (bardzo stare maszyny z niewielką ilością RAM), albo zupełnie
wyeliminowane za sprawą nowszych technologi lub/i posiadania większej ilości pamięci operacyjnej w
takich systemach. Obecnie domowy komputer z 32 GiB pamięci RAM to nic niezwykłego i przestrzeń
wymiany na takich maszynach nie jest już nam w zasadzie do niczego potrzebna, bo raczej jest mało
prawdopodobne, że nam tej pamięci zabraknie przy codziennym użytkowaniu naszego linux&#39;a. Niemniej
jednak, hibernacja systemu jest czymś pozytywnym z perspektywy użytkownika, bo umożliwia mu
zapisanie stanu pracy przed wyłączeniem komputera i odtworzenie tego stanu po ponownym uruchomieniu
systemu. Jeśli chcielibyśmy się cieszyć urokami hibernacji, to bez konfiguracji SWAP&#39;a się nie
obejdzie. Problem jednak zaczyna się, gdy mamy dysk SSD i taka przestrzeń wymiany zostanie na nim
skonfigurowana. Chodzi generalnie o pewne aplikacje, które są w stanie generować bardzo dużo cache
w pamięci operacyjnej, czego efektem będzie przenoszenie danych z RAM do SWAP, a to może bardzo
szybko wykończyć taki nośnik flash. Dlatego też przydałoby się nieco zabezpieczyć przestrzeń
wymiany przed tego typu sytuacjami, tak by można było jej używać jedynie w przypadku hibernacji.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Trim/discard przy LUKS/LVM na dysku SSD pod Debian linux</title>
      <link>https://morfikov.github.io/post/trim-discard-przy-luks-lvm-na-dysku-ssd-pod-debian-linux/</link>
      <pubDate>Fri, 15 Dec 2023 17:00:00 +0100</pubDate>
      
      <guid>https://morfikov.github.io/post/trim-discard-przy-luks-lvm-na-dysku-ssd-pod-debian-linux/</guid>
      <description>&lt;p&gt;Z okazji zbliżającego się końca roku, postanowiłem nieco ogarnąć swojego Debiana, tj. postawić go
na nowo. Jakby nie patrzeć 4 lata korzystania z tego linux&#39;a z włączonymi gałęziami unstable i
experimental sprawiło, że trochę syfu się nazbierało. Nie chciałem też czyścić całego kontenera
LUKS czy samej struktury LVM z systemowymi voluminami logicznymi na starym dysku HDD, bo
zainstalowany tam system zawsze może się do czegoś przydać, np. do odratowania tego nowego linux&#39;a.
Dlatego też postanowiłem zakupić niedrogi dysk SSD (MLC, używany) i to na nim &lt;a href=&#34;https://morfikov.github.io/post/instalacja-debiana-z-wykorzystaniem-debootstrap/&#34;&gt;postawić świeżego
Debiana z wykorzystaniem narzędzia debootstrap&lt;/a&gt;. Sama instalacja linux&#39;a na dysku SSD nie różni
się zbytnio od instalacji na dysku HDD, za wyjątkiem skonfigurowania w takim systemie mechanizmu
trim/discard. Standardowi użytkownicy linux&#39;a nie muszą zbytnio nic robić, aby ten mechanizm został
poprawnie skonfigurowany. Sprawa się nieco komplikuje, gdy wykorzystywany jest &lt;a href=&#34;https://en.wikipedia.org/wiki/Device_mapper&#34;&gt;device-mapper&lt;/a&gt;,
który mapuje fizyczne bloki urządzenia na te wirtualne, np. przy szyfrowaniu dysku z wykorzystaniem
LUKS/dm-crypt, czy korzystaniu z voluminów logicznych LVM. Dlatego też postanowiłem przyjrzeć się
nieco bliżej zagadnieniu konfiguracji mechanizmu trim/discard na dysku SSD w przypadku
zaszyfrowanego systemu na bazie LUKS+LVM.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Analiza systemu plików EXT4 pod kątem formatowania większych dysków pod linux</title>
      <link>https://morfikov.github.io/post/analiza-systemu-plikow-ext4-pod-katem-formatowania-wiekszych-dyskow-pod-linux/</link>
      <pubDate>Sun, 25 Jul 2021 18:40:00 +0200</pubDate>
      
      <guid>https://morfikov.github.io/post/analiza-systemu-plikow-ext4-pod-katem-formatowania-wiekszych-dyskow-pod-linux/</guid>
      <description>&lt;p&gt;Zapewne każdy użytkownik linux&#39;a tworzył na dysku HDD/SSD partycje sformatowane systemem plików
EXT4. Prawdopodobnie też zastanawiało nas pytanie odnośnie ilości zajmowanego miejsca przez
strukturę samego systemu plików, zwłaszcza w przypadku dysków o sporych rozmiarach (setki GiB, czy
nawet kilka TiB). Jako, że musiałem ostatnio zmigrować kolekcję filmów ze strych dysków na
jeden większy, który miał zostać podłączony pod Raspberry Pi z działającym Kodi na bazie LibreELEC,
to przy okazji postanowiłem ten dysk sformatować w taki sposób, w jaki powinno się do tego zadania
podchodzić wiedząc, że ma się do czynienia z dużym dyskiem, na którym będą przechowywane głównie
duże pliki. Celem tego artykułu jest pokazanie jakie błędy przy tworzeniu systemu plików EXT4 można
popełnić przez posiadanie niezbyt wystarczającej wiedzy z jego zakresu, oraz jak te błędy
wyeliminować przed rozpoczęciem korzystania z tak nie do końca poprawnie przygotowanego do pracy
dysku twardego&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Montowanie dysków USB na Raspberry Pi z LibreELEC w trybie tylko do odczytu</title>
      <link>https://morfikov.github.io/post/montowanie-dyskow-usb-na-raspberry-pi-z-libreelec-w-trybie-tylko-do-odczytu/</link>
      <pubDate>Mon, 24 Aug 2020 21:00:00 +0200</pubDate>
      
      <guid>https://morfikov.github.io/post/montowanie-dyskow-usb-na-raspberry-pi-z-libreelec-w-trybie-tylko-do-odczytu/</guid>
      <description>&lt;p&gt;Po paru dniach zabawy z &lt;a href=&#34;https://libreelec.tv/&#34;&gt;LibreELEC&lt;/a&gt; na Raspberry Pi 4B mogę powiedzieć, że ten system ma w
zasadzie wszystko to, co jest potrzebne przy zabawie z Kodi/XBMC i przerabianiu maliny na domowe
centrum multimediów. Niestety jednak, w moim przypadku pojawił się jeden problem, który dotyczył
montowania zasobów (konkretnie dysku HDD). Chodzi generalnie o to, że LibreELEC nie umożliwia
zdefiniowania własnych punktów montowania i opcji dla tych punktów. W ten sposób wszystkie dyski USB
podłączone do Raspberry Pi 4B będą działać w trybie do zapisu. Teoretycznie LibreELEC (czy Kodi)
nie powinien nic na tych dyskach zapisywać sam z siebie. Niemniej jednak, system plików NTFS
działający w trybie do zapisu na maszynie z linux, która nie ma podłączonego żadnego UPS&#39;a, budzi u
mnie lekki dyskomfort psychiczny. Chciałem zatem swój dysk zamontować w trybie tylko do odczytu ale
polityka LibreELEC na to domyślnie nie pozwala, co nie znaczy oczywiście, że tego zadania się nie
da zrealizować.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Jak przygotować dysk pod instalację Debian linux z EFI/UEFI</title>
      <link>https://morfikov.github.io/post/jak-przygotowac-dysk-pod-instalacje-debian-linux-z-efi-uefi/</link>
      <pubDate>Tue, 10 Mar 2020 03:28:00 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/jak-przygotowac-dysk-pod-instalacje-debian-linux-z-efi-uefi/</guid>
      <description>&lt;p&gt;Instalacja linux&#39;a w trybie EFI/UEFI nieco inaczej wygląda niż tradycyjna instalacja systemu, zwana
często dla odróżnienia trybem BIOS, przynajmniej przy wykorzystaniu &lt;code&gt;debootstrap&lt;/code&gt; Jeśli kupujemy
nowego desktopa czy laptopa, to zwykle będziemy mieli na dysku twardym zainstalowanego windows&#39;a i
tym samym przygotowany cały układ partycji niezbędny do prawidłowego uruchomienia systemu w trybie
EFI/UEFI. Co jednak w przypadku, gdy kupimy komputer bez systemu operacyjnego? W takiej sytuacji
trzeba będzie ręcznie podzielić dysk na partycje oraz zainstalować menadżer rozruchu (rEFInd) lub
też bootloader (grub/grub2/syslinux/extlinux) i skonfigurować wszystkie te elementy samodzielnie.
Prawdopodobnie instalator Debiana jest w stanie za nas te kroki przeprowadzić automatycznie ale my
nie będziemy korzystać z automatycznych rozwiązań, bo one nieco odmóżdżają. Spróbujemy za to
stworzyć sobie uniwersalną konfigurację, która pozwoli nam zainstalować i odpalić dowolną
dystrybucję linux&#39;a w trybie EFI/UEFI.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Montowanie dysków jako zwykły użytkownik z UDisks i PolicyKit</title>
      <link>https://morfikov.github.io/post/montowanie-dyskow-jako-zwykly-uzytkownik-z-udisks-i-policykit/</link>
      <pubDate>Fri, 26 Apr 2019 21:10:15 +0200</pubDate>
      
      <guid>https://morfikov.github.io/post/montowanie-dyskow-jako-zwykly-uzytkownik-z-udisks-i-policykit/</guid>
      <description>&lt;p&gt;Jeszcze nie tak dawno temu przeciętnej klasy desktop był wyposażony w pojedynczy i do tego
niewielkiej pojemności dysk twardy, który był w stanie pomieścić wszystkie pliki swojego
właściciela. Obecnie jednak większość maszyn ma tych nośników już kilka. Mowa tutaj nie tylko o
dyskach systemowych, które są fizycznie na stałe zamontowane w komputerze ale również o tych
wszystkich urządzeniach, które można podłączyć do portu USB. Polityka linux&#39;a wymusza, by wszystkie
nośniki pamięci masowej (HDD, SSD, pendrive czy też karty SD) były montowane w systemie jedynie
przez użytkowników posiadających uprawnienia administratora. Domyślnie taki przywilej ma jedynie
root. Zatem by uzyskać dostęp do danych na takim zewnętrznym nośniku musimy logować się na root&#39;a.
Jakby nie patrzeć ma to swoje plusy patrząc z perspektywy bezpieczeństwa, niemniej jednak czy
naprawdę potrzebny nam jest root do wgrania czegoś na nasz ulubiony pendrive? Widać nie tylko ja
zadawałem sobie takie pytanie i ktoś postanowił stworzyć narzędzie UDisks (lub jego nowszą wersję
UDisks2), które za pomocą mechanizmu PolicyKit (zwanym też PolKit) jest w stanie nadać stosowne
uprawnienia konkretnym użytkownikom systemu, przez co można określić zespół akcji, które będą oni w
stanie przeprowadzić bez potrzeby podawania hasła, np. montowanie czy odmontowanie zasobu.
Postanowiłem zatem zobaczyć jak ten duet sobie radzi na moim Debianie przy tradycyjnym użytkowaniu
systemu i ocenić jego stopień przydatności.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Badsector dysku HDD w kontenerze LUKS zawierającym LVM</title>
      <link>https://morfikov.github.io/post/badsector-dysku-hdd-w-kontenerze-luks-zawierajacym-lvm/</link>
      <pubDate>Sun, 31 Mar 2019 12:23:42 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/badsector-dysku-hdd-w-kontenerze-luks-zawierajacym-lvm/</guid>
      <description>&lt;p&gt;Podczas rutynowego skanu powierzchni dysków HDD w moim laptopie, S.M.A.R.T wykrył w jednym z nich
podejrzany blok, który zdawał się wyzionąć już ducha, przez co proces weryfikacji integralności
powierzchni dysku twardego nie był w stanie zakończyć się z powodzeniem. Komunikat zwracany przy
czytaniu padniętego sektora też był nieco dziwny: &lt;code&gt;bad/missing sense data, sb[]&lt;/code&gt; . Jakiś czas temu
już opisywałem jak &lt;a href=&#34;https://morfikov.github.io/post/uszkodzony-sektor-na-dysku-i-jego-realokacja/&#34;&gt;realokować uszkodzony sektor dysku HDD&lt;/a&gt; i w zasadzie wszystkie informacje
zawarte w tamtym artykule można by wykorzystać do próby poprawienia zaistniałego problemu, gdyby
tylko nie fakt, że w tym przypadku badblock znalazł się w obszarze voluminu logicznego LVM na
partycji zaszyfrowanej przy pomocy mechanizmu LUKS. Taki schemat układu partycji sprawia, że do
realokowania błędnego bloku trzeba podejść nieco inaczej uwzględniając w tym procesie kilka
offset&#39;ów, bez których w zasadzie nic nie da się zrobić. Postanowiłem zatem napisać na konkretnym
przykładzie jak realokować badsector dysku, gdy do czynienia mamy z zaszyfrowanym linux&#39;em
zainstalowanym na voluminach LVM.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Jak optymalnie podzielić dysk HDD/SSD na partycje pod linux</title>
      <link>https://morfikov.github.io/post/jak-optymalnie-podzielic-dysk-hdd-ssd-na-partycje-pod-linux/</link>
      <pubDate>Fri, 15 Mar 2019 17:05:42 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/jak-optymalnie-podzielic-dysk-hdd-ssd-na-partycje-pod-linux/</guid>
      <description>&lt;p&gt;Ostatnio przeglądając nowe wpisy na forach trafiłem
na &lt;a href=&#34;https://forum.linuxmint.pl/showthread.php?tid=112&#34;&gt;pytanie o podział dysku&lt;/a&gt; pod instalację
linux&#39;a. Autorowi wątku chodziło o jak najlepszy podział dysku HDD ale najwyraźniej pogubił się on
w tym całym bałaganie informacyjnym, który tyczy się procesu partycjonowania nośnika pod kątem jego
optymalnego wykorzystania przez linux. Zagadnienie podziału dysków HDD/SSD nie jest zbytnio jakoś
skomplikowane, a mimo to wciąż pojawiają się pytania o poprawne przeprowadzenie tego procesu i to
pomimo faktu, że mamy obecnie już dość sporych rozmiarów dyski. To pytanie powoli przestaje mieć
jakikolwiek sens, przynajmniej jeśli chodzi o przeciętnego Kowalskiego instalującego linux&#39;a u
siebie na kompie (desktop/laptop). Postanowiłem jednak napisać parę słów na temat tego całego
podziału dysku na partycje, tak by dobrać optymalny ich rozmiar przy instalowaniu dowolnej
dystrybucji linux&#39;a.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Jak ukryć zaszyfrowany kontener LUKS pod linux</title>
      <link>https://morfikov.github.io/post/jak-ukryc-zaszyfrowany-kontener-luks-pod-linux/</link>
      <pubDate>Tue, 25 Oct 2016 19:30:23 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/jak-ukryc-zaszyfrowany-kontener-luks-pod-linux/</guid>
      <description>&lt;p&gt;Gdy w grę wchodzi poufność informacji, to przeciętny użytkownik komputera od razu zaczyna rozważać
szyfrowanie danych. Są różne narzędzia, które te kwestię realizują w mniejszym lub większym stopniu.
Kiedyś wszyscy korzystali z &lt;a href=&#34;http://truecrypt.sourceforge.net/&#34;&gt;TrueCrypt&lt;/a&gt; ale po jego dziwnych
przygodach ludzie stopniowo zaczęli od tego oprogramowania odchodzić. W jego miejscu zaczęły
pojawiać się różne forki, np. &lt;a href=&#34;https://veracrypt.codeplex.com/&#34;&gt;VeraCrypt&lt;/a&gt;. Abstrahując od tych ww.
narzędzi, w każdym linux&#39;ie mamy również dostępny &lt;a href=&#34;https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions&#34;&gt;mechanizm szyfrujący na bazie
LUKS&lt;/a&gt; i jego gołą wersję
wykorzystującą dm-crypt. Przy pomocy każdego z tych narzędzi jesteśmy w stanie zaszyfrować dysk
komputera, pendrive, czy nawet kartę SD, w taki sposób, by nikt inny nie uzyskał dostępu do danych
zgromadzonych na tych nośnikach informacji. Problem w tym, że w dalszym ciągu ktoś może nas
torturować, by wydobyć od nas hasło czy keyfile i uzyskać dostęp do tych zaszyfrowanych danych bez
większego trudu. Dlatego też pojawiło się coś nazwanego &lt;a href=&#34;https://en.wikipedia.org/wiki/Plausible_deniability&#34;&gt;Plausible
Deniability&lt;/a&gt;, gdzie wykorzystywane są tak
naprawdę dwa nośniki z czego jeden robi za przykrywkę, a na drugim mamy zgromadzone poufne pliki. W
ten sposób agresorowi podajemy hasło do trefnego kontenera i wszyscy są zadowoleni. Czy aby na
pewno?&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Dysk, pendrive i inne nośniki pod OpenWRT</title>
      <link>https://morfikov.github.io/post/dysk-pendrive-inne-nosniki-pod-openwrt/</link>
      <pubDate>Wed, 27 Apr 2016 00:32:19 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/dysk-pendrive-inne-nosniki-pod-openwrt/</guid>
      <description>&lt;p&gt;Czym by był router bez portów USB? Obecnie chyba wszystkie routery posiadają przy najmniej jeden
taki port. Umożliwia to podłączenie pendrive, dysku USB, drukarki i innych urządzeń posiadających
interfejs USB. W przypadku, gdy posiadamy jeden port USB i chcemy podłączyć dwa (lub więcej)
urządzenia, musimy skorzystać z hubów USB. Ja w przypadku swojego routera &lt;a href=&#34;http://www.tp-link.com.pl/products/details/TL-WR1043ND.html&#34;&gt;TP-LINK TL-WR1043N/ND
v2&lt;/a&gt; mam zastosowane właśnie takie
rozwiązanie. Niby potrzebuję trzy porty USB, a ten router ma tylko jeden. Co prawda, pojawia się
problem z zapotrzebowaniem na energię ale aktywne huby USB wyposażone w zasilacze niwelują tę
dolegliwość. Ten wpis ma na celu przedstawić zarządzanie tymi wszystkimi nośnikami pod OpenWRT.
Zostanie tutaj pokazane jak stworzyć i zamontować partycje o systemie plików EXT4, NTFS, FAT.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Backup dysku przez sieć przy pomocy dd i netcat</title>
      <link>https://morfikov.github.io/post/backup-dysku-przez-siec-przy-pomocy-dd-netcat/</link>
      <pubDate>Mon, 08 Feb 2016 00:45:07 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/backup-dysku-przez-siec-przy-pomocy-dd-netcat/</guid>
      <description>&lt;p&gt;Dyski talerzowe mają to do siebie, że zawierają elementy mechaniczne, np. ramię głowicy czy też sam
napęd dysku. Te ruchome elementy się zużywają podczas eksploatacji dysku i trzeba mieć na uwadze, że
prędzej czy później taki dysk ulegnie awarii. Statystycznie rzecz biorąc, około 5% dysków rocznie
zdycha. Oczywiście to tylko statystyka i w sporej części przypadków dyski twarde ulegają awarii
znacznie wcześniej. Niekoniecznie musimy mieć tutaj do czynienia z &lt;a href=&#34;https://pl.wikipedia.org/wiki/Planowane_starzenie&#34;&gt;planowanym postarzaniem
sprzętu&lt;/a&gt; i zwyczajnie możemy trafić na trefny
model, którego wada fabryczna wyjdzie po 2-3 miesiącach użytkowania. Poza tym, producenci dysków
implementują w nich te energooszczędne rozwiązania, które znacznie skracają żywotność nośników.
Można o tym przekonać się analizując &lt;a href=&#34;https://morfikov.github.io/post/parkowanie-glowicy-w-dyskach-wstern-digital/&#34;&gt;193 parametr SMART (Load/Unload Cycle) odpowiadający za
parkowanie głowicy&lt;/a&gt; w dyskach
firmy Western Digital. Także na dobrą sprawę nie możemy być pewni kiedy nam ten dysk zwyczajnie
odmówi posłuszeństwa. Dlatego też powinniśmy się zabezpieczyć na taką ewentualność robiąc kopię
bezpieczeństwa (backup) danych zawartych na dysku. W tym wpisie postaramy się zrobić kompletny obraz
dysku laptopa przy pomocy narzędzi &lt;code&gt;dd&lt;/code&gt; i &lt;code&gt;nc&lt;/code&gt; (netcat). Nie będziemy przy tym rozkręcać urządzenia
czy też podłączać do portu USB zewnętrznego nośnika. Dane prześlemy zwyczajnie przez sieć.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Jak dodać nowy dysk do LVM</title>
      <link>https://morfikov.github.io/post/jak-dodac-nowy-dysk-lvm/</link>
      <pubDate>Tue, 02 Feb 2016 16:21:08 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/jak-dodac-nowy-dysk-lvm/</guid>
      <description>&lt;p&gt;Rozmiary obecnych dysków twardych zwykliśmy już liczyć w TiB. Jest to dość sporo ale ciągle zdarzają
się sytuacje, gdzie zaczyna nam brakować miejsca na pliki. W takich przypadkach myślimy raczej o
zmianie rozmiaru istniejących już partycji czy też dokupieniu nowego dysku. Pierwsza z powyższych
opcji nie zawsze może wchodzić w grę, no chyba, że zaimplementowaliśmy sobie &lt;a href=&#34;https://pl.wikipedia.org/wiki/LVM&#34;&gt;LVM&lt;/a&gt;. Jeśli tak,
to możemy bez większego problemu &lt;a href=&#34;https://morfikov.github.io/post/zmiana-rozmiaru-lvm/&#34;&gt;zmieniać rozmiar każdego z tych voluminów LVM&lt;/a&gt;. Niemniej
jednak, nawet jeśli już dostosujemy sobie te wirtualne dyski, to miejsce wciąż może nam się
skończyć i raczej można przyjąć za pewne, że tak się stanie w bliżej nieokreślonej przyszłości. Gdy
to nastąpi, czeka nas druga opcja wymieniona wyżej, tj. zaopatrzenie się w dodatkowy nośnik danych.
Przy pomocy LVM jesteśmy w stanie ten nowy dysk dodać do istniejącej grupy voluminów i zwiększyć tym
wirtualnym partycjom rozmiar bez potrzeby przerywania pracy systemu, czy też wykonywania dodatkowych
czynności związanych z formatowaniem i instalowaniem systemu na nowo. W tym wpisie postaramy się
przebrnąć przez ten proces.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Zmiana identyfikatora UUID systemu plików EXT4 i kontenera LUKS</title>
      <link>https://morfikov.github.io/post/zmiana-identyfikatora-uuid/</link>
      <pubDate>Sat, 30 Jan 2016 16:52:05 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/zmiana-identyfikatora-uuid/</guid>
      <description>&lt;p&gt;&lt;a href=&#34;https://forum.dug.net.pl/viewtopic.php?id=28210&#34;&gt;Na forum DUG&#39;a po raz kolejny pojawił się post&lt;/a&gt; dotyczący unikalnych identyfikatorów, które są
nadawane partycjom dysków twardych. Nie wiem jak sprawa ma się w przypadku windowsów ale linux na
podstawie tych numerów &lt;a href=&#34;https://en.wikipedia.org/wiki/Universally_unique_identifier&#34;&gt;UUID&lt;/a&gt; i (&lt;a href=&#34;https://pl.wikipedia.org/wiki/Globally_Unique_Identifier&#34;&gt;GUID&lt;/a&gt;) jest w stanie identyfikować konkretne urządzenia.
Czasem się zdarza tak, że dwa dyski czy partycje mają taki sam identyfikator, co prowadzi zwykle do
problemów. Kolizja numerów identyfikacyjnych może być wynikiem pozostałości po procesie
produkcyjnym ale może także powstać za sprawą klonowania nośnika za pomocą narzędzia &lt;code&gt;dd&lt;/code&gt; . Tak czy
inaczej, przydałoby się wiedzieć jak ustalić, poprawnie wygenerować czy też zmienić UUID wszędzie
tam, gdzie jest on wykorzystywany i o tym będzie ten wpis.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Backup systemu przy pomocy LVM snapshot</title>
      <link>https://morfikov.github.io/post/backup-przy-pomocy-lvm-snapshot/</link>
      <pubDate>Fri, 15 Jan 2016 14:09:15 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/backup-przy-pomocy-lvm-snapshot/</guid>
      <description>&lt;p&gt;W dzisiejszych czasach systemy operacyjne są bardziej odporne na błędy niż to miało miejsce kilka
czy kilkanaście lat temu. Bardzo ciężko jest się zatem odnaleźć w sytuacji, gdzie nasz linux odmawia
współpracy i nie chce się w ogóle uruchomić. Niemniej jednak, jeśli chodzi o samą kwestię
naprawiania szkód po ewentualnej awarii systemu, to, jakby nie patrzeć, zajmuje ona nasz cenny czas.
Oczywiście takie błędy sprawiają, że mamy szansę nieco zgłębić strukturę używanego systemu
operacyjnego ale też pojawiają się one w najmniej oczekiwanym momencie. W takiej sytuacji nie ma
mowy byśmy siedzieli paręnaście minut i zastanawiali się nad tym dlaczego coś nie działa jak należy.
Jest kilka mechanizmów bezpieczeństwa, które mogą nam nieco czasu zaoszczędzić. W tym wpisie omówimy
sobie zagadnienia związane z &lt;a href=&#34;http://www.tldp.org/HOWTO/html_single/LVM-HOWTO/#snapshotintro&#34;&gt;LVM snapshot&lt;/a&gt;, czyli migawką systemu, którą możemy wykonać
praktycznie natychmiast i w razie problemów przywrócić system do stanu sprzed wprowadzenia w nim
zmian.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Temperatura dysku twardego (hddtemp)</title>
      <link>https://morfikov.github.io/post/temperatura-dysku-twardego-hddtemp/</link>
      <pubDate>Sun, 03 Jan 2016 16:24:45 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/temperatura-dysku-twardego-hddtemp/</guid>
      <description>&lt;p&gt;Obecnie dyski twarde nie są potrzebne do prawidłowego działania komputera. Mając sporo pamięci
operacyjnej oraz &lt;a href=&#34;https://pl.wikipedia.org/wiki/Live_CD&#34;&gt;system live&lt;/a&gt;, możemy bez problemu korzystać z takiego sprzętu. Niemniej jednak,
systemy live są nieco ograniczone. Najdotkliwszą ich wadą jest brak zapisywania wprowadzanych zmian.
W pewnych przypadkach ta cecha może być bardzo pożądana ale jeśli chodzi o przeciętnego użytkownika,
to chciałby on raczej mieć możliwość zapisu swojej pracy. Dlatego też zewnętrzny magazyn danych w
postaci dysku twardego nie prędko wyjdzie z użytku. Te urządzenia, jak i większość tych, które
podłączamy do naszego komputera, wydzielają ciepło. Temperatura jest wrogiem numer 1 w przypadku
maszyn i musi stale być monitorowana, tak by czasem nie doszło do przegrzania sprzętu.
&lt;a href=&#34;https://pl.wikipedia.org/wiki/Dysk_twardy&#34;&gt;Dyski HDD&lt;/a&gt; mają ten problem, że im wyższa jest temperatura, tym obszar magnetyczny się bardziej
rozszerza, a to powoduje błędy odczytu i zapisu. Podobnie jest ze zbyt niską temperaturą, gdzie
ścieżki i sektory ulegają skurczeniu. Taki dysk musi pracować w odpowiednich warunkach termalnych.
W tym wpisie postaramy się ustalić aktualną temperaturę dysku oraz spróbujemy ją monitorować, tak
by wiedzieć czy czynnik temperaturowy nie zagraża czasem dyskom podpiętym do naszego PC.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Kopia struktury dysku twardego</title>
      <link>https://morfikov.github.io/post/kopia-struktury-dysku-twardego/</link>
      <pubDate>Fri, 18 Dec 2015 17:01:12 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/kopia-struktury-dysku-twardego/</guid>
      <description>&lt;p&gt;Wszyscy wiedzą, że zabawa z dyskiem zwykle kończy się tragicznie dla zawartych na nim danych. W tym
wpisie spróbujemy się przyjrzeć sytuacjom, które nie jednego użytkownika linux&#39;a potrafią przyprawić
o zawał serca. Chodzi generalnie o uszkodzenie struktury dysku, oczywiście tylko tej programowej. Na
błędy fizyczne nie możemy zbytnio nic poradzić. Natomiast jeśli chodzi o sferę logiczną, to mamy
tutaj dość duże pole do popisu i jesteśmy w stanie się zabezpieczyć przed wieloma krytycznymi
sytuacjami. Postaramy się tutaj omówić to jak wykonać kopię dysku. Taka kopia będzie miała tylko
kilka (ew. kilkanaście) MiB, w skład której wchodzić będzie superblok systemu plików, nagłówki
zaszyfrowanych partycji LUKS, struktura LVM i tablica partycji. Uszkodzenie każdego z tych
powyższych uniemożliwia nam dostęp do danych zgromadzonych na dysku.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Zmiana rozmiaru dysków w strukturze LVM</title>
      <link>https://morfikov.github.io/post/zmiana-rozmiaru-lvm/</link>
      <pubDate>Thu, 17 Dec 2015 20:15:26 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/zmiana-rozmiaru-lvm/</guid>
      <description>&lt;p&gt;&lt;a href=&#34;https://pl.wikipedia.org/wiki/LVM&#34;&gt;Logical Volume Manager (LVM)&lt;/a&gt;, czyli menadżer voluminów
logicznych w systemach linux, to mechanizm, który jest w stanie podzielić jedną partycję fizyczną na
szereg dysków logicznych. Każdy z tych dysków może być programowo dostosowany bez potrzeby edycji
czy zmiany tablicy partycji fizycznego dysku. Dzięki LVM jesteśmy w stanie obejść kilka ograniczeń
płynących z wykorzystywania tablicy partycji MS-DOS. Głównie chodzi tutaj o 4 partycje podstawowe,
które mieszczą się w &lt;a href=&#34;https://pl.wikipedia.org/wiki/Master_Boot_Record&#34;&gt;MBR&lt;/a&gt;. Jeśli zdecydowaliśmy
się na wykorzystywanie LVM, to w pewnym momencie może okazać się, że niektóre voluminy mają zbyt
duże lub też zbyt małe rozmiary. Trzeba będzie je zatem dostosować i w tym wpisie postaramy się ten
proces zasymulować.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Zmiana rozmiaru kontenera LUKS</title>
      <link>https://morfikov.github.io/post/zmiana-rozmiaru-zaszyfrowanego-kontenera-luks/</link>
      <pubDate>Thu, 17 Dec 2015 18:38:25 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/zmiana-rozmiaru-zaszyfrowanego-kontenera-luks/</guid>
      <description>&lt;p&gt;Ci z nas, którzy zabezpieczają swoje systemy przy pomocy technik kryptograficznych wiedzą, że taki
system trzeba traktować nieco inaczej niż ten, który nie jest w żaden sposób zaszyfrowany. Gdy mamy
na swoim dysku kilka &lt;a href=&#34;https://pl.wikipedia.org/wiki/Linux_Unified_Key_Setup&#34;&gt;kontenerów LUKS&lt;/a&gt; (czy
też TrueCrypt), problematyczna może się okazać zmiana rozmiaru tego typu partycji. Praktycznie żadne
narzędzia graficzne, ewentualnie inne automaty, nie są w stanie nas przez ten proces bezstresowo
przeprowadzić. Musimy zatem skorzystać z niskopoziomowych aplikacji, takich jak &lt;code&gt;fdisk&lt;/code&gt; czy
&lt;code&gt;cryptsetup&lt;/code&gt; , by ten rozmiar sobie dostosować. Problem w tym, że nieumiejętne operowanie na tych
narzędziach może skończyć się tragicznie dla zgromadzonych na dysku danych. W tym wpisie postaram
się opisać cały proces zmiany rozmiaru zaszyfrowanego kontenera LUKS wliczając w to również
dostosowanie partycji i jej systemu plików.&lt;/p&gt;</description>
    </item>
    
  </channel>
</rss>
