-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2021-10-24 at 17:21 +0100, Dave Howorth wrote:
On Sun, 24 Oct 2021 14:18:40 +0200 "Carlos E. R." <> wrote:
On 24/10/2021 12.27, Dave Howorth wrote:
On Sun, 24 Oct 2021 04:25:13 +0200 "Carlos E. R." <> wrote:
On 23/10/2021 22.30, Dave Howorth wrote:
On Sat, 23 Oct 2021 20:52:59 +0200 (CEST) "Carlos E. R." <> wrote:
Hi,
You mean you have a tmpfs or something? Or just the kernel's caching?
No, it is an effect of relatime, which is default nowdays IIRC.
"something" in the filesystem stack tries to write the access time, but the kernel in fact stores that change in RAM. Can stay there for days, apparently. At some point it actually writes them to disk.
I did some quick reading around. It seems modern relatime should write at least once every twenty-four hours. I don't know if that matches your experience?
Apparently there was something called lazytime also being developed. It never writes atimes to disk, but keeps them always in cache. I don't know whether that would be better for you, or even whether lazytime is actually implemented/available/default by now?
They are the default, I think. In any case, I'm using them: Telcontar:~ # mount | grep reiser /dev/sdc9 on /data/Lareiserfs type reiserfs (rw,relatime,lazytime,user_xattr,acl) /dev/sdc9 on /data/homedvl type reiserfs (rw,relatime,lazytime,user_xattr,acl) /dev/sdc9 on /usr/src type reiserfs (rw,relatime,lazytime,user_xattr,acl) /dev/sdc9 on /home/cer/terrasync type reiserfs (rw,relatime,lazytime,user_xattr,acl) /dev/sdc9 on /usr/share/flightgear type reiserfs (rw,relatime,lazytime,user_xattr,acl) /dev/nvme0n1p6 on /data/LareiserfsOnSSD type reiserfs (rw,relatime,lazytime,user_xattr,acl) /dev/nvme0n1p6 on /var/spool/news type reiserfs (rw,relatime,lazytime,user_xattr,acl) Telcontar:~ # If I disable them, sync goes faster or is not needed, but instead the normal operation during the day is very slow.
My hypothesis is that reiserfs, which sees barely no maintenance, is slow when doing that, specially on rotating rust. In fact, I see the hard disk LED solid "on" while the sync is going on.
Now that I think... I have free space in my /dev/nvme0n1, I can add a small reiserfs there and test. I see 3.7 gigs in use, so 12 gigs would be more than enough.
I would suggest to try running
$ strace synce
and see what that shows. Is it hanging somewhere, or in an infinite loop? You might be able to see where.
I doubt that is viable, but I can try.
Why wouldn't it be viable?
If it goes on on 100000 files... the trace can be enormous.
Anyway, operation yesterday night was fast, the strace was active. 43 lines.
Huh, we will see nothing, the gist is a single line:
... open("/usr/lib64/gconv/gconv-modules.cache", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=26244, ...}) = 0 mmap(NULL, 26244, PROT_READ, MAP_SHARED, 3, 0) = 0x7f829bbbe000 close(3) = 0 sync() = 0 close(1) = 0 close(2) = 0 exit_group(0) = ? +++ exited with 0 +++
Yeah, sync() is a single call to the kernel. So whatever is slowing your system is something in the kernel rather than the application. Whether that's a kernel issue or just a 'big' filesystem in some sense, I don't know. NVMe should definitely help. Or change to some news software that doesn't use atime :)
Oh, there is no alternative to leafnode, it is unique. I have migrated my partition to SSD, but I tried a sync on the old one (that is not in operation) and it is taking hours. I have a half written post on it, waiting for the sync to complete and write the report. - -- Cheers, Carlos E. R. (from openSUSE 15.2 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHIEARECADIWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCYXWR1BQccm9iaW4ubGlz dGFzQGdteC5lcwAKCRC1MxgcbY1H1fn9AJ4l9T/R8Akmkf5kapzsdzfyiaXcsACe KEzbT1y7+9V60+GLT0WVhL6X4Lw= =jtkr -----END PGP SIGNATURE-----