On Fri, 13 Apr 2012 09:38:28 +0300 Artem Bityutskiy <dedekind1@xxxxxxxxx> 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? -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
