Messages in this thread | | | Date | Tue, 28 Feb 2006 10:38:34 -0800 | From | Hans Reiser <> | Subject | Re: Drastic Slowdown of 'fseek()' Calls From 2.4 to 2.6 -- VMM Change? |
| |
Bill Davidsen wrote:
> Hans Reiser wrote: > >> Andrew Morton wrote: >> >>> runs like a dog on 2.6's reiserfs. libc is doing a (probably) 128k >>> read >>> on every fseek. >>> >>> - There may be a libc stdio function which allows you to tune this >>> behaviour. >>> >>> - libc should probably be a bit more defensive about this anyway - >>> plainly the filesystem is being silly. >>> >>> >> I really thank you for isolating the problem, but I don't see how you >> can do other than blame glibc for this. The recommended IO size is only >> relevant to uncached data, and glibc is using it regardless of whether >> or not it is cached or uncached. Do I misunderstand something >> myself here? > > > I think the issue is not "blame" but what effect this behavior would > have on things like database loads, where seek-write would be common. > Good to get this info to users and admins. > Well, ok, let me phrase it as "this should be fixed in glibc". Does anyone know who the maintainer for it is? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |