From: David Gibson <david@gibson.dropbear.id.au>
To: Stefano Brivio <sbrivio@redhat.com>
Cc: passt-dev@passt.top
Subject: Re: [PATCH v3 5/9] log: Don't use O_APPEND at all
Date: Tue, 29 Oct 2024 15:20:56 +1100 [thread overview]
Message-ID: <ZyBiqObNQHXzsTyh@zatzit> (raw)
In-Reply-To: <20241028100044.939714-6-sbrivio@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2882 bytes --]
On Mon, Oct 28, 2024 at 11:00:40AM +0100, Stefano Brivio wrote:
> We open the log file with O_APPEND, but switch it off before seeking,
> and turn it back on afterwards.
>
> We never seek when O_APPEND is on, so we don't actually need it, as
> its only function is to override the offset for writes so that they
> are always performed at the end regardless of the current offset
> (which is at the end anyway, for us).
Sorry, this sounded fishy to me on the call, but I figured I was just
missing something. But looking at this the reasoning doesn't make
sense to me.
We don't seek with O_APPEND, but we do write(), which is exactly where
it matters. AIUI the point of O_APPEND is that if you have multiple
processes writing to the same file, they won't clobber each others
writes because of a stale file pointer. That's usually not
_necessary_ for us as such, but it's perhaps valuable since it reduces
the likelihood of data loss if somehow you do get two instances
logging to the same file.
Of course the rotation process *can* clobber things (which is exactly
why I was always a bit sceptical of this "in place" rotation, not that
we really have other options). But that at least is occasional,
unlike each log write.
Maybe it's not worth having O_APPEND, but I don't think the reasoning
above makes any real sense.
>
> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
> ---
> log.c | 8 +-------
> 1 file changed, 1 insertion(+), 7 deletions(-)
>
> diff --git a/log.c b/log.c
> index 6932885..dd25862 100644
> --- a/log.c
> +++ b/log.c
> @@ -204,9 +204,6 @@ out:
> */
> static int logfile_rotate(int fd, const struct timespec *now)
> {
> - if (fcntl(fd, F_SETFL, O_RDWR /* Drop O_APPEND: explicit lseek() */))
> - return -errno;
> -
> #ifdef FALLOC_FL_COLLAPSE_RANGE
> /* Only for Linux >= 3.15, extent-based ext4 or XFS, glibc >= 2.18 */
> if (!fallocate(fd, FALLOC_FL_COLLAPSE_RANGE, 0, log_cut_size))
> @@ -215,9 +212,6 @@ static int logfile_rotate(int fd, const struct timespec *now)
> #endif
> logfile_rotate_move(fd, now);
>
> - if (fcntl(fd, F_SETFL, O_RDWR | O_APPEND))
> - return -errno;
> -
> return 0;
> }
>
> @@ -416,7 +410,7 @@ void logfile_init(const char *name, const char *path, size_t size)
> if (readlink("/proc/self/exe", exe, PATH_MAX - 1) < 0)
> die_perror("Failed to read own /proc/self/exe link");
>
> - log_file = open(path, O_CREAT | O_TRUNC | O_APPEND | O_RDWR | O_CLOEXEC,
> + log_file = open(path, O_CREAT | O_TRUNC | O_RDWR | O_CLOEXEC,
> S_IRUSR | S_IWUSR);
> if (log_file == -1)
> die_perror("Couldn't open log file %s", path);
--
David Gibson (he or they) | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you, not the other way
| around.
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2024-10-29 4:25 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-28 10:00 [PATCH v3 0/9] Take care of clang-tidy warnings with LLVM >= 16 Stefano Brivio
2024-10-28 10:00 ` [PATCH v3 1/9] Makefile: Exclude qrap.c from clang-tidy checks Stefano Brivio
2024-10-28 10:00 ` [PATCH v3 2/9] treewide: Comply with CERT C rule ERR33-C for snprintf() Stefano Brivio
2024-10-28 10:00 ` [PATCH v3 3/9] treewide: Silence cert-err33-c clang-tidy warnings for fprintf() Stefano Brivio
2024-10-28 10:00 ` [PATCH v3 4/9] Makefile: Disable readability-math-missing-parentheses clang-tidy check Stefano Brivio
2024-10-28 10:00 ` [PATCH v3 5/9] log: Don't use O_APPEND at all Stefano Brivio
2024-10-29 4:20 ` David Gibson [this message]
2024-10-29 8:48 ` Stefano Brivio
2024-10-29 9:32 ` David Gibson
2024-10-29 10:23 ` Stefano Brivio
2024-10-30 2:33 ` David Gibson
2024-10-30 12:27 ` Stefano Brivio
2024-10-31 0:35 ` David Gibson
2024-10-28 10:00 ` [PATCH v3 6/9] treewide: Suppress clang-tidy warning if we already use O_CLOEXEC or if we can't Stefano Brivio
2024-10-29 4:24 ` David Gibson
2024-10-28 10:00 ` [PATCH v3 7/9] treewide: Address cert-err33-c clang-tidy warnings for clock and timer functions Stefano Brivio
2024-10-29 4:24 ` David Gibson
2024-10-28 10:00 ` [PATCH v3 8/9] udp: Take care of cert-int09-c clang-tidy warning for enum udp_iov_idx Stefano Brivio
2024-10-28 10:00 ` [PATCH v3 9/9] util: Don't use errno after a successful call in __daemon() Stefano Brivio
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZyBiqObNQHXzsTyh@zatzit \
--to=david@gibson.dropbear.id.au \
--cc=passt-dev@passt.top \
--cc=sbrivio@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://passt.top/passt
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for IMAP folder(s).