<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Chromium on Morfitronik</title>
    <link>https://morfikov.github.io/tags/chromium/</link>
    <description>Recent content in Chromium 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/chromium/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>
    
  </channel>
</rss>
