Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1764723AbXHQTBp (ORCPT ); Fri, 17 Aug 2007 15:01:45 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757631AbXHQTBe (ORCPT ); Fri, 17 Aug 2007 15:01:34 -0400 Received: from iriserv.iradimed.com ([72.242.190.170]:22178 "EHLO iradimed.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1756267AbXHQTBd (ORCPT ); Fri, 17 Aug 2007 15:01:33 -0400 Message-ID: <46C5F09C.2050600@cfl.rr.com> Date: Fri, 17 Aug 2007 15:01:48 -0400 From: Phillip Susi User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Valdis.Kletnieks@vt.edu CC: Kyle Moffett , Michael Tharp , alan , Marc Perkel , LKML Kernel , Lennart Sorensen , Al Viro Subject: Re: Thinking outside the box on file systems References: <106259.96671.qm@web52501.mail.re2.yahoo.com> <46C2F96D.5030908@partiallystapled.com> <20070815133021.GB9412@csclub.uwaterloo.ca> <46C33934.7060802@cfl.rr.com> <46C3644C.9020102@cfl.rr.com> <87EEB1B3-7FFA-472C-B539-1A7AA2843869@mac.com> <46C37AD4.5060006@cfl.rr.com> <46C4689C.8020702@cfl.rr.com> <5D526964-3F46-4B6D-A12A-437A7EF5E0D8@mac.com> <46C5BC79.9090204@cfl.rr.com> <1942.1187365183@turing-police.cc.vt.edu> In-Reply-To: <1942.1187365183@turing-police.cc.vt.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Aug 2007 19:01:46.0571 (UTC) FILETIME=[0EF829B0:01C7E101] X-TM-AS-Product-Ver: SMEX-7.5.0.1243-5.0.1021-15368.000 X-TM-AS-Result: No--11.360100-5.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1463 Lines: 34 Valdis.Kletnieks@vt.edu wrote: > I suspect Kyle is not quite correct - it's probably the case that you don't > have to consider just the in-memory dentries, but *all* the descendent objects > in the entire file system. > > If you have a clever proof that on-disk can't *possibly* be affected, feel > free to present it. Why would you have to consider the descendent entries on disk when you are only changing an entry in the parent? The effects of that change are only computed in memory when the dentry for a child is created, so you don't have to do a bunch of disk churning to change permissions on the whole tree. In fact, all of the children may very well have NO acl of their own stored on disk, which also saves space. The whole idea here is that there is ONE acl that applies to the whole tree, rather than have every object in the tree have its own acl. That's why every object in the tree on the disk is not effected by a change. > It will become even *more* of a "not that common" if the lock will block moves > and ACL changes *across the filesystem* for potentially *minutes* at a time. It will not take anywhere NEAR minutes at a time to update the in memory dentries, more like 50ms. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/