On Qui, 2008-11-13 at 16:07 -0500, Miles Nordin wrote:
If you can find a small drive laying around, here is another option
that might work, but you could lose the whole pool due to some
miscalculation or another mistake:
1. make a new, small 1-drive zpool on the small drive
2. make a
Hi Richard,
On Qua, 2008-10-22 at 14:04 -0700, Richard Elling wrote:
It is more important to use a separate disk, than to use a separate and fast
disk. Anecdotal evidence suggests that using a USB hard disk works
well.
While I don't necessarily disagree with your statement, please note that
Hi Jeff,
On Sex, 2008-10-10 at 01:26 -0700, Jeff Bonwick wrote:
The circumstances where I have lost data have been when ZFS has not
handled a layer of redundancy. However, I am not terribly optimistic
of the prospects of ZFS on any device that hasn't committed writes
that ZFS thinks are
On Sex, 2008-10-10 at 11:23 -0700, Eric Schrock wrote:
But I haven't actually heard a reasonable proposal for what a
fsck-like tool (i.e. one that could repair things automatically) would
actually *do*, let alone how it would work in the variety of situations
it needs to (compressed RAID-Z?)
Hi Jack,
On Qui, 2008-09-11 at 15:37 -0700, Jack Dumson wrote:
Issues with ZFS and Sun Cluster
If a cluster node crashes and HAStoragePlus resource group containing
ZFS structure (ie. Zpool) is transitioned to a surviving node, the
zpool import can cause the surviving node to panic.
On Ter, 2008-06-03 at 23:33 +0100, Paulo Soeiro wrote:
6)Remove and attached the usb sticks:
zpool status
pool: myPool
state: UNAVAIL
status: One or more devices could not be used because the label is
missing
or invalid. There are insufficient replicas for the pool to continue
Hi Owen,
Owen Davies wrote:
I'm not sure of the implications of Luster using ZFS DMU. Does this mean a subset of ZFS functionality, binary compatibility of written disks or what?
It means Lustre will be using ZFS (instead of ext4/ldiskfs) as its disk
storage backend in metadata and
Steve McKinty wrote:
1) First issue relates to the überblock. Updates to it are assumed to be atomic, but if the replication block size is smaller than the überblock then we can't guarantee that the whole überblock is replicated as an entity. That could in theory result in a corrupt
