From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Morton Subject: Re: [PATCH v1 0/3] do not use s_dirt in FAT FS Date: Fri, 13 Apr 2012 00:26:56 -0700 Message-ID: <20120413002656.b67e58ad.akpm@linux-foundation.org> References: <1334144707-9729-1-git-send-email-dedekind1@gmail.com> <20120412171257.a0fc35b4.akpm@linux-foundation.org> <1334299108.2544.68.camel@sauron.fi.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: OGAWA Hirofumi , Linux Kernel Maling List , Linux FS Maling List , Jens Axboe , Al Viro To: dedekind1@gmail.com Return-path: In-Reply-To: <1334299108.2544.68.camel@sauron.fi.intel.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Fri, 13 Apr 2012 09:38:28 +0300 Artem Bityutskiy wrote: > > That implies that we retain ->write_super, probably in a modified form. > > Modified to permit the VFS to determine whether the superblock needs > > treatment, if ->s_dirt doesn't suffice. > > I tried this approach and it was vetoed by Al Viro. Although it is > simpler to me to resurrect my old patches, I agree with Al that killing > '->write_super()' is a better approach. Well, it can be done without a super_operation vector - pass the library code a superblock* and a function address. But the difference is pointless fluff. > We do not want to serve a whole > kernel thread in the generic code for few baroque citizens. One could refcount the thread, but I think I misread the code - the amount of generic boilerplate which was added to the fs is in fact pretty small. > Please, see this thread for the reference: > http://lkml.org/lkml/2010/7/22/96 > > > The code as you've proposed it will cause more wakeups than needed - if > > multiple filesystems are mounted and active, their timers will get out > > of sync. Which rather defeats the intent of the whole work! This > > problem should be addressable via some new centralised way of managing > > things. > > I do not think this is an issue. If we have many file-systems, and all > of them are actively used so that the super block becomes dirty, which > most probably means there is also write-back - so be it, it is ok to arm > many timers. And if we make them deferrable for most of the FSes (which > we can not do for the generic timer, because we do not know FSes needs) > - then this is not an issue at all. OK. > Also, if you look at this from the angle that only few old FSes will > have this, it becomes not that bad. I assume I will change this > patch-set and won't use delayed works here. I don't think I understand that. You intend to alter this patchset?