Date: Mon, 18 Nov 2024 12:28:28 +0200 From: Andriy Gapon <avg@freebsd.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: freebsd-fs <fs@freebsd.org> Subject: Re: tmpfs loses (sub-page chunks of) data? Message-ID: <4334a3f7-5246-46db-ad43-771bd797ec05@freebsd.org> In-Reply-To: <ZzlQrIlOYAMkh13t@kib.kiev.ua> References: <a301f26f-0c67-48c3-af08-5f36c7ce764f@FreeBSD.org> <ZzfKJhrgbwq6CawR@kib.kiev.ua> <140eb994-ae19-41b4-8f0e-fc4290603ce0@freebsd.org> <ZzlQrIlOYAMkh13t@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On 17/11/2024 04:10, Konstantin Belousov wrote: > On Sat, Nov 16, 2024 at 02:31:25PM +0200, Andriy Gapon wrote: >> I think that mmap is not involved at all. >> Files are written from kernel using kern_writev(). > Why? Why from kernel or why kern_writev? That's how our appliance works. >> After they are complete, they are read from userland using whatever libssl >> uses to read input files (when encrypting). Looks like that's fread(3) / >> read(2). > > Try to reproduce it on the HEAD kernel. > Then, turn off swap and see if it is still there. > On HEAD, if reproducable without swap, try to add 'pgread' option to the > tmpfs moount. > > I am interested if the issue persists after all the measures listed above. Switching the systems where the problem happens to HEAD would be very nontrivial, unfortunately. I can experiment with swap and pgread much more easily. Thank you for suggestions. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4334a3f7-5246-46db-ad43-771bd797ec05>