On Thu, Jun 16, 2011 at 09:44:47PM +0200, Michael Biebl wrote:
> I'm wondering what the plans are regarding /etc/init.d/mountoverflowtmp and
> RAMTMP. Will mountoverflowtmp be dropped if you enable RAMTMP by default?
It will still be needed as a fallback if the admin chose to
disable RAMTMP, or co
Hi Roger,
I'm wondering what the plans are regarding /etc/init.d/mountoverflowtmp and
RAMTMP. Will mountoverflowtmp be dropped if you enable RAMTMP by default?
Cheers,
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
signat
Hi Roger!
Thanks for answering in such detail. I'll try to comment on a few points.
Am 15.06.2011 22:46, schrieb Roger Leigh:
> On Wed, Jun 15, 2011 at 05:33:59PM +0100, Roger Leigh wrote:
>
> The FHS defines the persistence/lifetime for /tmp and /var/tmp.
> It does not make any recommendations
On Wed, Jun 15, 2011 at 05:33:59PM +0100, Roger Leigh wrote:
> On Wed, Jun 15, 2011 at 05:56:59PM +0200, Petter Reinholdtsen wrote:
> > [Michael Biebl]
> > > the default for new installations is to use RAMTMP=yes.
> >
> > Hm, do not remember doing this change. Anyone know when it happened?
>
> T
[Michael Biebl]
> For the examples I mentioned, those files don't need to be
> persistent, so /var/tmp would not be the right place.
I must have been unclear. /var/tmp/ is not for persistent data. It
is for temporary data, but not expected to disappear during boot.
/tmp/ is for temporary data wh
Am 15.06.2011 19:13, schrieb Petter Reinholdtsen:
> [Michael Biebl]
>> For this type of data /var/tmp is not the right place.
>
> Actually, /var/tmp/ is the right place for this kind of data.
For the examples I mentioned, those files don't need to be persistent, so
/var/tmp would not be the right
[Michael Biebl]
> For this type of data /var/tmp is not the right place.
Actually, /var/tmp/ is the right place for this kind of data.
I am sure there are programs saving large files in /tmp/, but for me
this only proves that there are programs with bugs around. Bugs that
should be fixed, not wo
Am 15.06.2011 18:34, schrieb Michael Biebl:
> Fact of the matter is, that there is software out there using /tmp to store
> large amount of temporary data (which doesn't need to survive reboots, so
> /var/tmp would be the wrong place).
To be a bit more specific about this. I at least remember fsa
Hi Roger!
Am 15.06.2011 18:33, schrieb Roger Leigh:
> On Wed, Jun 15, 2011 at 05:56:59PM +0200, Petter Reinholdtsen wrote:
>
> This was done following the discussion about default size limits
> for the various tmpfses in use (/run, /run/lock, /run/shm, and
> /tmp) on the debian-devel list, and al
Am 15.06.2011 17:56, schrieb Petter Reinholdtsen:
> [Michael Biebl]
>> the default for new installations is to use RAMTMP=yes.
>
> Hm, do not remember doing this change. Anyone know when it happened?
>
>> I think having RAMTMP as optional feature is great, but it should
>> default to no, because
On Wed, Jun 15, 2011 at 05:56:59PM +0200, Petter Reinholdtsen wrote:
> [Michael Biebl]
> > the default for new installations is to use RAMTMP=yes.
>
> Hm, do not remember doing this change. Anyone know when it happened?
This was done as part of the /run work a couple of months back.
This was do
[Michael Biebl]
> the default for new installations is to use RAMTMP=yes.
Hm, do not remember doing this change. Anyone know when it happened?
> I think having RAMTMP as optional feature is great, but it should
> default to no, because this is the safer default:
> - virtual machines are usually
12 matches
Mail list logo
