Jerome Haynes-Smith wrote:
regarding ZFS compression method: what happens when a compressed file is
udpated/appended? Is it ALL un-compressed first, updated/appended and
then re-compressed? Or only the affected blocks are uncompressed and
then recompressed?
ZFS does NOT compress files. It compresses the individual blocks that
are written to comprise the file.
What this means is if you have a 10G file and you need to change one
small part in the middle you seek(2) to that point, read(2) the data
make your change to your in memory copy and write(2) it back out again.
ZFS will update (and recompress) only those blocks that actual need to
get changed.
How can this work? With compressed data, its hard to predict its final size
before compression.
Because you are NOT compressing the file only compressing the blocks as
they get written to disk.
How is the seek(2) accurate? How can the seek know where
the uncompressed block (say) 345 is after the data is compressed?
seek(2) doesn't know anything about compression that is all hidden below
in the implementation of ZFS.
seek(2) works on file offsets not block numbers on the raw storage device.
It will be
physically on a different actual block...??. or I probably dont understand
how compression with ZFS works.... ;-)
Or - does it compress an 8k block into a smaller 6 or 4K block, but with the
same block number, and so the seek to a block will still work, but less disk
space is taken up ?
A bit more like that yes, except that seek(2) doesn't (and shouldn't)
know anything about block numbers only file offsets.
--
Darren J Moffat
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
