From: "Ludovic Courtès" <ludo@gnu.org>
To: Ricardo Wurmus <rekado@elephly.net>
Cc: guix-devel@gnu.org
Subject: Upgrading storage on bordeaux.guix.gnu.org
Date: Mon, 06 Dec 2021 13:51:49 +0100 [thread overview]
Message-ID: <87pmq9nbfe.fsf_-_@gnu.org> (raw)
In-Reply-To: <87tufsq8ck.fsf@elephly.net> (Ricardo Wurmus's message of "Wed, 01 Dec 2021 23:04:22 +0100")
Hello!
(+Cc: Andreas.)
Ricardo Wurmus <rekado@elephly.net> skribis:
> [space is running out on bayfront, so I wrote:]
>
>> Remember that I’ve got three 256G SSDs here that I could send to
>> wherever bayfront now sits. With LVM or a RAID configuration these
>> could just be added to the storage pool — if bayfront has
>> sufficient slots for three more disks.
>
> You wrote in response:
>
>> Good to know. In that case we’d need to come up with (1) an updated
>> Guix System config with LVM, and (2) a way to copy the existing
>> store
>> over to the new storage, which sounds tricky if the existing disk is
>> to
>> be kept.
>
> We could first install Guix System with the adjusted bayfront config
> on a separate machine (e.g. on a build node at the MDC), onto a volume
> with LVM (using as many of the SSDs as needed). Copy signing keys etc
> from bayfront. Then we’d pretty much export/import the bayfront store
> over the network. Once everything has been copied, we turn off
> bayfront, swap the disks, boot it up again. If everything works all
> right we add the original disk (and any unused left-over disks) to the
> LVM volume to extend the storage pool.
Sounds like a plan. But note that there’s the store and there’s the
cached nars, though maybe we can tolerate missing, say, a week or two of
nars.
It would be more convenient to do that with a machine already in the
vicinity of bayfront though, so we can more easily move the disks there
when we’re ready. Maybe we could use a machine at Inria or the math
institute next door. Andreas, WDYT? (We can work out the details
off-list.)
>> (Also I think we’re down to 1.5 person who could go on
>> site. :-/)
>
> Not great :-/
Here’s a call: if you’re in the whereabouts of Bordeaux, France, and
would like to help, please get in touch with Andreas and myself! We
need to increase our tramway factor.
Cheers,
Ludo’.
next prev parent reply other threads:[~2021-12-06 12:55 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-24 8:52 Update on bordeaux.guix.gnu.org Christopher Baines
2021-11-28 17:26 ` Ludovic Courtès
2021-11-28 19:54 ` Ricardo Wurmus
2021-12-01 17:42 ` Ludovic Courtès
2021-12-01 22:04 ` Ricardo Wurmus
2021-12-06 12:51 ` Ludovic Courtès [this message]
2021-12-07 19:26 ` Upgrading storage " Maxim Cournoyer
2021-12-03 10:17 ` Update " Christopher Baines
2021-12-03 11:18 ` Ricardo Wurmus
2021-12-03 9:39 ` Christopher Baines
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87pmq9nbfe.fsf_-_@gnu.org \
--to=ludo@gnu.org \
--cc=guix-devel@gnu.org \
--cc=rekado@elephly.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.