Czy pliki krótkotrwałe są opróżniane na dysk?

Mój program tworzy wiele małych, krótkotrwałych plików. Zazwyczaj są one usuwane w ciągu sekundy po utworzeniu. Pliki znajdują się w systemie plików ext4 wspieranym przez prawdziwy dysk twardy. Wiem, że Linux okresowo opróżnia ( pdflush) brudne strony na dysk. Ponieważ moje pliki są krótkotrwałe, najprawdopodobniej nie są one buforowane pdflush. Moje pytanie brzmi: czy mój program powoduje wiele zapisów na dysku? Moje obawy dotyczą życia mojego dysku twardego.

Ponieważ pliki są małe, załóżmy, że suma ich wielkości jest mniejsza niż dirty_bytesi dirty_background_bytes.

Ext4 ma włączony domyślny dziennik, tj. Dziennik metadanych. Chcę również wiedzieć, czy metadane lub dane są zapisywane na dysku.

Prosty eksperyment z użyciem ext4:

Utwórz obraz 100 MB ...

# dd if=/dev/zero of=image bs=1M count=100
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 0.0533049 s, 2.0 GB/s

Zrób to z pętli ...

# losetup -f --show image
/dev/loop0

Utwórz system plików i zamontuj ...

# mkfs.ext4 /dev/loop0
# mount /dev/loop0 /mnt/tmp

Uruchom jakiś rodzaj plików z plikami krótkotrwałymi. (Zmień to na dowolną preferowaną metodę).

for ((x=0; x<1000; x++))
do
    (echo short-lived-content-$x > /mnt/tmp/short-lived-file-$x
     sleep 1
     rm /mnt/tmp/short-lived-file-$x ) &
done

Umount, synchronizacja, odpięcie.

# umount /mnt/tmp
# sync
# losetup -d /dev/loop0

Sprawdź zawartość obrazu.

# strings image | grep short-lived-file | tail -n 3
short-lived-file-266
short-lived-file-895
short-lived-file-909
# strings image | grep short-lived-content | tail -n 3

W moim przypadku wymieniono wszystkie nazwy plików, ale nie zawierała żadnej zawartości pliku. Więc tylko treść nie została napisana.

O ile nie mówimy o napędzie półprzewodnikowym, duża liczba zapisów na dysku nie będzie dominującym czynnikiem długowieczności dysku.

Jeśli naprawdę chcesz w ogóle uniknąć zapisu na dysku, zajrzyj do tmpfs ,

Zasadniczo nie, nie zostaną napisane. Wynika to z faktu, że pamięć podręczna opróżnia brudne strony, gdy spełniony jest jeden z dwóch warunków:

1. Dane są przedawniane /proc/sys/vm/dirty_writeback_centisecs, co domyślnie wynosi 5 sekund.

2. Jest za mało pamięci, aby pamięć podręczna mogła pomieścić dane, więcej niż dirty_ratiobrudne strony w pamięci podręcznej (domyślnie 20%).

Tak więc w systemie z dużą ilością wolnej pamięci i małym ruchem zapisu poza małymi plikami, które są usuwane w mniej niż 5 sekund, dane nie zostaną usunięte.

To, czy pliki krótkotrwałe zostaną zapisane na dysk, zależy nie tylko od domyślnego zachowania pamięci podręcznej plików jądra, ale także od szczegółów implementacji sterownika systemu plików i opcji montowania wspomnianego systemu plików. Możliwe jest skonfigurowanie systemu w taki sposób, aby wszystko zawsze było natychmiast zapisywane na dysk (w zasadzie zachowanie DOS).

Jednym z systemów plików, z wyraźnym zachowaniem, które Cię interesuje (tzw. „Opóźniony przydział”), jest XFS. Dzięki niemu możesz być mniej lub bardziej pewien (pod żadnym pozorem żadnych śmiesznych opcji konfiguracji), że bloki należące do właśnie usuniętych plików zostaną ponownie wykorzystane w pamięci bez pośredniego dostępu do dysku. XFS może nadal chcieć aktualizować swój dziennik metadanych (który będzie zapisywany dość często na dysku; jednak biorąc pod uwagę, że dziennik XFS to tylko metadane, jest wystarczająco mały, aby ustawić go na innym, szybkim urządzeniu, takim jak znaleziona pamięć RAM podtrzymywana bateryjnie na wielu kontrolerach RAID).

Z powodu tego zachowania nierzadko zdarza się, aby znaleźć całkowicie wyzerowane, ale poza tym prawnie wyglądające pliki (rozmiar i inne nienaruszone metadane) w systemie plików XFS po nagłej przerwie w zasilaniu. Taki jest koszt obsługi szybkich „pół-tymczasowych” operacji na plikach.

Trochę teorii

Zasadniczo wywołanie systemowe uzyskujące dostęp do systemu plików kończy się dość szybko w metodzie zdefiniowanej przez sterownik systemu plików (dołączonej do „struct inode_operations” i „struct file_operations” po zarejestrowaniu sterownika VFS). To, co dzieje się później, zależy wyłącznie od implementacji systemu plików. Zazwyczaj stosuje się coś podobnego do następującego podejścia (ten prosty przykład pochodzi ze sterownika FAT dla Linuksa):

if (IS_DIRSYNC(dir))
    (void)fat_sync_inode(dir);
else
    mark_inode_dirty(dir);

Jeśli system plików jest zamontowany w trybie „synchronizacji”, wszystkie zmiany są natychmiast przenoszone na dysk (w tym przypadku przez fat_sync_inode ()). W przeciwnym razie blok jest oznaczony jako „brudny” i pozostaje w pamięci podręcznej pamięci, dopóki nie zostanie opróżniony przy rozsądnej okazji.

Dlatego nie można przewidzieć zachowania systemu w odniesieniu do plików przejściowych bez uwzględnienia opcji montowania systemu plików i sprawdzenia kodu źródłowego jego implementacji (dotyczy to oczywiście wszystkich rodzajów egzotycznych systemów plików najczęściej znajdujących się w przestrzeni osadzonej) .