On Fri, Jan 26, 2007 at 10:57:19PM -0800, Frank Cusack wrote: > On January 27, 2007 12:27:17 AM -0200 Toby Thain <[EMAIL PROTECTED]> wrote: > >On 26-Jan-07, at 11:34 PM, Pawel Jakub Dawidek wrote: > >>3. I created file system with huge amount of data, where most of the > >>data is read-only. I change my server from intel to sparc64 machine. > >>Adaptive endianess only change byte order to native on write and > >>because > >>file system is mostly read-only, it'll need to byteswap all the time. > >>And here comes 'zfs rewrite'! > > > >Why would this help? (Obviously file data is never 'swapped'). > > Metadata (incl checksums?) still has to be byte-swapped. Or would > atime updates also force a metadata update? Or am I totally mistaken.
You're all correct. File data is never byte-swapped. Most metadata needs to be byte-swapped, but it's generally only 1-2% of your space. So the overhead shouldn't be significant, even if you never rewrite. An atime update will indeed cause a znode rewrite (unless you run with "zfs set atime=off"), so znodes will get rewritten by reads. The only other non-trivial metadata is the indirect blocks. All files up to 128k are stored in a single block: ZFS has variable blocksize from 512 bytes to 128k, so a 35k file consumes exactly 35k (not, say, 40k as it would with a fixed 8k blocksize). Single-block files have no indirect blocks, and hence no metadata other than the znode. So all that remains is the indirect blocks for files larger than 128k -- which is to say, not very much. Jeff _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
