Hello,
while testing some code changes, I managed to fail an assertion while
doing a zfs create.
My zpool is now invulnerable to destruction. :(
bash-3.00# zpool destroy -f test_undo
internal error: unexpected error 0 at line 298 of ../common/libzfs_dataset.c
bash-3.00# zpool status
pool:
Jeremy Teo wrote:
How can I destroy this pool so I can use the disk for a new pool?
Thanks! :)
dd if=/dev/zero of=/dev/dsk/c0d1s1
dd if=/dev/zero of=/dev/dsk/c0d1s0
that should do it.
--
Darren J Moffat
___
zfs-discuss mailing list
On Thu, 2006-05-18 at 22:05 +0800, Jeremy Teo wrote:
My zpool is now invulnerable to destruction. :(
Nifty - does that mean your disk is also invulnerable to hardware errors
too ? [ as in, your typical superhero who gets endowed with special
abilities due to a failed radiation experiment ;-) ]
Sorry to revive such an old thread.. but I'm struggling here.
I really want to use zfs. Fssnap, SVM, etc all have drawbacks. But I work for a
University, where everyone has a quota. I'd literally have to create 10K
partitions. Is that really your intention? Of course, backups become a huge
On Thu, May 18, 2006 at 11:42:58AM -0700, Charlie wrote:
Sorry to revive such an old thread.. but I'm struggling here.
I really want to use zfs. Fssnap, SVM, etc all have drawbacks. But I
work for a University, where everyone has a quota. I'd literally have
to create 10K partitions. Is that
Why can't we just have user quotas in zfs? :)
+1 to that. I support a couple environments with group/user quotas that cannot
move to ZFS since they serve brain-dead apps that read/write from a single
directory.
I also agree that using even a few hundred mountpoints is more tedious than
On Thu, 2006-05-18 at 12:12 -0700, Eric Schrock wrote:
On Thu, May 18, 2006 at 11:42:58AM -0700, Charlie wrote:
Sorry to revive such an old thread.. but I'm struggling here.
I really want to use zfs. Fssnap, SVM, etc all have drawbacks. But I
work for a University, where everyone has a
On Thu, May 18, 2006 at 02:23:55PM -0600, Gregory Shaw wrote:
I'd agree except for backups. If the pools are going to grow beyond a
reasonable-to-backup and reasonable-to-restore threshold (measured by
the backup window), it would be practical to break it into smaller
pools.
Speaking of
On Thu, May 18, 2006 at 12:46:28PM -0700, Charlie wrote:
Traditional (amanda). I'm not seeing a way to dump zfs file systems to
tape without resorting to 'zfs send' being piped through gtar or
something. Even then, the only thing I could restore was an entire file
system. (We frequently
On 5/18/06, Gregory Shaw [EMAIL PROTECTED] wrote:
On Thu, 2006-05-18 at 12:12 -0700, Eric Schrock wrote:
On Thu, May 18, 2006 at 11:42:58AM -0700, Charlie wrote:
Sorry to revive such an old thread.. but I'm struggling here.
I really want to use zfs. Fssnap, SVM, etc all have drawbacks.
On Thu, May 18, 2006 at 12:46:28PM -0700, Charlie wrote:
Eric Schrock wrote:
Using traditional tools or ZFS send/receive?
Traditional (amanda). I'm not seeing a way to dump zfs file systems to
tape without resorting to 'zfs send' being piped through gtar or
something. Even then, the only
Bill Moore wrote:
On Thu, May 18, 2006 at 12:46:28PM -0700, Charlie wrote:
Eric Schrock wrote:
Using traditional tools or ZFS send/receive?
Traditional (amanda). I'm not seeing a way to dump zfs file systems to
tape without resorting to 'zfs send' being piped through gtar or
something. Even
On Thu, 2006-05-18 at 16:43 -0500, James Dickens wrote:
On 5/18/06, Gregory Shaw [EMAIL PROTECTED] wrote:
On Thu, 2006-05-18 at 12:12 -0700, Eric Schrock wrote:
On Thu, May 18, 2006 at 11:42:58AM -0700, Charlie wrote:
Sorry to revive such an old thread.. but I'm struggling here.
On the topic of ZFS snapshots:
does the snapshot just capture the changed _blocks_, or does it
effectively copy the entire file if any block has changed?
That is, assuming that the snapshot (destination) stays inside the same
pool space.
-Erik
On Thu, May 18, 2006 at 03:41:13PM -0700, Erik Trimble wrote:
On the topic of ZFS snapshots:
does the snapshot just capture the changed _blocks_, or does it
effectively copy the entire file if any block has changed?
Incremental sends capture changed blocks.
Snapshots capture all of the FS
Just piqued my interest on this one -
How would we enforce quotas of sorts in large filesystems that are
shared? I can see times when I might want lots of users to use the same
directory (and thus, same filesystem) but still want to limit the amount
of space each user can consume.
Thoughts?
Hello Roch,
Monday, May 15, 2006, 3:23:14 PM, you wrote:
RBPE The question put forth is whether the ZFS 128K blocksize is sufficient
RBPE to saturate a regular disk. There is great body of evidence that shows
RBPE that the bigger the write sizes and matching large FS clustersize lead
RBPE to
On Fri, 2006-05-19 at 10:18 +1000, Nathan Kroenert wrote:
Just piqued my interest on this one -
How would we enforce quotas of sorts in large filesystems that are
shared? I can see times when I might want lots of users to use the same
directory (and thus, same filesystem) but still want to
Since it's not exactly clear what you did with SVM I am assuming the
following:
You had a file system on top of the mirror and there was some I/O
occurring to the mirror. The *only* time, SVM puts a device into
maintenance is when we receive an EIO from the underlying device. So,
in case
19 matches
Mail list logo
