On Aug 1, 2011, at 2:16 PM, Neil Perrin wrote: > In general the blogs conclusion is correct . When file systems get full there > is > fragmentation (happens to all file systems) and for ZFS the pool uses gang > blocks of smaller blocks when there are insufficient large blocks. > However, the ZIL never allocates or uses gang blocks. It directly allocates > blocks (outside of the zio pipeline) using zio_alloc_zil() -> > metaslab_alloc(). > Gang blocks are only used by the main pool when the pool transaction > group (txg) commit occurs. Solutions to the problem include: > - add a separate intent log
Yes, I thought that it was odd that someone who is familiar with Oracle databases, and their redo logs, didn't use separate intent logs. > - add more top level devices (hopefully replicated) > - delete unused files/snapshots etc with in the poll… If gang activity is the root cause of the performance, then they must be at the edge of effective space utilization. -- richard > > Neil. > > > On 08/01/11 08:29, Josh Simon wrote: >> Hello, >> >> One of my coworkers was sent the following explanation from Oracle as to why >> one of backup systems was conducting a scrub so slow. I figured I would >> share it with the group. >> >> http://wildness.espix.org/index.php?post/2011/06/09/ZFS-Fragmentation-issue-examining-the-ZIL >> >> >> PS: Thought it was kind of odd that Oracle would direct us to a blog, but >> the post is very thorough. >> >> Thanks, >> >> Josh Simon >> >> _______________________________________________ >> zfs-discuss mailing list >> zfs-discuss@opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
