Phil Harman <phil.har...@sun.com> wrote:
> ZFS doesn't mix well with mmap(2). This is because ZFS uses the ARC
> instead of the Solaris page cache. But mmap() uses the latter. So if
> anyone maps a file, ZFS has to keep the two caches in sync.
>
> cp(1) uses mmap(2). When you use cp(1) it brings pages of the files it
> copies into the Solaris page cache. As long as they remain there ZFS
> will be slow for those files, even if you subsequently use read(2) to
> access them.
>
> If you reboot, your cpio(1) tests will probably go fast again, until
Do you believe that reboot is the only way to reset this?
> someone uses mmap(2) on the files again. I think tar(1) uses read(2),
> but from my iPod I can't be sure. It would be interesting to see how
> tar(1) performs if you run that test before cp(1) on a freshly
> rebooted system.
There are many tar implementations. The oldest is the UNIX tar implementation
from around 1978, the next was star from 1982, then there is GNU tar from 1987.
Star forks into two processes that are connected via shared memory in order to
speed up things.
If you compare the copy speed from star amd cp on UFS and if you tell star to
be as unreliable as cp (by specifying the star option -no-fsync), star will do
the job by 30% faster than cp does even though star does not use mmap. Copying
with Sun's tar is a tic faster than using cp and it is a bit more accurat.
GNU tar is not better than Sun's tar.
If you are looking for the best speed, use:
star -copy -no-fsync -C from-dir . to-dir
and set up e.v. bs=1m fs=128m.
Jörg
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni)
joerg.schill...@fokus.fraunhofer.de (work) Blog:
http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
