Dotaz: I operace s bežným HDD může položit reakci systému

[lertimir]

Před časem jsme tu povídali jak operace nad pomalým filesystémem (flash) může položit reakci systému. Teď musím potvrdit, že je možné dostat systém do v podstatě nereagující stavu i operacemi nad HDD. V rámci opravy svého domaciho RAID pole jsem provedl rsync -a svého zálohovacihp oddílu z daty BackupPC systému. Teď po dokončení všeho jsem se je rozhodnul smazat. Příkaz rm -r * vpříslušném adresáři /zaloha/BackupPC jede již 45 minut a podle toho co mohu sledovat tak dříve než za hodinu neskončí. a co je nejhorší systém je nepoužitelný. Vše co píšu píšu naslepo a po cca minutě nebo dvou se řádek vysype z bufferu na obrazovku. Proto nemám silu opravovat žádné překlepy a ani čárky. Jsem si celkem vědom, že je to v podstatě ta nejhorší možná kombinace. backuppc vytvářístrom kdy v jedné větvi jsou všechny záléhované soubory zařazené podle hashů. v druhé vetvi jsou jednotlivá PC podnimi přislušné plné nebo inkrementální zálohy a ty jsou na hardlinkované do hashoové větve.(tedy jednotlivé soubory ve větmi pod zálohami jednotlivých pc jsou na hardlinkované na příslušné hashe. Pro mne má hashová větev asi milion souborů a na každý je mezi 5a25 hardlinky. takže i když je souborů cca milion smzatelných objektů ve stromu je cca 10-15 mil.mnohé z nich jsou mrnavé pod 500 bytů. jsou kompresované. a celé to sedí na v podstatě nejhorším možném filesystému, protože na zálohu v tomto objemu jsem neměl jinde místo než na mém multimediálním oddíle s XFS filesystémem. Vím že xfs má s mazáním mnoha malých souborů problémy a je pomalý, ale mne nevadí že je pomalý, ale to že v podstatě mi tohle mazání zastavilo systém. a nemohl jsem skoro nic psát.

Odpovědi

[inode cruncher]

To mas za to!

[rastos]

nice/ionice?

[lertimir]

Asi bych s tím něco dokázal, ale bylo už pozdě, tak jsem jen dopsal (i když obtížně) zprávu, šel spát, a nechal mazání doběhnout.. Před tím jsem o zamrzání systému při interakci s "pomalým zařízením" se bavili zde (Večer jsem článek nebyl schopen najít.). Tímhle jsem jen chtěl poznamenat, že do stavu "pomalého zařízení" se může dostat i HDD v nějaké neobvyklé situaci.

[marek_hb]

super viď? a to se nám pomalu blíží rok 2014 a náš operační systém budoucnosti umí takové krásné věci :)

[pavel]

To máš za to, že pro mazání takového množství souborů používáš nevhodné nástroje. Pro psaní dopisu použiji tužku a papír, pro tisk knihy by to ovšem nebylo "to pravé ořechové". Možná by stálo za to si postěžovat přímo u kováře, třeba to opraví.

[Tomáš Bžatek]

Mrkni na aktivni I/O scheduler, i takove CFQ se da tunit. Mozna jeste pomuze rozhazet procesy do patricnych cgroup.

Jinak mas pravdu, XFS je zkratka univerzalni a nezavdeci se vsem pouzitim. Na male soubory mam v produkcnim prostredi osvedceny reiserfs.

[AraxoN]

Rozumiem správne, že máš milióny súborov v jednom jedinom adresári? Mne niečo také položilo server - len vojsť do toho adresára (cd /var/blabla) trvalo minúty. Ak je niekde veľa súborov, je vhodné ich zoskupiť do menších adresárov.

[lertimir]

Ne. Je to uložené ve stromu. Pod základním adresářem s kompresovaými zálohovanými soubory, má BackupPC 3 úrovně adresářů odpovídající prvnímu druhému a třetímu znaku hashe (0-9,a-f) a teprve na třetí úrovni jsou vlastní soubory, je to stromek z 16 větvemi z každého uzlu. Takže těch adresářů v nichž jsou fakticky soubory je 4096 ((2^4)^3) a v každém adr je jen pár stovek souborů. V části kde je to jako vlastní zálohy počítače, adresářová struktura odpovídá struktuře zálohovaného stroje.

[Šangala]

A to se ti stalo na xfs?, ptám se proto, že když jsem to zkoušel, tak mi na xfs lépe dopadlo vytvořit 1M souborů do jednoho adresáře, než do struktury (ale fčul marně hledám čísla, bo to byl nedokončený „test“).

[AraxoN]

Myslím, že to bol ext3, ale bolo to už dávno...

[Šangala]

To pak jo, to jsem nezkoušel, jen pro zajímavost jdem si to na RAID1/LUKS/LVM/xfs zkusil:

test $ cat testfs-files 
#!/bin/bash
MAX=$1
for ((i=0;i<$MAX;i++)); do
  dd if=./testfile of="./test/F$i" bs=2048 2>/dev/null 
done
test $
test $ ls -l testfile | cut -d ' ' -f 5
2048
test $
test $
test $ time ./testfs-files 1000000
real	12m6.861s
user	0m40.989s
sys	1m1.892s
test $ time sync

real	0m0.454s
user	0m0.000s
sys	0m0.279s
test $ time du -sh test
3.9G	test

real	0m1.142s
user	0m0.317s
sys	0m0.825s
test $ time cd test

real	0m0.000s
user	0m0.000s
sys	0m0.000s
test $ time ls -1 | wc -l
1000000

real	0m1.468s
user	0m1.409s
sys	0m0.068s
test $ cd ..
test $ time find ./test -type f -delete

real	0m49.055s
user	0m0.540s
sys	0m29.257s
test $ 

[Šangala]

Zkusil jsem to i s ext4, paradoxně bylo rychlejší vytvoření (o slabou minutu), ale pak už vše pomalejší (zanedbatelně), ale poslední příkaz si vzal 29.5min - což už je pomalejší o sakramentsky víc (a pak, že je xfs pomalé při mazání :)).

[dustin]

Hodně asi bude záležet na verzi jádra, na XFS v poslední době dost zapracovali.

[Šangala]

To bude spíš tím find-em (rm -f ./test/* nelze použít na 1M souborů), ext4 podle mých zkušeností není šťastný s takového množství souboru v jednom adresáři, ale xfs to nevadí, naopak, jak jsem uvedl, vycházelo mi to lépe, než je zahnízďovat do struktury. Ext4 kdyby to měl ve struktuře, tak to smázne hned a xfs by to zas trvalo déle (si to tedy myslím, fčul jsem to nezkoušel).

Byl to CentOS 6.5 s distribučním jádrem, tedy staré dobré 2.6.32 (přiznám se, že nevím co tak „kjucí“ backportovali, nijak to nesleduji).

[dustin]

rm -f ./test/* nelze použít na 1M souborů

Je tam ještě několik úrovní podadresářů, do kterých jsou rozházené vlastní soubory, globbing to v pohodě vezme.

[Šangala]

Bavilo jsem se o svém výše (po vláknu) uvedeném testu, kde 1M souborů bylo v jedné složce.

Evidentně find -delete na ext4 z nějakého důvodu trval hnusně dlouho, ještě jsem si to zkusil bez něj a ze strukturou. Struktura je 63-63-252

                                       struct-ext4  struct-xfs  one-dir-ext4  one-dir-xfs      
create 63,63,252 | 1000188                 11:19.2     11:55.7       11:38.2      11:48.8
sync                                        0:00.2      0:01.1        0:00.2       0:00.4
du -sh test                                 0:01.4      0:00.9        0:02.0       0:01.2
find ./test -type f -name '*22' | wc -l     0:00.6      0:01.2        0:00.9       0:01.4
(sync && \
> echo 3 > /proc/sys/vm/drop_caches && \
> sleep 1 && \
> find ./test -type f -name '*22' \
> | wc -l)                                 0:20.0       1:29.6        0:38.7       0:37.8
(sync && \
> echo 3 > /proc/sys/vm/drop_caches && \
> sleep 1 && \
> rm -rf ./test/ )                         0:44.2       2:29.6        0:54.9       1:28.0

A potvrdila se má zkušenost, že xfs je šťastnější s mnoha soubory ve složce než ze strukturou a ext4 obráceně. (použil jsem zde rm na nadřazenou složku aby to bylo rm a stejně zadané).

Vytváření souborů v jednom adresáři jako výše, struktury takto:

#!/bin/bash
MAXL1=$1
MAXL2=$2
MAX=$3
for ((d1=0;d1"MAXL1;d1++)); do
  mkdir "./test/D${d1}"
  for ((d2=0;d2"MAXL2;d2++)); do
    mkdir "./test/D${d1}/d${d2}"
    for ((i=0;i"$MAX;i++)); do
      dd if=./testfile of="./test/D${d1}/d${d2}/F$i" bs=2048 2>/dev/null 
    done
  done
done