From nobody Sat Sep 17 20:44:20 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 4MVNGT4xZhz4cPZy for ; Sat, 17 Sep 2022 20:44:33 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-qv1-f52.google.com (mail-qv1-f52.google.com [209.85.219.52]) (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 4MVNGS6r5Fz40T9 for ; Sat, 17 Sep 2022 20:44:32 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-qv1-f52.google.com with SMTP id g4so19199745qvo.3 for ; Sat, 17 Sep 2022 13:44:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date; bh=ovtFai6JUFAj1DPq9jN6AgcRd6aLSkL0UM1g6FENJhQ=; b=tAQ5KCCeLFU1Dv/90LcoPl1Q3at+HeSo6pj8kjcjjOgmQYyW4epYHgD9uvrBpf65jL UW2fQitw7DCleYqFPJX9G20j/yPxQMKCDpOAcuo8RmnQ5G7/0pngDFjF0ID3gxqFJipu JAvWYrPccVLvY7PsN9U9S9WJi4tSer0yLdmbcZkevy3ILpobgyOBSR6bq25qFObX0OdE fMU5jFmzQbfYsVWRK4m/D62ftaTkUP1IXD/v4IrD6touKJwS4hljwo5DewmbRZ6Ajm+x Eimc5vPrGwpib7NdZGBA8lnocNL3A2RKXdbhAPk1KAvBT1k79Wlic4Rs5H1li4sAq8v5 Bydw== X-Gm-Message-State: ACrzQf2Hh+iYfN4ZAErPLhF9hStWNh8Nv0b9pbrIX1uuWlIxmc1bVWrj HKrfn6PAMLm4lJCQHAlRmDOUSxrqRoIVO1nXQO8= X-Google-Smtp-Source: AMsMyM6MTNt47xLBq4IhEQz+6DqomkfhbeG50XX3Dw7u4CDxMeWV19WBxVxouU5JxvLNJq7D5rnjIf38RpJ4x7FS3Jo= X-Received: by 2002:a0c:f1c7:0:b0:474:725e:753e with SMTP id u7-20020a0cf1c7000000b00474725e753emr9400293qvl.49.1663447472227; Sat, 17 Sep 2022 13:44:32 -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: In-Reply-To: From: Alan Somers Date: Sat, 17 Sep 2022 14:44:20 -0600 Message-ID: Subject: Re: Need help with live system expansion (zfs+geli) To: milky india Cc: freebsd-fs Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4MVNGS6r5Fz40T9 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.219.52 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-2.99 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_SHORT(-1.00)[-0.996]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-fs@freebsd.org]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; FREEMAIL_TO(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; R_DKIM_NA(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.219.52:from]; RCVD_IN_DNSWL_NONE(0.00)[209.85.219.52:from]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[asomers]; RCPT_COUNT_TWO(0.00)[2]; PREVIOUSLY_DELIVERED(0.00)[freebsd-fs@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[freebsd.org]; TO_DN_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Sat, Sep 17, 2022 at 2:42 PM milky india wrote: > > > > On Sun, Sep 18, 2022 at 12:30 AM Alan Somers wrote: >> >> On Sat, Sep 17, 2022 at 2:25 PM milky india wrote= : >> > >> > >> > >> > On Sun, Sep 18, 2022 at 12:20 AM Alan Somers wro= te: >> >> >> >> On Sat, Sep 17, 2022 at 2:03 PM milky india wr= ote: >> >> > >> >> > >> >> > >> >> > On Sat, Sep 17, 2022 at 10:58 PM Alan Somers = wrote: >> >> >> >> >> >> On Sat, Sep 17, 2022 at 12:52 PM milky india wrote: >> >> >> > >> >> >> > >> >> >> > >> >> >> > On Sat, Sep 17, 2022 at 10:43 PM Alan Somers wrote: >> >> >> >> >> >> >> >> On Sat, Sep 17, 2022 at 12:31 PM milky india wrote: >> >> >> >> > >> >> >> >> > Sorry about that, again - I'm not sure what you mean by botto= m-post vs top-post. >> >> >> >> > >> >> >> >> > Be that as it may - I read the geli man page. I was specifica= lly warned against using "geli resize" since it may not work as expected ht= tps://forums.FreeBSD.org/threads/how-to-extend-zfs-geli-encrypted-disk-spac= e-not-showing.86447/post-581642 >> >> >> >> > Is this advise wrong? >> >> >> >> > > "The geli has autoresize flag which will handle the new pro= vider size after gpart resize command." >> >> >> >> > followed by >> >> >> >> > > You are right, no geli resize needed. >> >> >> >> > >> >> >> >> > What would be the correct sequence of commands to fix this - = Simply "geli resize" ? (the -s option seems to be additional, will it figur= e it out without providing s?) >> >> >> >> > >> >> >> >> > On Sat, Sep 17, 2022 at 10:20 PM Alan Somers wrote: >> >> >> >> >> >> >> >> top-posting is where you insert your reply above the previous e= mail. >> >> >> >> Bottom posting is where you insert your reply below it, like I'= m >> >> >> >> doing. The forum user said that you shouldn't need to run "gel= i >> >> >> >> resize" because the AUTORESIZE flag is on. But as you can see = from >> >> >> >> your "geli list" output, it's actually off. So you need to run= "geli >> >> >> >> resize". The "-s" flag should be unnecessary since your provid= er is >> >> >> >> already online. At any rate, you can try it both ways. You mi= ght >> >> >> >> want to make a copy of /var/backups/ada0p3.eli, just in case yo= u make >> >> >> >> a mistake. >> >> >> > >> >> >> > Thanks - I hope I am bottom posting this as was expected of me. >> >> >> > >> >> >> > So if I understand correctly the AUTORESIZE flag is present for = adaop2 and NOT for adap3 (which is the partition we are concerned about) - = hence the advice given to not use "geli resize" isn't applicable here. Am I= understanding this correctly? >> >> >> >> >> >> Yes >> >> >> >> >> >> > >> >> >> > > So you need to run "geli resize" >> >> >> > Is this the only command that I need to run to resize my geli pa= rtition? >> >> >> >> >> >> Yes >> >> >> >> >> >> > >> >> >> > > The "-s" flag should be unnecessary since your provider is >> >> >> > already online. >> >> >> > Ok thanks. >> >> >> > >> >> >> > >You might want to make a copy of /var/backups/ada0p3.eli, just = in case you make a mistake. >> >> >> > Don't have the luxury of backup currently. >> >> >> >> >> >> Um, ok. I can't guess why you aren't able to do that, but it isn'= t >> >> >> strictly necessary. >> >> >> >> >> >> > >> >> >> > I suppose at the end of it - if this works - "geli list" would r= eflect the size to be 458G? (vs 290G currently) >> >> >> > And that's the output I can trust to have solved the issue - or = is there more to it? >> >> >> >> >> >> Yes. >> >> > >> >> > > The "-s" flag should be unnecessary since your provider is alread= y online. >> >> > When I try to run "geli resize /dev/ada0p3.eli" it complains. So I = guess options s is must ? If yes - do I need to put in the exact size down = to bytes from the output of geli list ? Under "Mediasize" ? >> >> > --------------------------------------- >> >> > geli: Option 's' not specified. >> >> > ---------------------------------------- >> >> >> >> Dude, it's easier just to try it, than to ask us. Go for it. The >> >> worst case scenario if you get the argument wrong is that nothing >> >> happens. >> > >> > >> > > The worst case scenario if you get the argument wrong is that nothin= g happens. >> > I'm not very sure if I put in the wrong value of s (old size) then "no= thing happens" - I would imagine if I put in a size less than the current s= ize then possibly the data after that get's lost? Or if I put in a size gre= ater than the current size then there is a gap in the geli partition? >> > I sense some frustration in your reply - but I'm on a live system and = wouldn't want to possibly risk it going kaput at this last step. That's the= reason I'm trying to understand what is the best value of s for geli resiz= e and how to obtain it. >> >> The purpose of the "-s" argument is to tell geli where to find the old >> label, if the provider isn't already attached. If you supply the >> wrong argument, then geli won't be able to find the label, and thus >> won't be able to do anything. It won't destroy any data, and it will >> always automatically determine the size of the current provider. Of >> course, if you're worried about losing data, you should always save a >> copy of /var/backups/ada0p3.eli, as I suggested. >> -Alan > > > >The purpose of the "-s" argument is to tell geli where to find the old > > label, if the provider isn't already attached. If you supply the > > wrong argument, then geli won't be able to find the label, and thus > > won't be able to do anything. > > I think you're confusing the -s argument with something else - the man pa= ge says it's for the old size - that's why I was trying to figure it out an= d still haven't been able to quite yet. Although I suspect the "Mediasize" = output for p3 from "geli list" is what the s value should be - but not very= sure : > -------------------------------------------------------------------------= ----------------- > Additional options include: > > -s oldsize The size of the provider before it = was resized. > -------------------------------------------------------------------------= ----------------------- Yes, that's right. geli needs to know the old size of the provider in order to find the provider's old label.