ZFS vs UFS2 overhead and may be a bug?
Bakul Shah
bakul at bitblocks.com
Fri May 4 19:42:46 UTC 2007
> >> Interesting. There are two problems. First is that cat(1) uses
> >> st_blksize to find out best size of I/O request and we force it to
> >> PAGE_SIZE, which is very, very wrong for ZFS - it should be equal to
> >> recordsize. I need to find discussion about this:
>
> >> ...
> >> sb->st_blksize = PAGE_SIZE;
> >
> > This does seem suboptimal. Almost always one reads an entire
>
> It's just broken.
What should it be?
> > file and the overhead of going to the disk is high enough
> > that one may as well read small files in one syscall. Apps
> > that want to keep lots and lots of files open can always
> > adjust the buffer size.
> >
> > Since disk seek access time is the largest cost component,
> > ideally contiguously allocated data should be read in one
> > access in order to avoid any extra seeks. At the very least
>
> Buffering makes the userland i/o size have almost no effect on
> physical disk accesses. Perhaps even for zfs, since IIRC your
> benchmark showed anamolies for the case of sparse files where
> no disk accesses are involved.
This is perhaps a separate problem from that of sparse file
access. In my tests on regular files (not sparse) ZFS took
8% more time to read a 10G file when 4K buffer was used and
90% more time for 1K buffer. May be it is simply the ZFS
overhead but as size of read() buffer has an non-negligible
effect, something needs to be done.
More information about the freebsd-fs
mailing list