Hi Matt, > > So. What could be the best architecture ? > > What is the problem?
I/O profile isolation versus snap backing-store 'reservation' optimisation. > > With UFS, I used to have separate metadevices/LUNs for each > > application. With ZFS, I thought it would be nice to use a separate > > pool for each application. > > Ick. It would be much better to have one pool, and a > separate > filesystem for each application. Including performance considerations ? For instance, if I have two Oracle Databases with two I/O profiles (TP versus Batch)...what would be the best : 1) Two pools, each one on two LUNs. Each LUN distributed on n trays. 2) One pool on one LUN. This LUN distributed on 2 x n trays. 3) One pool striped on two LUNs. Each LUN distributed on n trays. > > But, it means multiply snapshot backing-store OR dynamically > > remove/add this space/LUN to pool where we need to do backups. > I don't understand this statement. What problem are > you trying to solve? > If you want to do backups, simply take a snapshot, then point > your backup program at it. With one pool, no problem. With n pools, my problem is the space used by the snapshot. With the COW method of UFS snapshot I can put all backing-stores on one single volume. With ZFS snapshot, it's conceptualy impossible. This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
