From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from zeniv.linux.org.uk ([195.92.253.2]:35606 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751287AbcEaRoT (ORCPT ); Tue, 31 May 2016 13:44:19 -0400 Date: Tue, 31 May 2016 18:44:16 +0100 From: Al Viro To: Stef Bon Cc: "fuse-devel@lists.sourceforge.net" , "linux-fsdevel@vger.kernel.org" Subject: Re: [fuse-devel] Changes in 4.7. Message-ID: <20160531174416.GC14480@ZenIV.linux.org.uk> References: <87shwy8b38.fsf@thinkpad.rath.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Tue, May 31, 2016 at 06:25:24PM +0200, Stef Bon wrote: > I've been thinking about the non serialized readdirs. I do not understand. > Readdirs have to be serialized, since the offset of the next readdir > (belonging to the opendir) is known when the current readdir is > finished: > "start where current left". They are serialized per struct file (and so'd lseek() on them, for that matter). So the state that is associated with an opened file is just fine; it's modifiable state associated with directory itself, and shared between all opened file that would be a problem. IOW, they can do readdir in parallel exactly in the cases when lseek done by one of them would not affect another.