Date: Tue, 21 Mar 2017 21:41:19 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Dimitry Andric <dim@FreeBSD.org>, Ian Lepore <ian@FreeBSD.org>, "Gergely Czuczy" <gergely.czuczy@harmless.hu>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: process killed: text file modification Message-ID: <YQBPR01MB01807C7F00F1480FBBE82BF5DD3D0@YQBPR01MB0180.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <20170321175527.GN43712@kib.kiev.ua> References: <YTXPR01MB018944EF4248402AD421D825DD390@YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM> <20170317083605.GQ16105@kib.kiev.ua> <YTXPR01MB0189F7147A7C5C5F8C56B2F1DD390@YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM> <20170317141917.GS16105@kib.kiev.ua> <D0770019-3EEA-45D2-A751-18DF1B274F90@FreeBSD.org> <YTXPR01MB0189FBB6CF664653C1162936DD390@YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM> <20170318032150.GW16105@kib.kiev.ua> <YTXPR01MB0189F47B6A23C10BFE8A85E6DD3B0@YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM> <20170320221818.GM43712@kib.kiev.ua> <YTXPR01MB0189F229B71B500B8C3027DFDD3D0@YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM>, <20170321175527.GN43712@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
Konstantin Belousov wrote:
[stuff snipped]
> By 'impossible' I mean some arbitrary combination of bytes which were
> written by many means to the file at arbitrary moments. In other words,
> the file content, or even a single page/block content is not atomic
> WRT the client updates.
Yes. For multiple processes writing the same file, I'd agree that's going t=
o happen
unless the processes use advisoty byte range locking to order the updates.
And, I'm pretty sure a process that does both write(2) syscalls on a file a=
nd
modifies pages of it that are mmap()'d will produce "interesting" results a=
s you
describe.
[stuff snipped]
> Or, what seems more likely to me, the code was written on a system where
> buffer cache and page queues are not coherent.
>
> Anyway, my position is that nfs VOP_PUTPAGES() should do write through
> buffer cache, not issuing the direct rpc call with the pages as source.
Hmm. Interesting idea. Since a "struct buf" can only refer to contiguous by=
tes,
I suspect each page might end up as a separate "struct buf", at least until=
some
clustering algorithm succeeded in merging them.
I would agree that it would be nice to change VOP_PUTPAGES(), since it curr=
ently
results in a lot of 4K writes (with FILE_SYNC I think?) and this is normall=
y slow/inefficient
for the server. (It would be interesting to try your suggestion above and s=
ee if the
pages would cluster into larger writes. Also, the "struct buf" code knows h=
ow to do
UNSTABLE writes followed by a Commit.)
--> I am currently working on a pNFS server (which is coming along fairly w=
ell), so
I have no idea if/when I might get around to trying to do this.
> Then your patch would need an update with the mentioned call to ncl_flush=
().
Yes.
rick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YQBPR01MB01807C7F00F1480FBBE82BF5DD3D0>