Date: Wed, 07 May 2025 18:38:35 +0200 From: Olivier Certner <olce@freebsd.org> To: Xin LI <delphij@freebsd.org> Cc: src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: 83507f9e6fed - main - newsyslog(8): Disable compression by default in newsyslog.conf. Message-ID: <5049201.M427ezpTYi@ravel> In-Reply-To: <202505040750.5447oQWq012045@gitrepo.freebsd.org> References: <202505040750.5447oQWq012045@gitrepo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart5743926.vRHrNHmk2K
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"; protected-headers="v1"
From: Olivier Certner <olce@freebsd.org>
To: Xin LI <delphij@freebsd.org>
Date: Wed, 07 May 2025 18:38:35 +0200
Message-ID: <5049201.M427ezpTYi@ravel>
In-Reply-To: <202505040750.5447oQWq012045@gitrepo.freebsd.org>
References: <202505040750.5447oQWq012045@gitrepo.freebsd.org>
MIME-Version: 1.0
Hi Xin and all,
> (snip)
> Historically, newsyslog compressed rotated log files to save disk spa=
ce.
> This was helpful when storage was limited. However, with modern files
> systems like ZFS providing built-in compression and with larger disks
> now common, the benefits of additional log compression have diminishe=
d,
> especially given the inconvenience of needing to decompress logs when
> searching for specific patterns.
> (snip)
I remember having rebuked these arguments and most of the other ones presen=
ted in a discussion started by commit 2f036705f337 ("Document the two recen=
t newsyslog(8) change (-c option and <compress> configuration option).") mo=
re than a year ago. The main point of contention was turning the compressi=
on off by default. Re-reading what I wrote, I still find it as spot on as =
it seemed at that time. In a nutshell, I developed ample arguments showing=
why the benefits of compression for logs far outweigh the drawbacks. In f=
act, I could only find one drawback in a very niche scenario where log file=
s would stay big (i.e., they are not rotated enough/based on size). All ot=
her "drawbacks" reported by you and those wanting the change were very weak=
at best, and even sometimes based on plain wrong assumptions (to stay poli=
te).
In a subsequent private message, I was told there would be some followup to=
my last mail wrapping up the discussion (dated 2024/01/10), but unfortunat=
ely it never came. Today, browsing D43169, D43466 or even related D42961, =
I can see that there are exactly zero new arguments for the need to disable=
compression *by default*.
In absence of more elements, I thus stand by the same conclusion as one yea=
r ago: The sensible default is to enable compression (for files marked as c=
ompressible), and for POLA it is probably to stay with 'legacy', so that co=
mpression letters actually mandate the desired compression format. This is=
what seems to benefit most uses and users by far.
In other words, this commit should just be reverted.
Surely some people will find that this is a minor change, that we should no=
t make a fuss about it and just change our configuration file at next updat=
e if we disagree. That would just be missing the point. We are developing=
and shipping to users a highly configurable complex system, with lots of m=
oving parts, automatic tuning mechanisms, configuration files, and admin-tu=
nable parameters that more often then not are piling up over time. Expecti=
ng that most of our users will have/take the time to review and tweak even =
a fraction of them and correctly for their use case seems a delusion to me.=
They will just keep running with with essentially the automatically tuned=
and default values with some exceptions. Consequently, we should strive t=
o have sensible defaults, even on minor stuff, as otherwise we keep adding =
burden on administrators with all the bad choices/changes we made they have=
to correct (if at all possible), not even speaking about more casual users=
who at some point will choose to just give up and choose another system.
I would like to encourage a realization in this matter (or a rebuttal if yo=
u do not agree).
I would also like that, at the very least, people have some consideration w=
hen some others spend non-trivial amounts of time reviewing their work and =
endorsing the sometimes not-fun role of seriously challenging them for (wha=
t they think is) the greater good, e.g., by responding to well-argued criti=
cism.
=46or this precise case, I've read all the above-mentioned material (revisi=
ons, commits) and exchanged mails on src-committers@, and sent all my point=
s to the latter (in January 2024). I certainly don't intend to participate=
in a rehash of what has already been said in these venues, that would just=
be a waste of time, thank you. But if there are new elements in favor of =
this change, or if some of my understanding or arguments were wrong, I'd be=
glad to hear about that.=20
Thanks and regards.
=2D-=20
Olivier Certner
--nextPart5743926.vRHrNHmk2K
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit
-----BEGIN PGP SIGNATURE-----
iQIzBAABCQAdFiEEmNCxHjkosai0LYIujKEwQJceJicFAmgbjIsACgkQjKEwQJce
Jiew1g//Yu9JPCdu8HwheixHLhrhlVLcijXwWmPwyAobQREdLX+WpliUzZ7Axytu
kxsByo2TrueOzw/wrhZqeUKTQm5N5ebJEprDqExhYwtMtspF2bCbtZJVxedemBHt
sMMR3/TKxNujj9ivwvbgpGj21NM2SYDiCbOgmu0Qe4SAWW0hg+Hl+5fV6tq4QqM/
PQiDZ5x4BKWLvM58oDkumtpKkHpsjgyWmMWTuhrXAVzc7fjQG7Wi36ymq+fMp2PS
uZKDrHFQtjXN+2E6eqzZsNvQBEdTvLJbCHd4XzSMV13r18UuiwzBtMZd0RQsxZKf
BvSGa474bKenabVwyXML8dENJLrARhLRVFW9oz6Gc5drHasVW9ktFRKLk02Cvgd2
3gXeFHojFJrNO/gqKD6/7kSEgFl0jA4LEfFca9np93PAuUaddnSV+nJaY8z9MIru
r7kBYzJoRnjlcDejSlP2llLKzTshnZL331ed6jYCL9KkLUjeYJP6BiPadvlDk+Ky
Ag2k9E6m2aVuf+AHk9pzP6xCKG3vESq/NKpCnUerCbSMRSPb3r/H8g4u+DRxImkM
ExKr1nEaaUoicGRL0NriW+IJamydVF2Tgp/2f8DU7LX/soLZRZRWHgREbwvLQR4B
sVzcV7dyqqTXDM5aVdmV73vdO4OlwaTejJ/TJJcF1SDd3S54pho=
=tqv5
-----END PGP SIGNATURE-----
--nextPart5743926.vRHrNHmk2K--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5049201.M427ezpTYi>