Portál AbcLinuxu, 8. května 2025 08:10
ls -l ~/.local/share/baloo/ celkem 25567864 -rw-r--r-- 1 palovsky palovsky 18102980400611328 29. čec 14.39 index -rw-r--r-- 1 palovsky palovsky 8192 29. čec 14.39 index-lockJo, je to několika tisíckrát více než mám celý diskový prostor a pochopitelně to žádná záloha neudělá. Nerozumí tomu někdo?
# velikost volume df -h ... /dev/mapper/system 230G 221G 8,4G 97% /home ... # vytvoříme prázdný soubor o velikosti 5TB truncate -s 5T /home/test.img # ověříme, že má 5TB du -bhc /home/test.img 5,0T /home/test.img 5,0T celkem # koukneme přes ls ls -l /home/test.img -rw-r--r-- 1 max max 5497558138880 29. čec 15.16 /home/test.img # smažeme rm -f /home/test.imgNemusí tedy nutně jít o chybu na filesystému. Může se jednat i o nějaký bug v Baloo.
du -sh ~/.local/share/baloo/index
Jo, je to několika tisíckrát více než mám celý diskový prostor a pochopitelně to žádná záloha neudělá. Nerozumí tomu někdo?
To↑ jsou hned dva nesmysly v jednom odstavci. Udávaná velikost souboru přece nemusí nijak souviset s velikostí diskového prostoru. Existují řídké soubory, podobně jako existuje řídká stolice.
Každopádně, automatické zálohování nikdy nesmí kvůli řídkým souborům padat; musí si s nimi umět korektně poradit, tj. (1) detekovat a zachovat mezery v souborech a případně (2) z už alokovaných nulových bloků vytvořit nové mezery.
Takže na úvod a především bych zkontroloval (a raději zahodil a nahradil) onen automatický zálohovací mechanismus, který je zjevně rozbitý a neporadí si s obyčejným řídkým souborem. Já mám například na 2 TB SSD cca dvacet virtuálek a každá z nich má virtuální disk o (neméně virtuální) velikosti 1 až 10 TB. Jakpak se tam asi vejdou? Jakpak se asi zálohují? Inu, normálně; řídké soubory jsou úplně běžná věc. (Rozumné atomické zálohování typu btrfs send
/ btrfs receive
s nimi pracuje bez problémů a na úrovni souborového API s nimi umí pracovat třeba rsync
.)
K původnímu problému: Ano, Baloo je zabugovaný odpad, kterému je dobré se vyhnout. Moje hypotéza ohledně toho, co se stalo: Zase se projevil jeden z mnoha bugů, nějaké číslo přeteklo či podteklo, nastal
lseek64()
do ohromné dálky a následně pak pár zápisů v té ohromné dálce. Což bohužel samozřejmě uspělo, protože … řídké soubory jsou běžná věc.
Tak schválně, jestlipak mám 8 exabytů minus 1 byte „místa“, jo? A navíc klidně dvakrát.
$ truncate -s 9223372036854775807 huge $ du -shb huge 9223372036854775807 huge $ du -sh huge 0 huge $ cp huge also_huge $ du -shb huge also_huge 9223372036854775807 huge 9223372036854775807 also_huge $ du -sh huge also_huge 0 huge 0 also_huge $ rm huge also_huge
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.