Mám systém na mSATA SSD 125 Gb, někdy na něj odložím objemnější data. Pokud vytvořím image schnapps disku jeho velikost v desítkách Mp (80).Pokud takto vytvořený obraz exportuji, zahrne i odložené data a velikost je podle toho v desítkách Gb.
Myslím, že řešením by bylo rozdělení disku na partition, pak by snad schnapps při exportu nezahrnul druhou partition s velkými soubory.
Možná nevidím jaké informace vám chybí… každopádně hlavní háček vidím v tom, že budete nejspíš potřebovat tu současnou partition zmenšit, naštěstí i namountované btrfs by mělo jít snadno zmenšit. O zmenšení samotné živé partition si jistý nejsem… snad jo – a pak prostě vytvořit ve volném místě novou partition, nové btrfs, namountovat a přesunout samotná data.
Nemyslím že by šlo “rozdvojit historii snapshotů”. Celkově nečekám nic Turris-specifického, takže by mělo jít najít na jednotlivé kroky ty “návody pro hloupého” (v Angličtině alespoň). Leda mi přijde nepříjemné, že to mSATA asi nemáte jak vytáhnout a připojit k počítači pro “offline změny” (třeba gparted je pěkný a “pro hloupého”, řekl bych).
Ve Windows je pěkná správa disků, kde mohu systémovou partition zmenšit a v nealokovaném zbytku definovat partition pro data. To by se mi to líbilo.
Gparted si stáhnu a okouknu … mSATA sice vyndám, ale k přípojení bude třeba USB adapter.
Budu muset zvážit, zda efekt stojí za tu práci, ten prostor nějak extra nepotřebují - mám v sítí NAS na data a zálohy. Zase mi ten “obří disk” déle vydrží
Vyzkoušel jsem tuto možnost vytvořit subvolume (btrfs subvolume create /mnt/zkouska) někde v adresářové struktuře a potvrzuji, že schnapps create data v této složce (subvolume) nezahrne do vytvořené zálohy.
Cesta jak se potom zbavit nechtěných objemných dat v zálohách je jednoduchá, a to je přimountovat a vymazat je z nich.
Tak vyzkoušeno a ověřeno. Do subvolume /mnt/shareSSD jsem nakopíroval data cca 84 Mb vytvořil obraz 255 a exportoval ho s tímo výsledkem … schnapps opravdu subvolume přeskočí a export má správných 84 Mb. Pánové děkuji.
Subvolume stále sdílí stejný datový prostor btrfs na disku sda jako / , takže se budou započítávat do obsazenosti.
Mohlo se stát že mountovaný další disk (sdb) nebyl připojen k mountovanému adresáři a data se uložila na root disk (sda) a momentálně jsou skrytá už správně připojeným dalším diskem (sdb).
Taky by mohl nějaké velké obsazení ukázat příkaz btrfs fi du -s /*
Problém podle mne vznikl až po smazání prostého sdíleného adresáře s 30 Gb dat. Tojsem si “problému nevšiml” … až následně, když jsem udělal subvolume. Z toho odvozuji, že smazaný prostor není uvolněn a šel jsem na to trimem.
root@turris:~# btrfs fi du -s /*
Total Exclusive Set shared Filename
1.35MiB 0.00B 1.35MiB /bin
2.72MiB 0.00B 2.72MiB /boot
160.45MiB 0.00B 160.45MiB /core
ERROR: cannot check space of '/dev': Not a tty
2.53MiB 616.00KiB 1.93MiB /etc
0.00B 0.00B 0.00B /init
10.52MiB 0.00B 10.52MiB /lib
0.00B 0.00B 0.00B /mnt
ERROR: cannot check space of '/proc': Not a tty
0.00B 0.00B 0.00B /rom
0.00B 0.00B 0.00B /root
3.89MiB 0.00B 3.89MiB /sbin
725.78MiB 725.78MiB 0.00B /srv
ERROR: cannot check space of '/sys': Not a tty
ERROR: cannot check space of '/tmp': Not a tty
164.55MiB 0.00B 164.55MiB /usr
ERROR: cannot check space of '/var': Not a tty
216.00KiB 0.00B 216.00KiB /www
root@turris:~#
A toto je ta subvolume
root@turris:~# btrfs fi du -s /mnt*
Total Exclusive Set shared Filename
0.00B 0.00B 0.00B /mnt
root@turris:~# btrfs fi du -s /mnt/shareSSD*
Total Exclusive Set shared Filename
0.00B 0.00B 0.00B /mnt/shareSSD
root@turris:~#
Pokud do subvolume /mnt/shareSSD něco nakopíruji .
root@turris:~# btrfs fi du -s /mnt/shareSSD*
Total Exclusive Set shared Filename
676.40MiB 676.40MiB 0.00B /mnt/shareSSD
root@turris:~#
Ta data mohou být ještě v nějakém snappshotu, btrsf vytváří jenom odkazy na data která jsou stejná, neduplikuje je po disku. Takže pokud byla na / a mezitím se vytvořil nějaký snapshot, tak po smazání z / zůstávají nadále na disku pro ten snapshot.
Zkuste hledat v schnapps list ty co jsou velké přimountovat a vymazat je z nich.
To mne také napadlo, ale … pokud jsem dělal schnapshot v době kdy jsem měl na systémovém SSD disku velká uživatelská data 37 Gb … tak jsem proces vytváření přerušil hned na počátku po pár Mb.
Výpis nevypadá podezřele
root@turris:~# schnapps list
# | Type | Size | Date | Description
------+-----------+-------------+-----------------------------+------------------------------------
162 | rollback | 51.52MiB | 2019-12-26 13:14:38 +0100 | Rollback to snapshot 141
233 | rollback | 19.12MiB | 2020-03-01 16:38:59 +0100 | Rollback to snapshot 232
237 | single | 16.31MiB | 2020-03-05 21:07:53 +0100 | obrazky
240 | pre | 19.77MiB | 2020-03-07 10:30:29 +0100 | Automatic pre-update snapshot
241 | post | 19.80MiB | 2020-03-07 10:30:47 +0100 | Automatic post-update snapshot
242 | pre | 19.62MiB | 2020-03-07 16:39:52 +0100 | Automatic pre-update snapshot
243 | post | 19.51MiB | 2020-03-07 16:39:55 +0100 | Automatic post-update snapshot
245 | pre | 19.93MiB | 2020-03-12 13:28:12 +0100 | Automatic pre-update snapshot
247 | single | 19.72MiB | 2020-03-12 13:28:24 +0100 | 3.11.14
249 | single | 19.70MiB | 2020-03-12 13:33:00 +0100 | 3.11.15
250 | time | 20.30MiB | 2020-03-15 01:26:02 +0100 | Snapshot created by cron
251 | time | 20.30MiB | 2020-03-22 01:26:01 +0100 | Snapshot created by cron
252 | single | 20.36MiB | 2020-03-22 10:29:00 +0100 | 3.11.15
253 | single | 13.20MiB | 2020-03-24 20:04:16 +0100 | off shareSSD
254 | time | 13.14MiB | 2020-03-29 01:26:02 +0100 | Snapshot created by cron
255 | single | 13.20MiB | 2020-03-31 22:42:26 +0200 | shareSSD
root@turris:~#
.
240-252