On Wed, Jul 7, 2010 at 11:50 AM, Nick Piggin <npiggin@xxxxxxx> wrote:
>
> Well we do want to be simple I think, but it's not *totally* just
> for dbench performance :) Actually dbench is supposed to be an fs
> syscall reply of samba running a file server workload. For one
> reason or another, it calls statvfs a lot.
It seems to call statvfs() mainly because it wants the disk free block
information, afaik. I can't find anything that cares about f_flag.
In fact, the few f_flag usages I found on google code search have that
access conditional, usually by some configure script thing (ie
HAVE_STATVFS_F_FLAG). The samba code I found was to _generate_ f_flag
(from internal samba code), not to actually use it.
Oh, I'm sure I missed some case, but quite frankly, from looking at
the stuff I _did_ find, it looks like the real problem has always been
the stupid glibc emulation code rather than anything else. Without
that emulation code and without any f_flags member in user space,
everything I saw would have been perfectly happy. They'd just have
compiled the f_flag code away.
So from my quick grep, it really does look like the real problem was
always that glibc made things overly complicated, and emulated some
documented SuS interface (slowly) that nobody really ever cared about,
and thus made up the performance problem in the first place. Yes, it's
mentioned in SuS, but at the same time, judging by the config script
hackery, different unixes seem to have called it "f_flag" and
"f_flags" or not had it at all. So it can't be _that_ important.
And other uses are equally happy to use statfs() instead of statvfs(),
again making it more or less clear that they certainly don't care
about the magic f_flag field.
It looks like another "paper standard" thing, in other words.
And if this teaches us anything, that _should_ be that people should
not try to emulate paper standards badly. If there is no native system
call, don't emulate it with some random crap.
Linus
--
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
