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,
But how is it possible that sync is unable to cope and sync in time the metadata of a hundred new tiny files at most?
Is it some new problem with reiserfs?
Dunno, but I doubt it. I also have reiserfs partitions and my system syncs without trouble, plus I doubt there have been many changes in reiserfs recently (I stand to be corrected :)
But my /var/spool/news/ has 1,678,066 KiB in 659668 files, and some news processes change the access time of the inodes, which can be all of them.
Hmm, I mount all my filesystems with noatime (yes, I know modern people use relatime but just call me old-fashioned).
News in particular have traditionally used those time stamps.
I used to run a system that had loads of directories with millions of files in each one. Initially I used reiserfs for that but eventually had to change it for some reason. I remember ext4 was lousy for that application, but xfs worked well. Not as space efficient as reiserfs but it did perform reasonably.
The current implemantion stores all those change in ram, and dumps them to disk when doing a sync (halt or hibernate implies a sync).
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. 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 +++ -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)