Louwtjie Burger writes: > Hi > > After a clean database load a database would (should?) look like this, > if a random stab at the data is taken... > > [8KB-m][8KB-n][8KB-o][8KB-p]... > > The data should be fairly (100%) sequential in layout ... after some > days though that same spot (using ZFS) would problably look like: > > [8KB-m][ ][8KB-o][ ] > > Is this "pseudo logical-physical" view correct (if blocks n and p was > updated and with COW relocated somewhere else)? >
That's the proper view if the ZFS recordsize is tuned to be 8KB. That's a best practice that might need to be qualified in the future. > Could a utility be constructed to show the level of "fragmentation" ? > (50% in above example) > That will need to dive into the internals of ZFS. But anything is possible. It's been done for UFS before. > IF the above theory is flawed... how would fragmentation "look/be > observed/calculated" under ZFS with large Oracle tablespaces? > > Does it even matter what the "fragmentation" is from a performance > perspective? It matters to table scans and how those scans will impact OLTP workloads. Good blog topic. Stay tune. > _______________________________________________ > 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
