unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Ludovic Courtès" <ludo@gnu.org>
To: "Robert Smith" <robertsmith@posteo.net>
Cc: guix-devel@gnu.org
Subject: Re: Provide an option to specify the tmpfs size of the container
Date: Thu, 21 Jan 2021 12:02:45 +0100	[thread overview]
Message-ID: <87h7nablii.fsf@gnu.org> (raw)
In-Reply-To: <C7Z30470ONBH.3SMMFXBPYKBEW@amber> (Robert Smith's message of "Mon, 21 Dec 2020 21:57:06 -0800")

Hi,

"Robert Smith" <robertsmith@posteo.net> skribis:

> On Mon Dec 14, 2020 at 10:56 AM Ludovic Courtès wrote:
>> Hi,
>> 
>> luhux <luhux@outlook.com> skribis:
>> 
>> > I am using guix environment --container to containerize my programming environment and runtime environment, but I found that the container / created by this command uses tmpfs and cannot be resized.
>> >
>> > When a file in the container outputs a lot of logs to the tmpfs of the container, the memory usage of the host will be very high (this is usually something I did not expect)
>> >
>> > So can provide an option to specify the size of tmpfs?
>> 
>> Sure, why not.  Would you like to give it a try?
>
> This feature caught my interest and I wanted to investigate a bit :)
> tmpfs defaults to half of the available RAM, with the 'size=' option to
> the mount command we can increase this limit but I believe that the
> upper bound is the sum of the available RAM + swap space.

OK.

> Would it be worthwhile to allow for the container filesystem to be
> stored in a non-temporary filesystem, for example allowing the user to
> specify the parent directory of the container root? This would let the
> container fs grow as large as the computer storage allows.

Yes.  This happens in ‘mount-file-systems’ in (gnu build
linux-container):

  ;; The container's file system is completely ephemeral, sans directories
  ;; bind-mounted from the host.
  (mount "none" root "tmpfs")

So we can change it and make sure the temporary root directory is
cleaned up afterwards.  The only use case where this might be useful is
log files, as luhux reported, since in cases where you want to preserve
data, you’d use ‘--share’ instead.

The downside of not using a tmpfs is that data written to the file
system is visible outside the container, in /tmp/guix-directory.XXX,
though that directory is 700.

Thanks,
Ludo’.


      reply	other threads:[~2021-01-21 11:03 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-09 13:58 Provide an option to specify the tmpfs size of the container luhux
2020-12-14  9:56 ` Ludovic Courtès
2020-12-22  5:57   ` Robert Smith
2021-01-21 11:02     ` Ludovic Courtès [this message]

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

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87h7nablii.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=guix-devel@gnu.org \
    --cc=robertsmith@posteo.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 public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).