Marcelo Leal <[EMAIL PROTECTED]> wrote:
> Hello all,
> I think he got some point here... maybe that would be an interesting
> feature for that kind of workload. Caching all the metadata, would make t
> the rsync task more fast (for many files). Try to cache the data is really
> waste of time, because the data will not be read again, and will just send
> away the "good" metadata cached. That is what i understand when he said
> about the 96k being descarded soon. He wants to "configure" an area to
> "copy the data", and that´s it. Leave my metadata cache alone. ;-)
That's a common enough behavior pattern that Per Brinch Hansen
defined a distinct filetype for it in, if memory serves, the RC 4000.
As soon as it's read, it's gone.
We saw this behavior on NFS servers in the Markham ACE lab, and
absolutely with Samba almost everywhere. My Smarter Colleagues[tm]
explained it as a normal pattern whenever you have front-end
caching, as backend caching is then rendered far less effective, and
sometimes directly disadvantageous.
It sounded like, from the previous discussion, one could tune
for it with the level 1 and 2 caches, although if I understood
it properly, the particular machine also had to narrow a stripe
for the particular load being discussed...
--dave
--
David Collier-Brown | Always do right. This will gratify
Sun Microsystems, Toronto | some people and astonish the rest
[EMAIL PROTECTED] | -- Mark Twain
cell: (647) 833-9377, bridge: (877) 385-4099 code: 506 9191#
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
