From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Morton Subject: Re: [PATCH] 2.5.x write_super is not for syncing Date: Tue, 03 Dec 2002 20:29:57 -0800 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <3DED84C5.4085EBDD@digeo.com> References: <3DED2C7B.135E8F0D@digeo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "linux-fsdevel@vger.kernel.org" , Chris Mason , "Stephen C. Tweedie" Return-path: Received: from digeo-nav01.digeo.com (digeo-nav01.digeo.com [192.168.1.233]) by packet.digeo.com (8.9.3+Sun/8.9.3) with SMTP id UAA11621 for ; Tue, 3 Dec 2002 20:29:58 -0800 (PST) To: Bryan Henderson List-Id: linux-fsdevel.vger.kernel.org Bryan Henderson wrote: > > >Well, I'd say that telling the fs about umount activity is "out > >of scope" for this exercise ;) > > Not sure what your point is here. The filesystem driver already knows when > the filesystem image is being destroyed (i.e. the struct super_block is > going away), which is the only umount activity I'm talking about. If > destroying a filesystem image of a particular type means cached stuff has > to get sync'ed, the filesystem driver knows to do it then; there's no need > for a ->sync_fs call in addition to ->put_super. In the context of the 2.4 kernel it is not practical to change every filesystem to sync itself at unmount. Nor in 2.5, by my hand... > >It seems reasonable to have a super_op which says "sync everything > >to disk". > > Well, maybe, but the question is when should FS call that? I say > performing the sync() system call is the only time it should. If it calls > it for any other reason, it is making assumptions about how the particular > filesystem type works. Yes, it always has. And Linux's tradition of forcing the filesystems to comply with the VFS's and VM's requirements has always been a strength. Because we can make deep changes to the VM and VFS without having to make deep changes to filesytems. Yes, this makes porting filesystems from other OS'es harder. That is tough luck. It's better this way. Filesystems which do weird stuff are a pain - they drag down core kernel development. > Because "sync everything to disk" is ambiguous in the modern diverse world > of filesystems (so is fsync() -- note that standards define these pretty > vaguely in recognition of that), the only sensible way to define it is to > say "it's what sync() does -- ask your filesystem type designer what sync() > does on your filesystem." > > If there's any other writing of cached data to disk that needs to be done, > I say the filesystem driver knows when to do it; FS should not presume to > know. The move is more toward "if the fs needs to do special stuff then it should have a hook to do that". In concrete terms, this means rather than "write your superblock now" we need to tell the fs what's happening at a higher level, and if the fs isn't interested, perform the default (ext2-style) operation. I don't think anyone has a problem with that approach. And as new filesystems are added to Linux, each one brings in its own set of new hooks. And I think that's a fine approach - we should not be speculatively adding hooks if they have no in-kernel consumers. > Of course, in ext2 and its ilk, FS understands the inner workings and is > deeply involved in caching and uses the traditional ->write_super, etc. to > carry it out. We're only talking about new, more general kinds of > filesystems now. ->write_super() seems to be a bit of a crock. It _should_ be "the VFS superblock info has changed. You should propagate that to pagecache but not start IO against it". It's not clear what it actually means at present. But for your fs, I suspect we'll need to see specific descriptions of the problems which are being encountered, and patches.