From nobody Sat Sep 17 20:30:12 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 4MVMy85BLnz4cM7Y for ; Sat, 17 Sep 2022 20:30:24 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-qk1-f182.google.com (mail-qk1-f182.google.com [209.85.222.182]) (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 4MVMy80Lmbz3xSr for ; Sat, 17 Sep 2022 20:30:24 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-qk1-f182.google.com with SMTP id 3so17744799qka.5 for ; Sat, 17 Sep 2022 13:30:24 -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=k5kwUqRgqxUe6z7Ij8ElcP+iSZv8YNTwJPgoZ23KCB8=; b=nG9X/ULhii5i2+fsb9Sa3s4WAcGwFYv4QV0WK3cYd5D51S/xkSI7CitUyP8FuQJoJS bqxuHsW+sbUNb0GNgaFhVtOpGFop6K/JBKkhqdCOND7+mK9Zp8YT2DTApKqkUiaVgl11 yeouS8p4n7ZiHMx14l157Km+/Qx35JG8C+l+aXN3E65mcSJapmhea7q7fgka8FOPHp4q C3XLK8bYl2MMS4aSvFsoU+23s56K7My40gfAkbLOMewp6qQHrnxwU2R2X26HqiIAIATM QWhBX2zNFUyiVQUSlaHL133gMvIx6/x4EkpOFFq2wonpjRKWVL61zF3eJ8asYwRjFIj6 lrpA== X-Gm-Message-State: ACrzQf1TernXqtSHFeSQ2BcPoUfyzmlSJyWRuAm3QX+oKhp9VFK6NSXA zLwFPet+tyLSrlp7Mwe00gUnykcxAzFRqWohiGQ= X-Google-Smtp-Source: AMsMyM6oO3DTFpgauK8hO39oI/UHr/1teYd2UCAxtpoNfZVnevc6kWqb7ZfNzNmZ2YpHFHVRKe9NH3Unzo+xvicD2t4= X-Received: by 2002:a05:620a:99b:b0:6ce:4c0a:3ab2 with SMTP id x27-20020a05620a099b00b006ce4c0a3ab2mr8311787qkx.250.1663446623393; Sat, 17 Sep 2022 13:30:23 -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:30:12 -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: 4MVMy80Lmbz3xSr 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.222.182 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-2.99 / 15.00]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_LONG(-0.99)[-0.993]; 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.222.182:from]; RCVD_IN_DNSWL_NONE(0.00)[209.85.222.182: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:25 PM milky india wrote: > > > > On Sun, Sep 18, 2022 at 12:20 AM Alan Somers wrote: >> >> On Sat, Sep 17, 2022 at 2:03 PM milky india wrote= : >> > >> > >> > >> > On Sat, Sep 17, 2022 at 10:58 PM Alan Somers wro= te: >> >> >> >> On Sat, Sep 17, 2022 at 12:52 PM milky india w= rote: >> >> > >> >> > >> >> > >> >> > 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 bottom-p= ost vs top-post. >> >> >> > >> >> >> > Be that as it may - I read the geli man page. I was specifically= warned against using "geli resize" since it may not work as expected https= ://forums.FreeBSD.org/threads/how-to-extend-zfs-geli-encrypted-disk-space-n= ot-showing.86447/post-581642 >> >> >> > Is this advise wrong? >> >> >> > > "The geli has autoresize flag which will handle the new provid= er 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 - Sim= ply "geli resize" ? (the -s option seems to be additional, will it figure i= t 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 emai= l. >> >> >> 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 "geli >> >> >> resize" because the AUTORESIZE flag is on. But as you can see fro= m >> >> >> your "geli list" output, it's actually off. So you need to run "g= eli >> >> >> resize". The "-s" flag should be unnecessary since your provider = is >> >> >> already online. At any rate, you can try it both ways. You might >> >> >> want to make a copy of /var/backups/ada0p3.eli, just in case you m= ake >> >> >> 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 ada= op2 and NOT for adap3 (which is the partition we are concerned about) - hen= ce the advice given to not use "geli resize" isn't applicable here. Am I un= derstanding this correctly? >> >> >> >> Yes >> >> >> >> > >> >> > > So you need to run "geli resize" >> >> > Is this the only command that I need to run to resize my geli parti= tion? >> >> >> >> 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 refl= ect 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 already o= nline. >> > When I try to run "geli resize /dev/ada0p3.eli" it complains. So I gue= ss 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 nothing h= appens. > I'm not very sure if I put in the wrong value of s (old size) then "nothi= ng happens" - I would imagine if I put in a size less than the current size= then possibly the data after that get's lost? Or if I put in a size greate= r 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 wou= ldn't want to possibly risk it going kaput at this last step. That's the re= ason I'm trying to understand what is the best value of s for geli resize a= nd 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