OVH Community, your new community space.

Samoistnie psujący się system plików


heniec
07-09-2012, 08:24
kolego tak naprawde pelne wsparcie dla ext4 jest dopiero w przypadku Centos-a od wersji 6 gdzie nie ma z nim najmniejszych problemow.

Spacedust
06-09-2012, 20:41
Problem znów się pojawił i to ma być to pełne wsparcie dla ext4 ?

Spacedust
01-09-2012, 23:24
Wgrałem najnowszy kernel CentOS'a i przeszło jak ręką odjął

2.6.18-308.13.1.el5

Spacedust
31-08-2012, 18:46
To jest chyba to:

In the ext4 file system, splitting an unwritten extent while using Direct I/O could fail to mark the modified extent as dirty, resulting in multiple extents claiming to map the same block. This could lead to the kernel or fsck reporting errors due to multiply claimed blocks being detected in certain inodes. In the ext4_split_unwritten_extents() function used for Direct I/O, the buffer which contains the modified extent is now properly marked as dirty in all cases. Errors due to multiply claimed blocks in inodes should no longer occur for applications using Direct I/O.

Spacedust
28-08-2012, 21:19
Cytat Napisał victor
Ale nie widzę zwiazku. 3 macierze to 3 razy tyle klikania, jedyny zysk jest taki że pojedyńcza szybciej sie odbuduje gdyby pozostały dysk miał paść.
Daje to większą niezawodność. W przypadku awarii systemu plików na partycji/macierzy z bazami danych, cały system nadal działa tak samo boot.

Poza tym można w prosty sposób odpiąć na chwilę macierz z MySQL i sprawdzić system plików, a tak musiałbym się przełączać na rescue.

victor
28-08-2012, 19:44
Cytat Napisał Spacedust
Mam 3 osobne macierze RAID1 i teraz np. mogę z łatwością podmienić sobie dysk na większy.
Ale nie widzę zwiazku. 3 macierze to 3 razy tyle klikania, jedyny zysk jest taki że pojedyńcza szybciej sie odbuduje gdyby pozostały dysk miał paść.

Spacedust
28-08-2012, 18:56
Cytat Napisał victor
I jaki masz zysk z posiadania partycji na ssd? Fragmentacja i tak nie opóźnia niczego.
Mam 3 osobne macierze RAID1 i teraz np. mogę z łatwością podmienić sobie dysk na większy.

victor
28-08-2012, 18:24
Cytat Napisał Spacedust
Mam dwa dyski SSD 120 GB i 3 partycje na nich. /boot, / i /var/lib/mysql
I jaki masz zysk z posiadania partycji na ssd? Fragmentacja i tak nie opóźnia niczego.

Spacedust
28-08-2012, 17:53
Cytat Napisał victor
A po co ci na tym 120GB dysku ssd mbr skoro zapewne masz tam jedną partycję
Mam dwa dyski SSD 120 GB i 3 partycje na nich. /boot, / i /var/lib/mysql

victor
28-08-2012, 17:50
Cytat Napisał Spacedust
Zgłosiłem bug do CentOS'a. To jest problem po stronie GPT. Mniejsza macierz 120 GB na tym samym serwerze i też na ext4 tylko z MBR działa bezbłędnie.
A po co ci na tym 120GB dysku ssd mbr skoro zapewne masz tam jedną partycję

Spacedust
28-08-2012, 16:08
Zgłosiłem bug do CentOS'a. To jest problem po stronie GPT. Mniejsza macierz 120 GB na tym samym serwerze i też na ext4 tylko z MBR działa bezbłędnie.

Spacedust
28-08-2012, 13:20
Cytat Napisał patrick
Podmień Kernel na coś świeższego np. 3.2, bo tu może być winny jak zauważyli poprzednicy centosowy 2.6.18 z backportem ext4
Z pewnością, ale akurat tą maszynę mam poza OVH i musiałbym samemu kompilować kernel.

patrick
28-08-2012, 13:15
Podmień Kernel na coś świeższego np. 3.2, bo tu może być winny jak zauważyli poprzednicy centosowy 2.6.18 z backportem ext4

Spacedust
28-08-2012, 10:46
Sprawdziłem dziś w nocy przez godzinkę system plików i póki co błędów nie ma

Update znowu są:

EXT4-fs error (device md2): ext4_mb_generate_buddy: EXT4-fs: group 19509: 20669 blocks in bitmap, 25166 in gd
JBD: Spotted dirty metadata buffer (dev = md2, blocknr = 0). There's a risk of filesystem corruption in case of system crash.

borec
24-08-2012, 10:26
No to masz, co lubisz

Spacedust
24-08-2012, 10:25
Cytat Napisał WMP
Ext4 z 2.6 to nie ten sam Ext4 co z 3.4/3.5
Jak stawiałem system to nie było jeszcze 3.4/3.5

Poza tym lubię używać oryginalnego jądra CentOS'a.

WMP
23-08-2012, 23:46
Ext4 z 2.6 to nie ten sam Ext4 co z 3.4/3.5

Spacedust
23-08-2012, 21:10
Cytat Napisał borec
Jakaś wczesna wersja ext4? Spróbuj z nowszym jądrem i przeformatowaniem świeżym e2fsprogs. A jak dalej będzie lipa spróbuj xfs.
Jądro: 2.6.18-308.4.1.el5 - CentOS 5.8 64-bit

e4fsck 1.41.12 (17-May-2010)
Używane EXT2FS Library version 1.41.12, 17-May-2010
Jest to zamontowane tak:

/dev/md2 /home ext4 rw,noatime,nodiratime,usrjquota=aquota.user,grpjqu ota=aquota.group,usrquota,grpquota,jqfmt=vfsv0 0 0

borec
23-08-2012, 21:01
Jakaś wczesna wersja ext4? Spróbuj z nowszym jądrem i przeformatowaniem świeżym e2fsprogs. A jak dalej będzie lipa spróbuj xfs.

Spacedust
23-08-2012, 16:46
Co jakiś czas wyrzuca mi coś takiego mimo, że serwer nie był restartowany od bardzo dawna, a wcześniej był prawidłowo zamykany:

EXT4-fs error (device md2): mb_free_blocks: double-free of inode 0's block 602618322(bit 14802 in group 18390)
EXT4-fs error (device md2): mb_free_blocks: double-free of inode 0's block 602618323(bit 14803 in group 18390)
EXT4-fs error (device md2): mb_free_blocks: double-free of inode 0's block 602618324(bit 14804 in group 18390)
JBD: Spotted dirty metadata buffer (dev = md2, blocknr = 0). There's a risk of filesystem corruption in case of system crash.
EXT4-fs error (device md2): ext4_mb_generate_buddy: EXT4-fs: group 18390: 6190 blocks in bitmap, 6245 in gd
JBD: Spotted dirty metadata buffer (dev = md2, blocknr = 0). There's a risk of filesystem corruption in case of system crash.
Na razie się wstrzymuje jeszcze ze sprawdzaniem plików, bo jest to macierz 3 TB z 1,7 GB danych, więc sprawdzanie dość długo by trwało, chociaż w nocy możnaby wyłączyć na jakieś 2-3 godzinki /home i sprawdzić

Dyski są OK.