Re: [PATCH] Make use of stat.ctime configurable

On Mon, 28 Jul 2008, Junio C Hamano wrote:

quoted

Anybody who uses extended attributes as part of a indexing scheme is just 
insane. Modifying the file you are indexing is not just fundamentally 
wrong to begin with, but it will then also be incredibly inefficient to 
read those entries one at a time.

It's a typo and you are saying it _is_ fundamentally wrong, aren't you?

Not a typo, and I'm sayin that "it's not _just_ fundamentally wrong"

So yes, it's fundamentally wrong, but it's worse than that. It's 
fundamentally wrong _and_ it's inefficient as hell.

If you are prepared to pick up new files, you need to crawl everywhere
anyway, so if the xattr is used to leave a mark "The last time I looked at
this file was this" in the file itself, it does not sound too bad to me.

It's absolutely horrible. 

It means that you have another extra indirection and accompanying disk 
seek to check the thing. It's a total performance nightmare. Trust me, 
anybody who uses extended attributes like this simply does not know what 
he is doing.

It would be irritating that it touches ctime, though, but I do not use it
http://beagle-project.org/FAQ "Do I really need extended attributes?"
talks about BEAGLE_DISABLE_XATTR environment variable and interestingly
it says disabling use of xattr would slow you down.

They don't have a clue. They say that, but it's simply not true. 

Of course, the fact that they think it is probably implies that they did 
something EVEN MORE STUPID for the non-xattr case. That wouldn't surprise 
me at all. If I had to guess, I'd guess that they used an SQL database and 
query language, and did all their tests with hot caches too.

The kernel does caching really well, and the kernel is fast as hell, so 
_of_course_ when you benchmark, using kernel data structures looks good, 
especially if you benchmark against code that isn't well written for the 
particular usage case.

			Linus