LINUX.ORG.RU

Выбор ФС с адекватным журналом

 ,


0

1

Есть проблема с внезапными перезагрузками.

Но меня доканала проверка ФС на винтах(медленно) при каждой внезапной перезагрузке.

на винтах монтирован не корень, а всякие торренты и прочий медиаконтент. суть в том, что пишется туда что-то очень редко. инфа 100%.
Однако, Однако! при каждом внезапном ребуте убунта начинает гонять проверку раздела, что при частых перезагрузках начинает дико напрягать. это поведение (системд) убунту или самой ext4?

Как противоположный пример приведу винду с нтфс, которая чекает раздел, лишь когда проблемы со структурой есть реально - то есть работа с журналом реализована корректно.
вот записи в фстаб, не вижу опций, заставляющих чекать при каждом ребуте.

UUID=b76a8b7f-e584-48dd-9043-7e62482b0477 /media/gmslin   ext4    user,rw,exec,user_xattr         0       0
UUID=000db230-0bae-4a72-925c-f00634ed7c85 /media/B5       ext4    user,rw,exec,user_xattr       0       2

это поведение (системд) убунту или самой ext4?

ext4 вряд ли. Если неудачно задеть usb-кабель внешнего диска, то в dmesg появляется:

...
kernel: [956212.031774]  sdd: sdd1 sdd2
kernel: [956212.039341] sd 8:0:0:0: [sdd] Attached SCSI disk
kernel: [956214.645149] EXT4-fs (sdd1): recovery complete
kernel: [956214.649813] EXT4-fs (sdd1): mounted filesystem with ordered data mode. Opts: (null)
kernel: [956216.770532] EXT4-fs (sdd2): recovery complete
kernel: [956216.771466] EXT4-fs (sdd2): mounted filesystem with ordered data mode. Opts: (null)
gag ★★★★★ ()
Ответ на: комментарий от Deleted

man fsck.ext4

       ... For
       ext3 and ext4 filesystems that use a journal, if the  system  has  been
       shut  down  uncleanly without any errors, normally, after replaying the
       committed transactions  in the  journal,  the  file  system  should  be
       marked  as clean.   Hence, for filesystems that use journalling, e2fsck
       will normally replay the journal and exit, unless its superblock  indi‐
       cates that further checking is required.
gag ★★★★★ ()

начинает гонять проверку раздела, что при частых перезагрузках начинает дико напрягать. это поведение (системд) убунту или самой ext4?

Выбор идиотских файловых систем приводит к этому. Использовать что-либо кроме BTRFS или ZFS это глупость.

anonymous ()

Я думаю, проблема в убунту и/или неправильной настройке системы.
У меня много дисков, systemd, md raid, ext4, xfs и btrfs, все в одном компе, есть внезапные ребуты из-за видеокарты amd, но таких проблем нет.

Khnazile ★★★★★ ()

Проверка после каждого внезапного ребута - это не есть норма для ext4 и даже ext3. Это было нормой для etx2. Можно посмотреть настройки при помощи tune2fs - как часто должна делаться принудительная проверка.

Можно попробовать xfs - в последние 1-2 года было много вливаний в нее со стороны разработчиков, и сам Линус был плотно вовлечен.

Deleted ()
Ответ на: комментарий от Rx0

А какое ядро не делает вот так:

[drm:amdgpu_dm_commit_planes.constprop.0 [amdgpu]] *ERROR* Waiting for fences timed out!
[drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, signaled seq=7996962, emitted seq=7996964
<Далее неудачный gpu reset и простыня ошибок>
5.4 точно делает.

Khnazile ★★★★★ ()
Ответ на: комментарий от Khnazile

dmesg свой покажи.

[    2.997397] [drm] amdgpu kernel modesetting enabled.
[    3.003509] fb0: switching to amdgpudrmfb from EFI VGA
[    3.004438] amdgpu 0000:01:00.0: vgaarb: deactivate vga console
[    3.007037] amdgpu 0000:01:00.0: No more image in the PCI ROM
[    3.007598] amdgpu 0000:01:00.0: VRAM: 2048M 0x000000F400000000 - 0x000000F47FFFFFFF (2048M used)
[    3.007601] amdgpu 0000:01:00.0: GART: 1024M 0x000000FF00000000 - 0x000000FF3FFFFFFF
[    3.007710] [drm] amdgpu: 2048M of VRAM memory ready
[    3.007714] [drm] amdgpu: 3072M of GTT memory ready.
[    3.008746] amdgpu: [powerplay] hwmgr_sw_init smu backed is ci_smu
[    3.481064] [drm] amdgpu atom DIG backlight initialized
[    5.012394] fbcon: amdgpudrmfb (fb0) is primary device
[    5.565387] amdgpu 0000:01:00.0: fb0: amdgpudrmfb frame buffer device
[    5.578766] [drm] Initialized amdgpu 3.36.0 20150101 for 0000:01:00.0 on minor 0
Rx0 ()
Ответ на: комментарий от Rx0

Не думаю, что в этом будет толк. В баг-трекере есть как минимум 3 очень похожих бага, оставленных другими пользователями, по ним есть ответы от Alex Deucher и Pierre-Eric Pelloux-Prayer, разработчиков драйвера из АМД, но даже они ничего толкового посоветовать не смогли.

Khnazile ★★★★★ ()

Вообще если начинается неведомая хрень с целостностью ФС надо проверить хватает ли питания винту и бэдблоки.

Если же надо ускорить проверку ext4 возможно помогут опции монтирования journal_checksum journal_async_commit data=journal

https://www.kernel.org/doc/Documentation/filesystems/ext4.txt

ism ★★★ ()
Последнее исправление: ism (всего исправлений: 1)
Ответ на: комментарий от rupert

А чо там у виндузятников?

Ты ваще в курсе что у них там поголовно неотключаемые обновления которые перезагружают комп своими внезапными перезагрузками без спроса!

Только выиграли от постоянно ожидаемых перезагрузок в линуксе

anonymous ()
Ответ на: А чо там у виндузятников? от anonymous

Ты ваще в курсе что у них там поголовно неотключаемые обновления которые перезагружают комп своими внезапными перезагрузками без спроса!

Да уже обожрались попкорном от наблюдения за их веселухой. )))

Rx0 ()