From owner-freebsd-current@freebsd.org Tue Mar 21 21:41:24 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 65ED3D17CFD for ; Tue, 21 Mar 2017 21:41:24 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660057.outbound.protection.outlook.com [40.107.66.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0859916F6; Tue, 21 Mar 2017 21:41:23 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YQBPR01MB0180.CANPRD01.PROD.OUTLOOK.COM (10.169.141.138) by YQBPR01MB0178.CANPRD01.PROD.OUTLOOK.COM (10.169.141.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.11; Tue, 21 Mar 2017 21:41:19 +0000 Received: from YQBPR01MB0180.CANPRD01.PROD.OUTLOOK.COM ([10.169.141.138]) by YQBPR01MB0180.CANPRD01.PROD.OUTLOOK.COM ([10.169.141.138]) with mapi id 15.01.0977.020; Tue, 21 Mar 2017 21:41:19 +0000 From: Rick Macklem To: Konstantin Belousov CC: Dimitry Andric , Ian Lepore , "Gergely Czuczy" , FreeBSD Current Subject: Re: process killed: text file modification Thread-Topic: process killed: text file modification Thread-Index: AQHSnqPLfXcZwdtVHkecT5jK6Yv9dKGYQJIXgAAZ/baAAFsxgIAAVqF+gAAJQ4CAAFvPgIAAF1PPgABnggCAArMZZIABrxcAgAA8zEOAAQwZgIAAO42g Date: Tue, 21 Mar 2017 21:41:19 +0000 Message-ID: References: <20170317083605.GQ16105@kib.kiev.ua> <20170317141917.GS16105@kib.kiev.ua> <20170318032150.GW16105@kib.kiev.ua> <20170320221818.GM43712@kib.kiev.ua> , <20170321175527.GN43712@kib.kiev.ua> In-Reply-To: <20170321175527.GN43712@kib.kiev.ua> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: FreeBSD.org; dkim=none (message not signed) header.d=none;FreeBSD.org; dmarc=none action=none header.from=uoguelph.ca; x-microsoft-exchange-diagnostics: 1; YQBPR01MB0178; 7:HPiQDFBvN5uxzY98+VJSmz7B/5B4xAWraNMQ6nnHd80i6y3ZMu6IYCyRH3zR3N9rhShUZ/hwIRp6q96/kPZbU7ivcaEb82ELukPGddUYF6YdYTyqgiuwdVVaejqpje0UoQJOnsugNFv4wJKFo6LYDnSYZWYNC/6WZr1V01WJ77oCHZ/1TMi3TLVwoPsdi8svdyZnvzwN3JimvOf6N6c3lN9PHbI0oeGNI5zpVYbFc9iuEawnPylI4LgTUods2G9udNAQDBtYQDFmNcNCelKDUBAwlRhMMduFtNfq/R8Pe/I4Vn+JtoWAXGmB+U074PB6Qaye+vpPX66UowGRBI4UIg== x-ms-office365-filtering-correlation-id: d91edc00-9a0b-496a-b643-08d470a302d0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:YQBPR01MB0178; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123558025)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(6072148); SRVR:YQBPR01MB0178; BCL:0; PCL:0; RULEID:; SRVR:YQBPR01MB0178; x-forefront-prvs: 02530BD3AA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(24454002)(52314003)(39060400002)(93886004)(106356001)(6246003)(110136004)(38730400002)(4326008)(74482002)(8676002)(189998001)(2950100002)(7696004)(6916009)(6506006)(77096006)(6436002)(2906002)(54906002)(9686003)(55016002)(1411001)(86362001)(54356999)(50986999)(76176999)(8936002)(81166006)(305945005)(2900100001)(53936002)(3660700001)(68736007)(5660300001)(122556002)(74316002)(3280700002)(33656002)(102836003)(229853002)(25786009); DIR:OUT; SFP:1101; SCL:1; SRVR:YQBPR01MB0178; H:YQBPR01MB0180.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Mar 2017 21:41:19.4544 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQBPR01MB0178 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 21:41:24 -0000 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