Roch Bourbonnais - Performance Engineering wrote On 05/12/06 09:30,:
Tao Chen writes:
> On 5/11/06, Peter Rival <[EMAIL PROTECTED]> wrote:
> > Richard Elling wrote:
> > > 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?
> >
> > 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.
> >
>
> The purpose of zero-filled tablespace is to prevent fragmentation by
> future writes, in the case when multiple tablespaces are being
> updated/filled on the same disk, correct?
That and also there was a need for block reservation. Thus
posix_fallocate was added (recently).
>
> > This becomes pointless on ZFS, since it never overwrites the same
> > pre-allocated block, i.e. the tablespace becomes fragmented in that
> > case no matter what.
>
> is fragmented the right word here ?
> Anyway: random writes can be turned into sequential.
This really optimizes the data on disk for full table scans
(sequential reads of the whole tables or portions of them).
Random access may be supported from a DMBS perspective using
indexes - then read access patterns are random anyway.
In contrast to usual files DBMS files exhibit different access patterns:
They are often loaded sequentially (resulting in a nice layout for
later sequential reads) yet updates to the tables will erode this
sequential layout over time (e.g. updating accounts as they are credited
and debited online), so later full table scans will suffer.
ZFS optimizes random writes versus potential sequential reads.
this may hurt if there are many full table scans - but DBMS
designers try to avoid unnecessary full table scans anyway.
On the other hand there are use cases in which tables are updated
randomly and read sequentially many times (e.g. in batch runs) -
here overall performance may suffer.
An way to resolve this could be an option to transparently "reorganize"
a file (a tool triggering an internal rewrite - such that the
data become sequential on disk again - on-the-fly while the
DBMS is running/file is open).
- Franz
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
