On Thu, Jan 14, 2010 at 10:58:48AM +1100, Daniel Carosone wrote: > On Wed, Jan 13, 2010 at 08:21:13AM -0600, Gary Mills wrote: > > Yes, I understand that, but do filesystems have separate queues of any > > sort within the ZIL? > > I'm not sure. If you can experiment and measure a benefit, > understanding the reasons is helpful but secondary. If you can't > experiment so easily, you're stuck asking questions, as now, to see > whether the effort of experimenting is potentially worthwhile.
Yes, we're stuck asking questions. I appreciate your responses. > Some other things to note (not necessarily arguments for or against): > > * you can have multiple slog devices, in case you're creating > so much ZIL traffic that ZIL queueing is a real problem, however > shared or structured between filesystems. For the time being, I'd like to stay with the ZIL that's internal to the zpool. > * separate filesystems can have different properties which might help > tuning and experiments (logbias, copies, compress, *cache), as well > the recordsize. Maybe you will find that compress on mailboxes > helps, as long as you're not also compressing the db's? Yes, that's a good point in favour of a separate filesystem. > * separate filesystems may have different recovery requirements > (snapshot cycles). Note that taking snapshots is ~free, but > keeping them and deleting them have costs over time. Perhaps you > can save some of these costs if the db's are throwaway/rebuildable. Also a good point. > > If not, would it help to put the database > > filesystems into a separate zpool? > > Maybe, if you have the extra devices - but you need to compare with > the potential benefit of adding those devices (and their IOPS) to > benefit all users of the existing pool. > > For example, if the databases are a distinctly different enough load, > you could compare putting them on a dedicated pool on ssd, vs using > those ssd's as additional slog/l2arc. Unless you can make quite > categorical separations between the workloads, such that an unbalanced > configuration matches an unbalanced workload, you may still be better > with consolidated IO capacity in the one pool. As well, I'd like to keep all of the ZFS pools on the same external storage device. This makes migrating to a different server quite easy. > Note, also, you can only take recursive atomic snapshots within the > one pool - this might be important if the db's have to match the > mailbox state exactly, for recovery. That's another good point. It's certainly better to have synchronized snapshots. -- -Gary Mills- -Unix Group- -Computer and Network Services- _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
