1 |
On Oct 28, 2014 12:31 AM, "Rich Freeman" <rich0@g.o> wrote: |
2 |
> |
3 |
> On Mon, Oct 27, 2014 at 12:52 PM, Pandu Poluan <pandu@××××××.info> wrote: |
4 |
> > |
5 |
> > ZoL (ZFS on Linux) nowadays is implemented using DKMS instead of FUSE, |
6 |
thus |
7 |
> > running in kernelspace, and (relatively) easier to put into an |
8 |
initramfs. |
9 |
> |
10 |
> Sorry about that. I should have known that, but for some reason I got |
11 |
> that memory crossed in my brain... :) |
12 |
> |
13 |
> > vdevs can grow, but they can't (yet) shrink. |
14 |
> |
15 |
> Can you point to any docs on that, including any limitations/etc? The |
16 |
> inability to expand raid-z the way you can do so with mdadm was one of |
17 |
> the big things that has been keeping me away from zfs. I understand |
18 |
> that it isn't so important when you're dealing with large numbers of |
19 |
> disks (backblaze's storage pods come to mind), but when you have only |
20 |
> a few disks being able to manipulate them one at a time is very |
21 |
> useful. Growing is the more likely use case than shrinking. Then |
22 |
> again, at some point if you want to replace smaller drives with larger |
23 |
> ones you might want a way to remove drives from a vdev. |
24 |
> |
25 |
|
26 |
First, you need to set your pool to "autoexpand=on". |
27 |
|
28 |
Then, one by one, you offline a disk within the vdev and replace it with a |
29 |
larger one. After all disks have been replaced, do a scrub, and ZFS will |
30 |
automagically enlarge the vdev. |
31 |
|
32 |
If you're not using whole disks as ZFS, then s/replace with larger/enlarge |
33 |
the partition/. |
34 |
|
35 |
Rgds, |
36 |
-- |