Richard Elling wrote:
On Thu, 2006-05-11 at 10:31 -0600, Gregory Shaw wrote:
A couple of points/additions with regard to oracle in particular:
When talking about large database installations, copy-on-write may
or may not apply. The files are never completely rewritten, only
changed internally via mmap(). When you lay down your database, you
will generally allocate the storage for the anticipated capacity
required. That will result in sparse files in the actual filesystems.
This is counter to my Oracle experience, which I'll admit is dated.
Oracle will zero-fill the tablespace with 128kByte iops -- it is not
sparse. I've got a scar. Has this changed in the past few years?
I have the same scar (from a different company). We actually wound up calling it the
"tablespace create benchmark". And that was valid as of work done just over a
year ago. Multiple parallel tablespace creates is usually a big pain point for
filesystem / cache interaction, and also fragmentation once in a while. The latter ZFS
should take care of; the former, well, I dunno.
Now, if compression is enabled, then this represents and interesting
challenge...
Indeed. One would think the intents of these two are rather divergent... How
about filling with /dev/random? ;)
- Pete
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
