Carsten Aulbert wrote:
Hi Richard,
Richard Elling wrote:
Files are not compressed in ZFS. Blocks are compressed.
Sorry, yes, I was not specific enough.
If the compression of the blocks cannot gain more than 12.5% space savings,
then the block will not be compressed. If your file contains
compressable parts
and uncompressable parts, then (depending on the size/blocks) it may be
partially compressed.
I guess the block size is related (or equal) to the record size set for
this file system, right?
The block size is dynamic, but for large files will likely top out at the
recordsize.
What will happen then if I have a file which contains a header which
fits into 1 or 2 blocks, and is followed by stretches of data which are
say 500kB each (for simplicity) which could be visualized as sitting in
a rectangle with M rows and N columns. Since the file system has no way
of knowing details on the file, it will "cut" the file into blocks and
store it compressed or uncompressed as you have written. However, what
happens if the typical usage pattern is read only columns of the
"rectangle", i.e. read the header, seek to the start of stretch #1, then
seeking to stretch #N+1, ...
File systems do this even if the blocks are not compressed.
I can read your question as asking whether or not the file will always be
stored in contiguous blocks. The general answer is no, especially since
ZFS has a COW architecture. But the practical impacts of this are difficult
to predict, because there is so much caching occuring at all levels of the
data path. Suffice to say, if you think your disks are seeking themselves
to death, there is a simple dtrace script, iopattern, which will prove or
disprove the case.
Can ZFS make educated guesses where the seek targets might be or will it
read the file block by block until it reaches the target position, in
the latter case it might be quite inefficient if the file is huge and
has a large variance in compressibility.
This isn't a ZFS function, per se. If a program is written to seek(),
then it
can seek. If a program is written to sequentially read, then it will do
that.
The reason I say "per se" above, is because there is, by default, some
prefetching which can occur at the device or file level. For magnetic
disks,
the prefetching is usually free because it costs so much time to move the
head. For SSDs, I think the jury is still out... we just don't have enough
collective experience to know that prefetching will never be a win.
-- richard
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
