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
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 backup
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
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
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
