Matthew Ahrens wrote:
Nicolas Dorfsman wrote:
We need to think ZFS as ZFS, and not as a new filesystem ! I mean,
the whole concept is different.
Agreed.
So. What could be the best architecture ?
What is the problem?
With UFS, I used to have separate metadevices/LUNs 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)
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
>
Nicolas Dorfsman wrote:
We need to think ZFS as ZFS, and not as a new filesystem ! I mean,
the whole concept is different.
Agreed.
So. What could be the best architecture ?
What is the problem?
With UFS, I used to have separate metadevices/LUNs for each
application. With ZFS, I thought it
> If you want to copy your filesystems (or snapshots)
> to other disks, you
> can use 'zfs send' to send them to a different pool
> (which may even be
> on a different machine!).
Oh no ! It means copy the whole filesystem. The target here is definitively to
snapshot the filesystem and them backu
Well.
> ZFS isn't copy-on-write in the same way that things
> like ufssnap are.
> ufssnap is copy-on-write in that when you write
> something, it copies out
> the old data and writes it somewhere else (the
> backing store). ZFS doesn't
> need to do this - it simply writes the new data to a
> new
