Re: Need help with live system expansion (zfs+geli)
Date: Sat, 17 Sep 2022 20:58:12 UTC
On Sat, Sep 17, 2022 at 2:49 PM milky india <milkyindia@gmail.com> wrote: > > > > On Sun, Sep 18, 2022 at 12:44 AM Alan Somers <asomers@freebsd.org> wrote: >> >> On Sat, Sep 17, 2022 at 2:42 PM milky india <milkyindia@gmail.com> wrote: >> > >> > >> > >> > On Sun, Sep 18, 2022 at 12:30 AM Alan Somers <asomers@freebsd.org> wrote: >> >> >> >> On Sat, Sep 17, 2022 at 2:25 PM milky india <milkyindia@gmail.com> wrote: >> >> > >> >> > >> >> > >> >> > On Sun, Sep 18, 2022 at 12:20 AM Alan Somers <asomers@freebsd.org> wrote: >> >> >> >> >> >> On Sat, Sep 17, 2022 at 2:03 PM milky india <milkyindia@gmail.com> wrote: >> >> >> > >> >> >> > >> >> >> > >> >> >> > On Sat, Sep 17, 2022 at 10:58 PM Alan Somers <asomers@freebsd.org> wrote: >> >> >> >> >> >> >> >> On Sat, Sep 17, 2022 at 12:52 PM milky india <milkyindia@gmail.com> wrote: >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > On Sat, Sep 17, 2022 at 10:43 PM Alan Somers <asomers@freebsd.org> wrote: >> >> >> >> >> >> >> >> >> >> On Sat, Sep 17, 2022 at 12:31 PM milky india <milkyindia@gmail.com> wrote: >> >> >> >> >> > >> >> >> >> >> > Sorry about that, again - I'm not sure what you mean by bottom-post 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-not-showing.86447/post-581642 >> >> >> >> >> > Is this advise wrong? >> >> >> >> >> > > "The geli has autoresize flag which will handle the new provider 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 figure it out without providing s?) >> >> >> >> >> > >> >> >> >> >> > On Sat, Sep 17, 2022 at 10:20 PM Alan Somers <asomers@freebsd.org> wrote: >> >> >> >> >> >> >> >> >> >> top-posting is where you insert your reply above the previous email. >> >> >> >> >> 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 from >> >> >> >> >> your "geli list" output, it's actually off. So you need to run "geli >> >> >> >> >> 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 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 partition? >> >> >> >> >> >> >> >> 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 reflect 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 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 nothing happens. >> >> > I'm not very sure if I put in the wrong value of s (old size) then "nothing 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 greater 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 resize 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 page says it's for the old size - that's why I was trying to figure it out and 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. > > > Thanks for acknowledging. I tried to do this using the s value from geli list - it won't let me even do it as sudo : > Getting a bit scared now. Should I not be writing `.eli` part? > ----------------------------------------------------------------- > sudo geli resize -s 311481593856 /dev/ada0p3.eli > Password: > geli: Cannot open /dev/ada0p3.eli: Operation not permitted. > sudo geli resize -s 311481593856 ada0p3.eli > geli: Cannot open ada0p3.eli: Operation not permitted. > --------------------------------------------------------------------------- Yes, you normally would not write the ".eli", because "geli resize" is normally used when geli is not attached. But it seems like you're currently booted from this device, right? In that case, detaching it isn't an easy option for you. If you like, you could try automatic expansion instead. First enable it. If it doesn't automatically expand when you enable that option, then you may have to "gpart resize" again. You can enable it with "geli configure -r /dev/ada0p3".