I'm pretty sure that's ZFS because less than 25MB are sent through the network before the file starts playing, but more than 800MB are read from the server before the file starts. Usually there's a 2-3 second delay between when the VLC window opens and when you see the video and hear audio. It COULD be that VLC needed certain info from certain parts of the file yielding the high read rates and low utilization of data.
No, it's not ZFS. Look, we can EXPERIMENT. It's real simple. Run "zpool iostat 1" in one window. Run commands in another. Make sure you're NOT reading the same data so as to force a read off the disk (see below).
So here's what you do. Reading 25MB of data does not result in ZFS reading and caching 800MB of data. It's straightforward. Do "dd if=file.foo of=/dev/null bs=1048576 count=25". Assuming a fast system, you'll see a little spike
Code:
storage0 7.08T 3.80T 0 113 0 567K
storage0 7.08T 3.80T 481 138 59.5M 666K
storage0 7.08T 3.80T 0 116 0 578K
where that 59.5M coincides exactly with me hitting return. So ZFS is reading the requested 25MB, plus another 29.5MB which is 34GB, a tad above what I said was the maximum buffer, but then again it had to read metadata to open the file, and there is other light activity going on with the system too.
I did the dd you requested and it read 17.4MB. I ran it a second time and got 0, which I assume means the data is in the cache?
Right. Now play around with it a bit. You won't find ZFS reading gobs of data. It isn't efficient to do so. If it sees a file where prefetching is successful, it WILL try to prefetch a larger buffer but only up to about 32MB of data or thereabouts. And that only happens when several megabytes have already been read. If you go and read 1KB, it isn't going to prefetch 32MB.