On Sun, 23 Nov 2008, Tamer Embaby wrote: >> That is the trade-off between "always consistent" and >> "fast". >> > Well, does that mean ZFS is not best suited for database engines as > underlying filesystem? With databases it will always be fragmented, > hence slow performance?
Assuming that the filesystem block size matches the database size there is not so much of an issue with fragmentation because databases are generally fragmented (almost by definition) due to their nature of random access. Only a freshly written database from carefully ordered insert statements might be in a linear order, and only for accesses in the same linear order. Database indexes could be negatively impacted, but they are likely to be cached in RAM anyway. I understand that zfs uses a slab allocator so that file data is reserved in larger slabs (e.g. 1MB) and then the blocks are carved out of that. This tends to keep more of the file data together and reduces allocation overhead. Fragmentation is more of an impact for large files which should usually be accessed sequentially. Zfs's COW algorithm and ordered writes will always be slower than for filesystems which simply overwrite existing blocks, but there is a better chance that the database will be immediately usable if someone pulls the power plug, and without needing to rely on special battery-backed hardware. Bob ====================================== Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
