From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Tomas Subject: Re: [RFC] pdirops: vfs patch Date: Mon, 21 Feb 2005 02:43:27 +0300 Message-ID: References: <42191ED8.8030303@tu-harburg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Alex Tomas , Alexander Viro , Linux-Kernel Mailing List , linux-fsdevel Received: from [83.102.214.158] ([83.102.214.158]:7296 "EHLO gw.home.net") by vger.kernel.org with ESMTP id S262115AbVBTXpL (ORCPT ); Sun, 20 Feb 2005 18:45:11 -0500 To: Jan Blunck In-Reply-To: <42191ED8.8030303@tu-harburg.de> (Jan Blunck's message of "Mon, 21 Feb 2005 00:35:52 +0100") Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org >>>>> Jan Blunck (JB) writes: JB> With luck you have s_pdirops_size (or 1024) different renames altering JB> concurrently one directory inode. Therefore you need a lock protecting JB> your filesystem data. This is basically the job done by i_sem. So in JB> my opinion you only move "The Problem" from the VFS to the lowlevel JB> filesystems. But then there is no need for i_sem or your JB> s_pdirops_sems anymore. 1) i_sem protects dcache too 2) tmpfs has no "own" data, so we can use it this way (see 2nd patch) 3) I have pdirops patch for ext3, but it needs some cleaning ... thanks, Alex