> > changes seem to not come with TAKE messages sometimes. So I have to > > Yeah, sometimes we have new folks coming on board learning the ropes, > and sometimes email lists gets b0rked. We also have somewhat oddball > processes here so stuff gets dropped; its the nature of the beast and > unavoidable at times, unfortunately. Sure, this wasn't a complaint by itself. I happened to me more than often enough. It's just an explanation why it's hard to timely review xfs changes. What would be even more helpfull is of course if changes get sent to the xfs list for review before committing instead of just to an sgi-internal one.. > > - the big renaming of the vnode/vfs thingies. I take this as an official > > go-ahead that this cruft isn't for irix-compatibility anymore and remove > > it. I have a nice patch pending that reduces xfs size big time with > > this (unfortunatly needs a nasty rebase now) > > Heh, don't take it that way... take it more as "behaviours are useful within > XFS, despite you not wanting them to be". ;) There is no way I can see those > ever being removed, they are (for the Nth time) genuinely useful now and I see > them becoming more and more useful. A more pragmatic approach for you might > be to say: "I don't see how they can be even more useful, Nathan, you dill, > and I'm itching to remove them!", at which point I'll point you to Dave, and > say "Discuss amongst yourselves, but Dave is making wide use of them in his > current project and says they're a perfect fit there too". So, stop hassling > me about it and please don't send patches that have already been NACKd - I've > my own work to get done too. Thanks. Maybe Dave could explain what he's doing? (Hi Dave!). Generally these kinds of duplication of stackable filesystem infrastructure in a single filesystem is pretty much the last thing we want. If you want to keep it you need to bring up a very very good reason. This is comparable to the long as nasty reiser4 discussion. > issue there (the good old truncate vs. delalloc NULL files problem). If this > can be done better in a generic way, I'm all for it. Personally, I thought it > was a good use of the generic flush() infrastructure that we weren't using ... > but I guess theres some scope for this to be more generic (generic inode flag? > you sure? hmm, I dunno - would others use this?). Yes, a generic inode flag would be useful. Especially as killing this odd vmodified flag has been on my todo list for a long time. No need to have another flag word in the vnode when there's already one in the linux inode and one in xfs_inode. > > > - adding a new inherit_nodfrg flag that's not actually used anywhere > > C'mon, you know better. Try inode allocation, in xfs_inode.c. Look again. It's not used anywhere in fs/xfs/ in Linus' tree. > > - addding a VFS_UMOUNT flag that isn't actually used anywhere and shouldn't > > exist with Linux's unmount handling > > Hmm, yes, I really may have accidentally merged something there. That is used > during xfssyncd shutdown on 2.4, do you recall why we don't need it on 2.6? > (refresh my memory? I'm gettin' old). Because the kthread_ API handles all this. > I'm half-tempted to fire back my own list - recent regressions introduced into > XFS by, er, Christoph and (more importantly) fixed by myself and others @sgi... > but thats not constructive (although our atime and dir2-corruption nightmares > continue :). Hey, fixes for problems I introduced are 1st on my every growing todo list. But maybe you should tell me about things I'm supposed to help fixing? - 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
