On Mon, Jul 10, 2006 at 05:51:00PM +0100, Christoph Hellwig wrote:
> Sorry about the odd reference.
> 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,
> - 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
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.