http://bugzilla.suse.com/show_bug.cgi?id=911347 Chenzi Cao changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |chcao@suse.com Assignee|bnc-team-screening@forge.pr |systemd-maintainers@suse.de |ovo.novell.com | -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=911347 Dr. Werner Fink changed: What |Removed |Added ---------------------------------------------------------------------------- Comment #2 is|1 |0 private| | --- Comment #3 from Dr. Werner Fink --- (In reply to Thomas Blume from comment #2) AFAICR the default log console was /dev/tty10 also I'd like to know if we should use relative values which fits to 100Mb with a 40Gb root partition ... better we should check the size of /var which could be a seperate parition -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=911347 --- Comment #7 from Thomas Blume --- (In reply to Bruno Pesavento from comment #6)

(In reply to Thomas Blume from comment #5)

...

I guess we'd need an absolute lower limit for small systems and an relative upper limit for big systems.

Maybe there is a simpler solution. What really hurts slow disks is max file size. So something like "SystemMaxUse=400M" (or 1% of 40GB) and "SystemMaxFileSize=26M" (or three 8.4 MB log chunks as seen on my 64bit systems) is likely to make everybody happy. Anyway that sounds more reasonable than the current 4GB and 480MB, respectively, with the suggested 40 GB root/. If anybody really needs more, or less, he/she is not an "average" user IMHO and should know how to tweak system defaults. I'll try that on my slow test disk and report back anything of interest.

Thanks, would be good if you could test this. Btw. the code includes some general limits on the journal size: -->-- /* This is the minimum journal file size */ #define JOURNAL_FILE_SIZE_MIN (4ULL*1024ULL*1024ULL) /* 4 MiB */ /* These are the lower and upper bounds if we deduce the max_use value * from the file system size */ #define DEFAULT_MAX_USE_LOWER (1ULL*1024ULL*1024ULL) /* 1 MiB */ #define DEFAULT_MAX_USE_UPPER (4ULL*1024ULL*1024ULL*1024ULL) /* 4 GiB */ /* This is the upper bound if we deduce max_size from max_use */ #define DEFAULT_MAX_SIZE_UPPER (128ULL*1024ULL*1024ULL) /* 128 MiB */ --<-- but it seems they are too generous for old machines. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=911347 Thomas Blume changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tchvatal@suse.com Flags| |needinfo?(bpesavento@infini | |to.it), | |needinfo?(tchvatal@suse.com | |) --- Comment #12 from Thomas Blume --- (In reply to Bruno Pesavento from comment #11)

I still think that limiting SystemMaxFileSize= well under DEFAULT_MAX_SIZE_UPPER (I would set it to 32 MiB on my test system) prevents most collateral damage on slow systems and has no adverse effects, to my understanding. Then the defaults will take care of small systems, trying to leave some free space on /var anyway.

Hm, https://bugzilla.redhat.com/show_bug.cgi?id=1006386 comment#84 indicates that a small MaxFileSize will hurt the journal efficiency. However, it doesn't seem that we will loose logs therewith. And 32Mb is 3 times more than suggested in the RH bug. Maybe we won't have too bad negative effects therewith. Does SystemMaxFileSize=32M also help if you have SystemMaxUse unset?

Fragmentation is almost nonexistent in my "productive" laptop so far (Tumbleweed, SSD, EXT4, 30GB root/). So, waiting for the designers to solve the root problem, I'm not complaining: the test disk is going to be wiped by the next RC anyway. But even halving the times I'm witnessing, I think that many laptops more than 5 years old are going to hit troubles with current defaults.

Sure, we should continue pursue this, independently of the SystemMaxFileSize settings. Can you confirm that you see the fragmentation and the long journal flushes only on btrfs? If so, I should probably open a separate btrfs bug.

Feel free to ask for more testing if needed.

Thanks, would be good if you could also test the other fix, e.g. edit /etc/sysctl.d/99-sysctl.conf and put: net.unix.max_dgram_qlen=1000 there. Does this has any further influence on the journal flush time? Tomas, could you also test all the above? I really would need testing on more hardware here. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=911347 Thomas Blume changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(bpesavento@infini | |to.it) --- Comment #18 from Thomas Blume --- (In reply to Bruno Pesavento from comment #17)

(In reply to Thomas Blume from comment #16) Agree, this is just a workaround to keep old systems rolling, waiting for the designers to solve the root cause. Journal logs are highly sparse, a 33.6MB file compresses to just 4MB in tar.gz, as a rough measure of info content...

I would be completely fine with the workaround, if we only could limit it to systems that really need it. But I don't know how we should distinguish old from recent machines. Setting SystemMaxFileSize unconditionally gives me some headaches. Let's keep it as a last resort for now and first try some other things. A systemd build including the btrfs patches is now available at: https://build.opensuse.org/package/binaries/home:tsaupe:branches:Base:System... can you give it a try? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=911347 Thomas Blume changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(bpesavento@infini | |to.it) -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=911347 --- Comment #24 from Thomas Blume --- (In reply to Bruno Pesavento from comment #23)

I'll let the file grow unconstrained (unless I hit a wall...), but think the default max is 128MiB (see comment #7).

Indeed, please forget my comment and test without a limit. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=911347 http://bugzilla.suse.com/show_bug.cgi?id=911347#c27 Thomas Blume changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gnyers@suse.com --- Comment #27 from Thomas Blume --- *** Bug 838475 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are on the CC list for the bug.