From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Frank Filz" Subject: RE: [Nfs-ganesha-devel] [PATCH v5 13/14] locks: skip deadlock detection on FL_FILE_PVT locks Date: Tue, 14 Jan 2014 20:10:09 -0800 Message-ID: <03d101cf11a7$b0012770$10037650$@mindspring.com> References: <1389277187-18211-1-git-send-email-jlayton@redhat.com> <1389277187-18211-14-git-send-email-jlayton@redhat.com> <52CF05B5.5080700@amacapital.net> <20140109194930.1692fbbe@tlielax.poochiereds.net> <20140114192713.GA22262@fieldses.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: 'Richard Hipp' , 'Jeff Layton' , 'samba-technical' , linux-kernel@vger.kernel.org, 'Linux FS Devel' , 'nfs-ganesha-devel' To: "'Richard Hipp'" , "'Andy Lutomirski'" Return-path: In-Reply-To: Content-language: en-us List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: samba-technical-bounces@lists.samba.org Errors-To: samba-technical-bounces@lists.samba.org List-Id: linux-fsdevel.vger.kernel.org That is exactly the behavior we are trying to avoid with the new private locks. We are also adding behavior that allows an application to have multiple threads of the same process to have their own locking context for a file. Frank From: Richard Hipp [mailto:drh@sqlite.org] Sent: Tuesday, January 14, 2014 1:44 PM To: Andy Lutomirski Cc: Richard Hipp; Jeff Layton; samba-technical; linux-kernel@vger.kernel.org; Linux FS Devel; nfs-ganesha-devel Subject: Re: [Nfs-ganesha-devel] [PATCH v5 13/14] locks: skip deadlock detection on FL_FILE_PVT locks On Tue, Jan 14, 2014 at 4:24 PM, Andy Lutomirski > wrote: On Tue, Jan 14, 2014 at 1:21 PM, Richard Hipp > wrote: > I have no context here. I'm not sure what you are discussing or what > questions you have or what SQLite has to do with any of it. Nevertheless, I > have injected a few remarks inline.... > The discussion is about a new set of fcntl locking commands that are are respect locks acquired with the old ones but suck less. This seems like the right time to discuss what would make them even better. The immediate change is to let them be owned by the fd instead of the process. This might end up in POSIX and could make sqlite (and lots of other things') lives easier. Sounds great. A common cause of SQLite database corruption is when another application thread does close(open(zDatabaseFile)) and deletes all of SQLite's locks out from under it. (Usually that happens in a misguided attempt to backup the database.). Any help we can get in that area will be appreciated! -- D. Richard Hipp drh@sqlite.org