On Tue, 14 Dec 2021 12:41:16 +0100 (CET) "Carlos E. R." <robin.listas@telefonica.net> wrote:
Hi,
I have a problem with my one remaining reiserfs partition on rotating rust.
The problem I initially detected was that telling the machine to hibernate sometimes appeared to stall, and I had to force a power off (via physical power switch) to recover. In fact, I found out later, the kernel was simply syncing one partition, and this operation would take half an hour, which it is absurd.
Later I found out that it was only one partition affected, and this partition was (is) reiserfs. Then I guessed that the slow operation was syncing the metadata (the time stamps) of the news (nntp) spool.
Traditionally a news server touches (and use) the access timestamp each time a post is read, affecting one file per read. With the default mount options used nowdays this modification stays in RAM for long, many hours.
So, the cronjob that scans the news spool now also calls sync on that filesystem, and when hibernating I call sync in advance. This improved things, but not completely.
Thus I finally resorted to moving the news spool only to another reiserfs partition created on an SSD disk, which usually syncs in seconds, instead of half an hour.
So I thought, problem solved.
But later on I noticed that the sync operation prior to hibernating on the old reiserfs partition still takes long, but only on some days - even if nothing writes there now. This is astonishing.
Have you tried using strictatime (and no lazytime)? Does that cure the sync problem? FWIW I don't see delays when I run sync on my reiser partition and I use noatime so your problem is most likely either related to the specific data you store or the atime modes you choose. [snip]