As for encrypting swap created by swapspace, I have a question:
http://askubuntu.com/questions/726577/how-can-you-setup-encrypted-swap-
with-swapspace
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to the bug report.
As for encrypting swap created by swapspace, I have a question:
http://askubuntu.com/questions/726577/how-can-you-setup-encrypted-swap-
with-swapspace
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Dropping this as won't fix.
** Changed in: livecd-rootfs (Ubuntu)
Status: Triaged => Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1533639
Title:
[ubuntu-cpc]
Dropping this as won't fix.
** Changed in: livecd-rootfs (Ubuntu)
Status: Triaged => Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1533639
Title:
[ubuntu-cpc] please make /tmp a
Let's not move forward with this right now. This decision needs more
data and more consensus before being actioned.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1533639
Title:
Let's not move forward with this right now. This decision needs more
data and more consensus before being actioned.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1533639
Title:
[ubuntu-cpc] please
swapspace sounds cool. I'll try it on my next installation of Ubuntu
instead of reserving a separate partition.
I think the Ubuntu installer could have an option for making /tmp a
tmpfs and for making suitable swap configuration for that thus adapting
to all needs. I use noatime option for
swapspace sounds cool. I'll try it on my next installation of Ubuntu
instead of reserving a separate partition.
I think the Ubuntu installer could have an option for making /tmp a
tmpfs and for making suitable swap configuration for that thus adapting
to all needs. I use noatime option for
If user has chosen encrypted home directory during installation of
Ubuntu, he/she probably wants encrypted swap, too. I am not sure, if
that is possible with swapspace.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
If user has chosen encrypted home directory during installation of
Ubuntu, he/she probably wants encrypted swap, too. I am not sure, if
that is possible with swapspace.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to the bug report.
** Description changed:
In Ubuntu, we clear /tmp on every boot.
As such, on servers, by default /tmp should actually be a tmpfs entirely
- in RAM.
+ in RAM, when there is enough memory in the system. This threshold
+ should be configurable by the end user (in cloud-init?), and default
+
** Description changed:
In Ubuntu, we clear /tmp on every boot.
As such, on servers, by default /tmp should actually be a tmpfs entirely
- in RAM.
+ in RAM, when there is enough memory in the system. This threshold
+ should be configurable by the end user (in cloud-init?), and default
+
** Description changed:
In Ubuntu, we clear /tmp on every boot.
As such, on servers, by default /tmp should actually be a tmpfs entirely
in RAM.
This has several advantages, mainly:
- * Performance - much faster read/write access to data in /tmp
- * Security - sensitive data would
** Description changed:
In Ubuntu, we clear /tmp on every boot.
As such, on servers, by default /tmp should actually be a tmpfs entirely
in RAM.
This has several advantages, mainly:
- * Performance - much faster read/write access to data in /tmp
- * Security - sensitive data would
** Description changed:
- In Ubuntu, we clear /tmp on every boot.
+ In Ubuntu, we have always cleared /tmp on every boot.
As such, on servers, by default /tmp should actually be a tmpfs entirely
in RAM, when there is enough memory in the system. This threshold
should be configurable by
** Description changed:
- In Ubuntu, we clear /tmp on every boot.
+ In Ubuntu, we have always cleared /tmp on every boot.
As such, on servers, by default /tmp should actually be a tmpfs entirely
in RAM, when there is enough memory in the system. This threshold
should be configurable by
** Description changed:
In Ubuntu, we have always cleared /tmp on every boot.
As such, on servers, by default /tmp should actually be a tmpfs entirely
in RAM, when there is enough memory in the system. This threshold
should be configurable by the end user (in cloud-init?), and default
** Description changed:
In Ubuntu, we have always cleared /tmp on every boot.
As such, on servers, by default /tmp should actually be a tmpfs entirely
in RAM, when there is enough memory in the system. This threshold
should be configurable by the end user (in cloud-init?), and default
** Description changed:
In Ubuntu, we have always cleared /tmp on every boot.
As such, on servers, by default /tmp should actually be a tmpfs entirely
in RAM, when there is enough memory in the system. This threshold
should be configurable by the end user (in cloud-init?), and default
** Description changed:
In Ubuntu, we have always cleared /tmp on every boot.
As such, on servers, by default /tmp should actually be a tmpfs entirely
in RAM, when there is enough memory in the system. This threshold
should be configurable by the end user (in cloud-init?), and default
> * Performance - much faster read/write access to data in /tmp
Is this really true? Writes to /tmp will go to the page cache, which I
believe is an identical path whether /tmp is backed by disk or by tmpfs.
Similarly reads from /tmp will come from the page cache except where
pages have been
> and then killing the system due to memory starvation
Actually I think tmpfs is limited to 50% of system RAM or something by
default, but that brings up another issue. By doing this we're severely
limiting the available disk in /tmp. Or does that not matter in the
cloud image case because / is
> * Performance - much faster read/write access to data in /tmp
Is this really true? Writes to /tmp will go to the page cache, which I
believe is an identical path whether /tmp is backed by disk or by tmpfs.
Similarly reads from /tmp will come from the page cache except where
pages have been
I'd also add that the cloud image build process isn't the right place to
make such a change, I don't think. It should be cloud-init or some
system boot script that is shipped by a package in the archive.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which
I'd also add that the cloud image build process isn't the right place to
make such a change, I don't think. It should be cloud-init or some
system boot script that is shipped by a package in the archive.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
> and then killing the system due to memory starvation
Actually I think tmpfs is limited to 50% of system RAM or something by
default, but that brings up another issue. By doing this we're severely
limiting the available disk in /tmp. Or does that not matter in the
cloud image case because / is
I am inclined to make the change here. The only problem that I can see
is that some smaller cloud instance types (*.micro on AWS, the upcoming
nano instance, GCE's micro, etc) this might be problematic.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
As an alternative solution, I am wondering if we could make this be a
cloud-init function to give users control, with a default of /tmp being
a tmpfs when memory is sufficient (i.e. if you have less than 1G of RAM,
/tmp is tmpfs or you are in a container).
The other area where I think that this
This doesn't sound like a good idea to me, given the prevalence of
running Ubuntu on virtual machines with less than 4GB of RAM. I'm
thinking specifically of hosting providers like Linode, AWS,
DigitalOcean, etc., as well as tools like Vagrant, all of which are
extremely popular right now. Using
This doesn't sound like a good idea to me, given the prevalence of
running Ubuntu on virtual machines with less than 4GB of RAM. I'm
thinking specifically of hosting providers like Linode, AWS,
DigitalOcean, etc., as well as tools like Vagrant, all of which are
extremely popular right now. Using
Can we publish some test images? Instead of guessing at this, we can
benchmark this.
In general swapping ram-based for what is almost always disk-based is
going to impact applications/deployments using tmp and expecting enough
space there. It's not uncommon for large ISO or other image
> The big disadvantage of a tmpfs /tmp is that it cannot be paged out
My mistake, this is untrue if you have swap enabled (and enough swap
available). I was thinking of ramfs. I still wonder what any performance
gain would be, though. Using tmpfs will still limit size to available
RAM + available
> The big disadvantage of a tmpfs /tmp is that it cannot be paged out
My mistake, this is untrue if you have swap enabled (and enough swap
available). I was thinking of ramfs. I still wonder what any performance
gain would be, though. Using tmpfs will still limit size to available
RAM + available
Can we publish some test images? Instead of guessing at this, we can
benchmark this.
In general swapping ram-based for what is almost always disk-based is
going to impact applications/deployments using tmp and expecting enough
space there. It's not uncommon for large ISO or other image
34 matches
Mail list logo
