Paul B. Henson wrote:
On Wed, 13 May 2009, Richard Elling wrote:

If I wanted to swap between a 32GB SSD and a 1TB SATA drive, I guess I
would need to make a partition/slice on the TB drive of exactly the
size of the SSD?
Yes, but note that an SMI label hangs onto the outdated notion of
cylinders and you can't make a slice except on cylinder boundaries.

Hmm... So I probably wouldn't be able to use the entire SSD, but instead
create a partition on both the SSD and the SATA drive of the same size?
They wouldn't necessarily have the same cylinder size, right? So I'd have
to find the least common multiple of the cylinder sizes and create
partitions appropriately.

You can always change the cylinder sizes to suit, or use EFI labels.

In general I know it is recommended to give ZFS the entire disk, in the
specific case of the ZIL will there be any performance degradation if it is
on a slice of the SSD rather than the entire disk?

The "use full disk" recommendation should make zero difference for an
SSD.  It only applies to HDDs with volatile write buffers (caches).

In that case, the pool knows the log device is failed.

So, if I understand correctly, if the log device fails while the pool is
active, the log device is marked faulty, logging returns to in-pool, and
everything works perfectly fine and happy like until the log device is
replaced? It would seem the only difference between a pool without a log
device and one with a failed log device is that the latter knows it used to
have a log device? If so, it would seem trivial to support removing a log
device from a pool, unless I'm misunderstanding why has that not been
implemented?

This is CR6574286
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6574286
-- richard

Just as in the disabled ZIL case, the on-disk format is still correct.
It is client applications that may be inconsistent.  There may be a way
to recover the pool, Sun Service will have a more definitive stance.

Eh, Sun Service doesn't necessarily like definitiveness :).

However, I do have multiple service contracts, and probably will open a
ticket requesting further details on upcoming log improvements and recovery
modes. It would be nicer to hear it straight from the source (hint hint
hint ;) ), but barring that hopefully I can get it escalated to someone who
can fill in the gaps.

Thanks much...

_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to