Forum Debian Users Gang

FranzMakamele · 2021-03-06 23:12:33

Jeszcze Was trochę pomęczę.
Dodałem do systemu dysk HDD 8TB na magazyn danych. Na całości utworzona jest jedna partycja a na niej PV.
Utworzone są 3 woluminy.

root@srv1:/home/irek# pvdisplay
--- Physical volume ---
PV Name /dev/sdb1
VG Name volgr1
PV Size <7,28 TiB / not usable <4,32 MiB
Allocatable yes
PE Size 4,00 MiB
Total PE 1907720
Free PE 229384
Allocated PE 1678336
PV UUID lrTbsU-op0R-6fky-LDTB-KwYH-am2p-PWPS9o

vgs
VG #PV #LV #SN Attr VSize VFree
volgr1 1 3 0 wz--n- <7,28t 896,03g

lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
volsrv volgr1 -wi-ao---- <6,35t
volswap volgr1 -wi-ao---- 24,00g
voltmp volgr1 -wi-ao---- 32,00g

/etc/fstab wygląda tak:

# <file system> <mount point> <type> <options> <dump> <pass>
UUID=b7156a11-6ba5-4908-b89f-1b4341d859c7 / ext4 errors=remount-ro 0 1

# /boot was on /dev/sda1 during installation
UUID=9b9498af-c2f4-420e-9e7f-92e9cd4635d3 /boot ext4 defaults 0 2

/dev/mapper/volgr1-volswap none swap sw 0 0
/dev/mapper/volgr1-voltmp /tmp ext4 defaults,nodev,nosuid,noexec 0 2
/dev/mapper/volgr1-volsrv /srv ext4 defaults 0 2
/dev/sr0 /media/cdrom0 udf,iso9660 user,noauto 0 0

Problem jest taki że dioda dysku w ogóle nie gaśnie, słychać pracującą głowicę i gdyby nie wentylator byłby on gorący. Głowica rzęzi cały czas.

W katalogu /srv jest zaledwie 300MB danych, z których na razie nie korzysta żadna usługa bo jeszcze żadnej nie podłączyłem do tego katalogu.

Po odmontowaniu /srv dysk się uspokaja. Wolumin tym się różni od pozostałych że jest spory - ma wielkość 6,35TB
Z tego PV zamontowany jest jeszcze wolumin swap i /tmp ale one nie sprawiają problemów.

Udało mi się ustalić że sprawcą zamieszania są procesy jbd2
Poniżej wynik pidstat -dl 15

22:46:03 UID PID kB_rd/s kB_wr/s kB_ccwr/s iodelay Command
22:46:18 0 65 0,00 0,00 0,00 2 kworker/1:1-mm_percpu_wq
22:46:18 0 192 0,00 0,00 0,00 1 kworker/0:2-events
22:46:18 0 215 0,00 1,33 0,00 0 jbd2/sda2-8
22:46:18 0 432 0,00 0,27 0,00 8 jbd2/dm-2-8
22:46:18 0 434 0,00 0,00 0,00 19 ext4lazyinit

22:46:18 UID PID kB_rd/s kB_wr/s kB_ccwr/s iodelay Command
22:46:33 0 65 0,00 0,00 0,00 2 kworker/1:1-events_freezable_power_
22:46:33 0 66 0,00 0,00 0,00 1 kworker/3:1-mm_percpu_wq
22:46:33 0 192 0,00 0,00 0,00 2 kworker/0:2-events
22:46:33 0 432 0,00 0,53 0,00 11 jbd2/dm-2-8
22:46:33 0 434 0,00 0,00 0,00 18 ext4lazyinit

22:46:33 UID PID kB_rd/s kB_wr/s kB_ccwr/s iodelay Command
22:46:48 0 65 0,00 0,00 0,00 2 kworker/1:1-mm_percpu_wq
22:46:48 0 192 0,00 0,00 0,00 2 kworker/0:2-events
22:46:48 0 215 0,00 0,53 0,00 1 jbd2/sda2-8
22:46:48 0 432 0,00 0,27 0,00 15 jbd2/dm-2-8
22:46:48 0 434 0,00 0,00 0,00 19 ext4lazyinit

Średnia: UID PID kB_rd/s kB_wr/s kB_ccwr/s iodelay Command
Średnia: 0 65 0,00 0,00 0,00 2 kworker/1:1-mm_percpu_wq
Średnia: 0 66 0,00 0,00 0,00 0 kworker/3:1-events_power_efficient
Średnia: 0 192 0,00 0,00 0,00 2 kworker/0:2-events
Średnia: 0 215 0,00 0,62 0,00 0 jbd2/sda2-8
Średnia: 0 432 0,00 0,36 0,00 11 jbd2/dm-2-8
Średnia: 0 434 0,00 0,00 0,00 19 ext4lazyinit

oraz iostat -dx /dev/mapper/volgr1-volsrv 15

Device r/s w/s rkB/s wkB/s rrqm/s wrqm/s %rrqm %wrqm r_await w_await aqu-sz rareq-sz wareq-sz svctm %util
dm-2 1,02 6,43 9,10 2886,47 0,00 0,00 0,00 0,00 5,14 3,01 0,02 8,92 448,64 2,73 2,03

Device r/s w/s rkB/s wkB/s rrqm/s wrqm/s %rrqm %wrqm r_await w_await aqu-sz rareq-sz wareq-sz svctm %util
dm-2 0,00 6,60 0,00 2938,93 0,00 0,00 0,00 0,00 0,00 2,55 0,02 0,00 445,29 2,55 1,68

Device r/s w/s rkB/s wkB/s rrqm/s wrqm/s %rrqm %wrqm r_await w_await aqu-sz rareq-sz wareq-sz svctm %util
dm-2 0,00 6,67 0,00 2939,20 0,00 0,00 0,00 0,00 0,00 3,24 0,02 0,00 440,88 3,24 2,16

Device r/s w/s rkB/s wkB/s rrqm/s wrqm/s %rrqm %wrqm r_await w_await aqu-sz rareq-sz wareq-sz svctm %util
dm-2 0,00 6,20 0,00 2869,60 0,00 0,00 0,00 0,00 0,00 2,97 0,02 0,00 462,84 2,97 1,84

Device r/s w/s rkB/s wkB/s rrqm/s wrqm/s %rrqm %wrqm r_await w_await aqu-sz rareq-sz wareq-sz svctm %util
dm-2 0,00 6,67 0,00 2939,20 0,00 0,00 0,00 0,00 0,00 2,88 0,02 0,00 440,88 2,88 1,92

iotop --delay 1 też pokazuje mi cały czas ok 3M/s zapisu. Odczyt wynosi 0.

Możecie coś doradzić jak to zdiagnozować i usunąć?

Szukałem pół dnia ale nie znalazłem żadnego konkretnego algorytmu postępowania i diagnostyka tego mnie przerosła :(
W ostateczności wywalę lvm-a ale z racji rozmiaru magazynu danych wolałbym go jednak zachować aby móc łatwo regulować wielkościami woluminów. Być może że inne katalogi będą tam w przyszłości zamontowane.

Jak się dowiedzieć co on tam robi? Buduje jakieś indeks dla LVM albo zapisuje dzienniki systemu plików? Czy to jest normalne zachowanie? Nigdy nie używałem tak dużego woluminu.
Zostawić go na kilka godzin i się uspokoi? W takim stanie nie da się go używać bo ten dysk padnie.

Ktoś coś?
Dziękuję.

Ostatnio edytowany przez FranzMakamele (2021-03-08 09:38:29)

FranzMakamele · 2021-03-07 14:12:41

Urwał nać, przerobiłem na zwykłe partycje i jest jeszcze gorzej - objawy te same co powyżej
Załamka :/

FranzMakamele · 2021-03-07 15:49:26

Po dalszych walkach:
- fatrace - pokazał nic - żaden proces z przestrzeni użytkownika nie sięgał do tego dysku
- przetestowane różne opcje montowania - data=ordered, commit,noatime - bez zmian
- stworzenie kolejnej małej - 500MB partycji - zachowuje się tak samo.

W końcu zmieniłem system plików na reiserFS - pomogło - nastała cisza.
Wygląda na jakiś błąd w modułach kernela w połączeniu z ext4 + może jakieś specyficzności w elektronice dysku lub kontrolera, cóż pech.

No to reraz proszę o poradę - jaki system plików wybrać. Magazyn będzie przechowywał katalog /data serwera Nextcloud a na nim prawdopodobnie dużą liczbę raczej niewielkich plików biurowych - doc pdf xls etc.... Może też na niego trafić partycja /var z bazami danych do aplikacji.

reiserFS - nadaje się do tego celu, ale rozwój porzucony (?) i nie wiem jak w 2021 się prezentuje. Lata temu używałem na desktopie i sobie chwaliłem.
BTRFS - piszą że nie nadaje się jeszcze na systemy produkcyjne,
ZFS - nie chcę niczego z backportów
XFS? ??

No i kwestia dostępności/funkcjonalności narzędzi do tych systemów plików w Debianie. Nie interesują mnie tabelki i zestawienia bo te sobie sprawdzę tylko wasze doświadczenia sz tymi systemami.

Dziękuję

Ostatnio edytowany przez FranzMakamele (2021-03-07 15:53:53)

morfik · 2021-03-07 17:46:22

jbd2, to wątek kernela aktualizujący dziennik systemu plików -- coś ci tam do niego ciągle trafia i temu masz problem. LVM nic nie ma tutaj do rzeczy. W jaki sposób formatowałeś ten volumin? Sprawdź też jakie pliki ostatnio były zmieniane w tym voluminie.

Ostatnio edytowany przez morfik (2021-03-07 17:49:09)

FranzMakamele · 2021-03-07 18:09:00

Ad1.
mke2fs -t ext4 -L etykieta /dev/sdb3

Ad2. Żadne pliki nie były zmieniane. Nawet na pustych partycjach tak robi. Kasowałem i tworzyłem nowe, montowałem pod różnymi punktami - i zaraz po zamontowaniu zaczyna pisać bez końca ok 3MB/s. Testowałem różne wielkości partycji - i przy kilkudziesięciu GB na ext4 jest spokój - przy 200-300 zaczyna pisać.
Też doszedłem już do tego że LVM nie ma wpływu :)

Powertop nie pokazuje żadnego procesu, który wzbudzałby aktywność dysku (w idl-u). Weryfikowałem go czy działa - kopiując pliki na tę partycję - i pięknie pokazywał żądania dostępu i procesy.

Czas mnie goni - wolumin na magazyn 6TB sformatowałem pod reiserFS - zamontowałem, wrzuciłem dane - jest OK.

Zostawiłem sobie 1TB wolnego miejsca na dalsze eksperymenty bo mi nie da spokoju dopóki tego nie rozwiążę.

morfik · 2021-03-07 18:24:40

Sformatuj jeszcze raz tę dużą partycję. Zamontuj i zostaw to na parę godzin (1h/1TiB), niech sobie popracuje. Gadają, że po zapisie całej partycji uspokoi się. xD

Ewentualnie też formatnij ten volumin takimi opcjami:

Kod:

# mke2fs -O 64bit,has_journal,extents,huge_file,flex_bg,uninit_bg,dir_nlink,extra_isize -E lazy_itable_init=0,lazy_journal_init=0

Generalnie chodzi o to, że takie duże partycje formatowane systemem plików ext4 muszą się w pełni zainicjować. I można to zrobić na dwa sposoby. Pierwszym z nich jest podanie tych dodatkowych opcji lazy_itable_init=0,lazy_journal_init=0 i wtedy tworzenie systemu plików potrwa trochę dłużej. A można też od razu utworzyć system plików i niech ten proces inicjacji się dokona w późniejszym czasie i zapewne to zachowanie obserwujesz. xD

Ostatnio edytowany przez morfik (2021-03-07 18:52:33)

FranzMakamele · 2021-03-07 19:06:41

Ok. Dam mu szansę - na pozostałej 1TiB przestrzeni zrobię partycję - na razie bez tych opcji i zostawię to wszystko na noc.
W drugiej kolejności wypróbuję z tymi opcjami.

Jak się uspokoi to to samo zrobię z tą dużą dając odpowiednio więcej czasu . Dzięki

Ostatnio edytowany przez FranzMakamele (2021-03-07 19:10:25)

FranzMakamele · 2021-03-07 20:59:12

To jest to co mówisz - iotop mówi, że procesami obciążającymi są jbd2 i ext4lazyinit
Idę spać a ten niech mieli. zobaczymy co się urodzi.

FranzMakamele · 2021-03-07 21:56:23

Lazy Initialization

When creating an Ext4 file system, the existing regions of the inode tables must be cleaned (overwritten with nulls, or "zeroed"). The "lazyinit" feature should significantly accelerate the creation of a file system, because it does not immediately initialize all inode tables, initializing them gradually instead during the initial mounting process in background (from Kernel version 2.6.37).[18][19] Regarding this see the extracts from the mkfs.ext4 man pages:[20]

If enabled and the uninit_bg feature is enabled, the inode table will not be fully initialized by mke2fs. This speeds up file system initialization noticeably, but it requires the kernel to finish initializing the file system in the background when the file system is first mounted. If the option value is omitted, it defaults to 1 to enable lazy inode table zeroing.

One should be careful when testing the performance of a freshly created file system. The "lazy initialization" feature may write a lot of information to the hard disk after the initial mounting and thereby invalidate the test results. At first, the "ext4lazyinit" kernel process writes at up to 16,000kB/s to the device and thereby uses a great deal of the hard disk’s bandwidth (see also I/O Statistics by Process). In order to prevent lazy initialization, advanced options are offered by the mkfs.ext4 command:[20]

mkfs.ext4 -E lazy_itable_init=0,lazy_journal_init=0 /dev/mapper/fc-root

By specifying these options, the inodes and the journal will be initialized immediately during creation

morfik · 2021-03-07 22:31:16

No tylko taki format zajmie z pół godziny albo i więcej jeśli większa partycja. xD

FranzMakamele · 2021-03-08 09:38:06

Zrobił wszystko w nocy - jest OK
Dziękuję za pomoc!

Forum Debian Users Gang

Ogłoszenie

#1 2021-03-06 23:12:33

FranzMakamele - Użytkownik

[Solved] Wolumin LVM - ciągła aktywność dysku - jbd2/dm

#2 2021-03-07 14:12:41

FranzMakamele - Użytkownik

Re: [Solved] Wolumin LVM - ciągła aktywność dysku - jbd2/dm

#3 2021-03-07 15:49:26

FranzMakamele - Użytkownik

Re: [Solved] Wolumin LVM - ciągła aktywność dysku - jbd2/dm

#4 2021-03-07 17:46:22

morfik - Cenzor wirtualnego świata

Re: [Solved] Wolumin LVM - ciągła aktywność dysku - jbd2/dm

#5 2021-03-07 18:09:00

FranzMakamele - Użytkownik

Re: [Solved] Wolumin LVM - ciągła aktywność dysku - jbd2/dm

#6 2021-03-07 18:24:40

morfik - Cenzor wirtualnego świata

Re: [Solved] Wolumin LVM - ciągła aktywność dysku - jbd2/dm

Kod:

#7 2021-03-07 19:06:41

FranzMakamele - Użytkownik

Re: [Solved] Wolumin LVM - ciągła aktywność dysku - jbd2/dm

#8 2021-03-07 20:59:12

FranzMakamele - Użytkownik

Re: [Solved] Wolumin LVM - ciągła aktywność dysku - jbd2/dm

#9 2021-03-07 21:56:23

FranzMakamele - Użytkownik

Re: [Solved] Wolumin LVM - ciągła aktywność dysku - jbd2/dm

#10 2021-03-07 22:31:16

morfik - Cenzor wirtualnego świata

Re: [Solved] Wolumin LVM - ciągła aktywność dysku - jbd2/dm

#11 2021-03-08 09:38:06

FranzMakamele - Użytkownik

Re: [Solved] Wolumin LVM - ciągła aktywność dysku - jbd2/dm

Stopka forum