Hi Christoph, On Mon, Jul 10, 2006 at 05:51:00PM +0100, Christoph Hellwig wrote: > Sorry about the odd reference. No worries. > 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. > look at the changes between two linus releases to see changes. OK. I've still had zero expressions of interest from anyone else WRT sending out XFS git merge mail to wider audiences... *shrug*. And I know you're plenty handy with git, so you don't need it yourself. :) > Anyway, the odd changes from 2.6.17 to 2.6.18-rc are: > > - replacing PFLAGS_* with even more obsfucation Bah! They certainly look cleaner to me - less case SHOUTING, and this sort of thing is done in plenty of other places (e.g. see bio_flagged, bio_sync, etc...) > - 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. > - the VN_TRUNC looks interesting. I wish we had a public discussion about > this and could see whether or not to handle it at the VFS level Sure, please discuss. I was narrowing a window on a long standing XFS-specific 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?). > - adding a new inherit_nodfrg flag that's not actually used anywhere C'mon, you know better. Try inode allocation, in xfs_inode.c. > - 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). 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 :). I'd _really, really_ like to see people so keen on doing cleanup work also participating in the bug fixing work (and regression fixing from their own handiwork, sometimes!) - I think that would go a long way to really improving XFS, rather than just prettying the code up at the edges. As always, I appreciate your input though Christoph (at least you look at the code, unlike the wc(1) jokers, and there's plenty of good with the bad). Plus, you buy me beers sometimes, so I really can't complain - thanks mate. cheers. -- Nathan - 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
