From nobody Fri Mar 25 16:09:39 2022 X-Original-To: freebsd-fs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0897C1A323B0 for ; Fri, 25 Mar 2022 16:09:58 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ot1-f46.google.com (mail-ot1-f46.google.com [209.85.210.46]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KQ6Vr6DgPz3HpL for ; Fri, 25 Mar 2022 16:09:56 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-ot1-f46.google.com with SMTP id d15-20020a9d72cf000000b005cda54187c3so5819782otk.2 for ; Fri, 25 Mar 2022 09:09:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uvZudZYbNb08bb4DFwWyyLGkNcD/1uF3lKlSiopgTu4=; b=Pycv26Hv7bdkBmYfyw4u5y+052V88y/Bwf/zAYk+2UxApWokhBkvl+yOv2cM4WNiUS fijzXZBGcygHk5E/RE2eb/wVgqb3Vtu/sIJFNP7ytyxrNtWoNxdOWI5AauFAYeedYf9d +kF0P87+kWoCIZyoPxX7qM1ksEAoBPowP/Ju8QGmrE0z+6+g3ASGZh1eazKbecX5LFL9 AQwmieQMKPvkySbkW6/L0kEZHfBYfWsH4P9A283hfTftlJz918QyZ2oJ3+uJxACaiXZZ Uj5dobhjNJvh7bbNqTMxqjemM8S51WxCFdWHTFk2UL0eE9qknPNwdexG1kkNS4MtkUir bTbg== X-Gm-Message-State: AOAM5330KkOzPyV4lPtbvE/1AOwuTOx8URaaoVIHve/SqS4FuSzK/XKQ aNxfjkclzHk2ZpgFkJWokmUc77yaLCLepblALgPgsatk X-Google-Smtp-Source: ABdhPJyDc1zao5wME6iXwfn1wcn5PWJSK86RvdnuPdU2jb/uTdDn9Xjgt5lK4R112HYfbc6nx5wmytvvZ+EDaTnAzRM= X-Received: by 2002:a9d:6a84:0:b0:5cd:ad64:a50 with SMTP id l4-20020a9d6a84000000b005cdad640a50mr4555135otq.114.1648224590162; Fri, 25 Mar 2022 09:09:50 -0700 (PDT) List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org MIME-Version: 1.0 References: <95932839-F6F8-4DCB-AA7F-46040CFA1DE1@jld3.net> In-Reply-To: <95932839-F6F8-4DCB-AA7F-46040CFA1DE1@jld3.net> From: Alan Somers Date: Fri, 25 Mar 2022 10:09:39 -0600 Message-ID: Subject: Re: mirror vdevs with different sizes To: John Doherty Cc: freebsd-fs Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4KQ6Vr6DgPz3HpL X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.210.46 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-2.83 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[asomers]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[209.85.210.46:from]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-fs@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.84)[-0.840]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[209.85.210.46:from]; NEURAL_HAM_MEDIUM(-0.99)[-0.992]; MLMMJ_DEST(0.00)[freebsd-fs]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N There's nothing wrong with doing that. The performance won't be perfectly balanced, because the new disks will have a lower ratio of IOPS/TB. But that's fine. Go ahead. -Alan On Fri, Mar 25, 2022 at 9:17 AM John Doherty wrote: > > Hello, I have an existing zpool with 12 mirrors of 8 TB disks. It is > currently about 60% full and we expect to fill the remaining space > fairly quickly. > > I would like to expand it, preferably using 12 mirrors of 16 TB disks. > Any reason I shouldn't do this? > > Using plain files created with truncate(1) like these: > > [root@ibex] # ls -lh /vd/vd* > -rw-r--r-- 1 root wheel 8.0G Mar 25 08:49 /vd/vd0 > -rw-r--r-- 1 root wheel 8.0G Mar 25 08:49 /vd/vd1 > -rw-r--r-- 1 root wheel 16G Mar 25 08:49 /vd/vd2 > -rw-r--r-- 1 root wheel 16G Mar 25 08:49 /vd/vd3 > > I can first do this: > > [root@ibex] # zpool create ztest mirror /vd/vd{0,1} > [root@ibex] # zpool list ztest > NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP > HEALTH ALTROOT > ztest 7.50G 384K 7.50G - - 0% 0% 1.00x > ONLINE - > > And then do this: > > [root@ibex] # zpool add ztest mirror /vd/vd{2,3} > [root@ibex] # zpool list ztest > NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP > HEALTH ALTROOT > ztest 23G 528K 23.0G - - 0% 0% 1.00x > ONLINE - > > And FWIW, everything works as expected. But I've never constructed a > real zpool with vdevs of different sizes and I don't know whether there > might be any expected problems. > > I could just create a new zpool with new disks, but most of the existing > data and most of the expected new data is in just two file systems and > for simplicity's sake from the perspective of those users, it would be > nicer to just make the existing file systems larger than to give them > access to a new, different one. > > Any comments, suggestions, warnings, etc. much appreciated. Thanks. >