Re: Drastic Slowdown of 'fseek()' Calls From 2.4 to 2.6 -- VMM Change?

[Hans Reiser <reiser@namesys.com>]

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?

>- You can alter the filesystem's behaviour by mounting with the
>  `nolargeio=1' option.  That sets stat.blksize back to 4k.
>
>  This will alter the behaviour of every reiserfs filesystem in the
>  machine.  Even the already mounted ones.
>
>  `mount -o remount,nolargeio=1' can probably also be used.  But that
>  won't affect inodes which are already in cache - a umount/mount cycle may
>  be needed.
>
>  If you like, you can just mount and unmount a different reiserfs
>  filesystem to switch this reiserfs filesystem's behaviour.  IOW: the
>  reiserfs guys were lazy and went and made this a global variable :(
>
>- fseek is a pretty dumb function anyway - you're better off with
>  stateless functions like pread() - half the number of syscalls, don't
>  have to track where the file pointer is at.  I don't know if there's a
>  pread()-like function in stdio though?
>
>No happy answers there, sorry.  But a workaround.
>
>
>  
>

-
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/