Andrew <[EMAIL PROTECTED]> wrote:
Since ZFS is COW, can I have a read-only pool (on a central file
server, or on a DVD, etc) with a separate block-differential pool on
my local hard disk to store writes?
This way, the pool in use can be read-write, even if the main pool
itself is read-only, without having to make a full local copy of that
read-only pool in order to be able to write to it, and without having
to use messy filesystem-level union filesystem features.
Matthew Ahrens wrote:
These are some interesting use cases. I'll have to ponder how they
could be best implemented in ZFS.
Some of these cases can be solved simply by having a read-only device in
the pool (eg. live-boot DVDs). However, cases where you want to
transfer the data between devices are somewhat nontrivial (eg. hard
drive + flash memory), at least until we have 4852783 "reduce pool capacity".
I've filed RFE 6453741 "want mostly-read-only devices" to remember this
request.
I can see where this will lead to eventually...
I've seen several scenarios where 4852783 becomes essential. How to implement
such a thing? You first mark the vdev (do I say that correctly) as "evicting".
Then you start a full scrub/rewrite of the whole pool, with any "evict"-ing
components not available for writing, so the data is forced to be copied
elsewhere.
Once the scrub finishes, you change the state of the device to "evicted" and
remove it from the pool.
Odd thing is, with a read-only, or read-mostly device, you cannot put these
marks on the original disk in the first place. This is slightly contrary to
the concept of zfs storing all of its configuration and meta-data on-disk.
Which to me implies, that before you can actually start scrubbing the pool, you
first have to copy ALL metadata from the evicted device to the other devices in
the pool.
A consequence of this whole process is that this results in yet another
method of installing the OS:
- boot from a r/o zfs source image (dvd)
- add sufficient storage to capture changes.
- mark session as one of:
o transient - discard change-pool on halt/crash/reboot
o persistent - retain changes on reboot
o permanent - make the pool bootable independantly from the original r/o
image.
- followed by the parallel
- evict the source-image
- configure the system, and purge any history.
- if desired, reboot...
A final implication is that on such a system, you cannot ever use the
original source image, unless you tell the system explicitly NOT to import
any zfs devices besides the image.
The architecture of zfs is fascinating.
Cheers,
Henk
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
