zfs code - Dec 2007 - Recurring Hex Pattern on ZFS

Hello All,

For a Operating Systems project my partner and I are investigating ZFS''
on disk layout for files and how it maintains full-stripe writes for RAIDZ. 
During our investigation, we have noticed that the hex pattern 0xFC42 is being
written all over the disk and in large chunks.  It seems to be written when
files are accessed or even during idle periods.  It also appears both in regular
ZFS mirros as well as RAIDZ pools.  The writes of this pattern are not contained
any one area of the disk either.  We have tried to think of what kind of data
would be written in this manner and have come up blank.

We thought this pattern may be related to checksums and so we tried removing all
the 20,000 or so FC42 patterns from a disk (we are using file backing stores). 
We then scrubbed the pool and we got only 28 checksum errors.  When we again
looked at the backing store, only about a quarter of the FC42 pattern returned.

Does anyone recognize this pattern and explain why this is being written to the
disk?

Thanks,
Brian and Kynan
--
This messages posted from opensolaris.org

It''s an artifact of metadata compression with lzjb.  When you
get a run of zeroes, it compresses down into the FC42 pattern.
(We can clearly do better, BTW -- working on it.)

Jeff

On Sat, Dec 08, 2007 at 02:18:14PM -0800, Brian Hickmann
wrote:
> Hello All,
> 
> For a Operating Systems project my partner and I are investigating
ZFS'' on disk layout for files and how it maintains full-stripe writes
for RAIDZ.  During our investigation, we have noticed that the hex pattern
0xFC42 is being written all over the disk and in large chunks.  It seems to be
written when files are accessed or even during idle periods.  It also appears
both in regular ZFS mirros as well as RAIDZ pools.  The writes of this pattern
are not contained any one area of the disk either.  We have tried to think of
what kind of data would be written in this manner and have come up blank.
> 
> We thought this pattern may be related to checksums and so we tried
removing all the 20,000 or so FC42 patterns from a disk (we are using file
backing stores).  We then scrubbed the pool and we got only 28 checksum errors. 
When we again looked at the backing store, only about a quarter of the FC42
pattern returned.
> 
> Does anyone recognize this pattern and explain why this is being written to
the disk?
> 
> Thanks,
> Brian and Kynan
> --
> This messages posted from opensolaris.org
> _______________________________________________
> zfs-code mailing list
> zfs-code at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-code