I would more vote for a feature to have a zpool level property of
/redundancy/ (or something along that) that I can set to
/off//(default)|mirror|raidz/ that then enforces zpool add to be
supplied a vdev specification of at least (or exactly that) that level
of redundancy, else fail with descriptiv
> From: ilove zfs
> Sent: Thursday, March 03, 2016 10:47 PM
>
> This talk about accidentally adding a non-redundant top level vdev is a
bit
> bizarre:
Hmm, I've never done it myself, but I've heard horror stories from people
who have? Maybe it used to be easier?
---
---
openzfs-developer
Archives: https://www.listbox.com/member/archive/274414/=now
RSS Feed: https://www.listbox.com/member/archive/rss/274414/28015062-cce53afa
Modify Your Subscription:
https://www.listbox.com/member/?member_id=28015062&id_secret=280150
On 03/04/2016 01:27 AM, Paul B. Henson wrote:
> On Fri, Mar 04, 2016 at 12:50:15AM -0500, Richard Yao wrote:
>
>> My vote is for "Please don't integrate without mirror/RAID-Z
>> support - all ZFS features should work together."
>
> I think all the people who have ever accidentally added a non-red
On 03/04/2016 12:50 AM, Richard Yao wrote:
> On 03/02/2016 12:31 PM, Matthew Ahrens wrote:
>> On Wed, Mar 2, 2016 at 12:37 AM, Erik Sørnes wrote:
>>
>>> Hi!
>>>
>>> Are there any plans on implementing functionality to remove an entire vdev
>>> from a pool ?
>>>
>>> One could write zpool remove vd
On Fri, Mar 04, 2016 at 12:50:15AM -0500, Richard Yao wrote:
> My vote is for "Please don't integrate without mirror/RAID-Z
> support - all ZFS features should work together."
I think all the people who have ever accidentally added a non-redundant
top level vdev and screwed themselves with no way
On 03/02/2016 12:31 PM, Matthew Ahrens wrote:
> On Wed, Mar 2, 2016 at 12:37 AM, Erik Sørnes wrote:
>
>> Hi!
>>
>> Are there any plans on implementing functionality to remove an entire vdev
>> from a pool ?
>>
>> One could write zpool remove vdev , and it would
>> move the data on to other vdev
On 3/2/16 5:08 PM, Matthew Ahrens wrote:
I'll read that as "please don't integrate without mirror removal
because it will entice people to run 'zpool detach' to reduce their
redundancy". Let me know if I've misinterpreted your (Ray and
ilovezfs) position.
I assume your concern about "total
> On Mar 3, 2016, at 1:53 AM, Steven Hartland wrote:
>
> On 03/03/2016 03:41, PK1048 wrote:
>>> On Mar 2, 2016, at 22:14, ilove zfs wrote:
>>>
>>> Yes, exactly. The unintended consequence of saving one group from a
>>> fat-fingered "zpool add" will be dooming another group to pool loss.
>> Th
On 03/03/2016 03:41, PK1048 wrote:
On Mar 2, 2016, at 22:14, ilove zfs wrote:
Yes, exactly. The unintended consequence of saving one group from a fat-fingered
"zpool add" will be dooming another group to pool loss.
There are plenty of ways to set yourself up for pool loss. One of the streng
> On Mar 2, 2016, at 22:14, ilove zfs wrote:
>
> Yes, exactly. The unintended consequence of saving one group from a
> fat-fingered "zpool add" will be dooming another group to pool loss.
There are plenty of ways to set yourself up for pool loss. One of the strengths
of Unix and Unix-like OSe
---
openzfs-developer
Archives: https://www.listbox.com/member/archive/274414/=now
RSS Feed: https://www.listbox.com/member/archive/rss/274414/28015062-cce53afa
Modify Your Subscription:
https://www.listbox.com/member/?member_id=28015062&id_secret=280150
Hello Phil,
Thursday, March 3, 2016, 2:56:59 AM, you wrote:
> My default position would be "Please don't integrate without
> mirror/RAID-Z support - all ZFS features should work together.”
> However, in this case I would make an exception. I have a friend who
> once attempted to add a log device
FWIW …
My default position would be "Please don't integrate without mirror/RAID-Z
support - all ZFS features should work together.” However, in this case I would
make an exception. I have a friend who once attempted to add a log device to a
large production pool, but omitted the prefix “log” -
I'll read that as "please don't integrate without mirror removal because it
will entice people to run 'zpool detach' to reduce their redundancy". Let
me know if I've misinterpreted your (Ray and ilovezfs) position.
I assume your concern about "total pool loss" is if the remaining plain
device fai
To be honest, this would result in people loss as well, since this may well
be a resume-generating event.
There are 10 kinds of people in the world; those who can read binary and
those who can't.
On Thu, Mar 3, 2016 at 1:58 AM, ilove zfs wrote:
> s/total people loss/total pool loss/ lol
>
> On
On Wed, Mar 2, 2016 at 9:54 AM, Rich wrote:
> I agree, halfway there but stable is reasonable to integrate.
>
> Are there actual plans to improve this for removing all other vdev types,
> or is this just an "eventually we would like to do this" sort of thing?
>
It isn't on our (Delphix') roadmap,
On 3/2/16 9:56 AM, ilove zfs wrote:
I'd be concerned that this will lead a significant number of people to
total people loss when they start dismantling mirror vdevs in order to
be able to remove them, and then run without redundancy during the
course of the removal.
For mirrors, is exactly
---
openzfs-developer
Archives: https://www.listbox.com/member/archive/274414/=now
RSS Feed: https://www.listbox.com/member/archive/rss/274414/28015062-cce53afa
Modify Your Subscription:
https://www.listbox.com/member/?member_id=28015062&id_secret=280150
---
openzfs-developer
Archives: https://www.listbox.com/member/archive/274414/=now
RSS Feed: https://www.listbox.com/member/archive/rss/274414/28015062-cce53afa
Modify Your Subscription:
https://www.listbox.com/member/?member_id=28015062&id_secret=280150
I agree, halfway there but stable is reasonable to integrate.
Are there actual plans to improve this for removing all other vdev types,
or is this just an "eventually we would like to do this" sort of thing?
Does this currently only work with pools that do not contain any
raidz/mirror vdevs, or i
On Mar 2, 2016, at 5:39 PM, Josef 'Jeff' Sipek wrote:
> On Wed, Mar 02, 2016 at 09:31:28 -0800, Matthew Ahrens wrote:
> ...
>> We'd also appreciate opinions of "Please upstream even without
>> mirror/RAID-Z support"
>
> I am for this. Simply because it lets one undo an accidental zpool add
> (in
On Wed, Mar 02, 2016 at 09:31:28 -0800, Matthew Ahrens wrote:
...
> We'd also appreciate opinions of "Please upstream even without
> mirror/RAID-Z support"
I am for this. Simply because it lets one undo an accidental zpool add
(instead of a zpool attach).
Jeff.
--
mainframe, n.:
An obsolete
On Wed, Mar 2, 2016 at 12:37 AM, Erik Sørnes wrote:
> Hi!
>
> Are there any plans on implementing functionality to remove an entire vdev
> from a pool ?
>
> One could write zpool remove vdev , and it would
> move the data on to other vdevs in the pool and then remove the
> vdev entirely.
> Thi
Hi!
Are there any plans on implementing functionality to remove an entire vdev from
a pool ?
One could write zpool remove vdev , and it would move
the data on to other vdevs in the pool and then remove the vdev
entirely.
This is very usefull for many use cases. I've googled a lot, and haven
25 matches
Mail list logo
