FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian User

 
 
LinkBack Thread Tools
 
Old 03-25-2012, 06:09 AM
Stan Hoeppner
 
Default how to increase space for tmpfs /tmp

On 3/24/2012 4:02 PM, Javier Vasquez wrote:
> 2012/3/24 shirish शिरीष <shirishag75@gmail.com>:

>> # TMPFS_SIZE: maximum size for all tmpfs filesystems if no specific
>> # size is provided. If no value is provided here, the kernel default
>> # will be used.
>> TMPFS_SIZE=20%
>
> See, this is as you wish. This particular setting is the maximum for
> ALL of the tmpfs space. Kind of the default if nothing else is
> specified. You might not touch this if you don't want. So I would
> not be afraid of using 100% of RAM here.

That's probably not a smart idea:

http://www.kernel.org/doc/Documentation/filesystems/tmpfs.txt
...
tmpfs has three mount options for sizing:

size: The limit of allocated bytes for this tmpfs instance. The
default is half of your physical RAM without swap. If you
oversize your tmpfs instances the machine will deadlock
since the OOM handler will not be able to free that memory.
...

The OP would likely be far better off simply mounting /tmp on his root
filesystem as was always done in the past. Application developers
writing to /tmp aren't expecting memory speed transfers of such files
because of the traditional placement of /tmp. And he'll have more than
enough space, many times his RAM quantity.

FWIW, my Squeeze servers are all upgrades going back to Sarge, IIRC.
Here's my /tmp setup:

$ df /tmp
Filesystem Type Size Used Avail Use% Mounted on
/dev/sda2 ext2 33G 3.8G 28G 12% /

I'm sure some/many of you will gasp at that fact I still use EXT2. If
it ain't broke, don't "fix" it. The /boot and root filesystems are on
EXT2, with all data storage on XFS. Never had problems with EXT2 in
this setup, so it lives on, for now.

--
Stan


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4F6EB693.30009@hardwarefreak.com">http://lists.debian.org/4F6EB693.30009@hardwarefreak.com
 
Old 03-25-2012, 10:51 AM
Camalen
 
Default how to increase space for tmpfs /tmp

On Sat, 24 Mar 2012 12:40:12 -0600, Javier Vasquez wrote:

> On Sat, Mar 24, 2012 at 11:10 AM, Camalen <noelamac@gmail.com> wrote:

>>>> You may also consider filing a bug, since the more people report
>>>> problems with Debian's new, absurdly small /tmp, the more likely it
>>>> is to get fixed.
>>
>> +5
>>
>>> Why?
>>
>> Because the default is giving some headaches to the users?
>>
>>
> How many? Or how many would you consider critical mass to make things
> change?

Many is many (enough to catch other user's attention) ;-)

There is a refrain we use in Spain that says: "Cuando el ro suena, agua
lleva" or in English "Where there's smoke, there's fire". A default
setting should not make noise and when people starts complaining about it
is not a good sign.

> To me it's just not possible to provide defaults satisfying all users.

Of course.

But when something that was working stops doing it my auto-defense system
sends me a warn (beep, beep!) and I have to find what have caused the
problem. When a default setting is causing the problem then the default
is not good for me. When other users complain for the same issue, then
the default is neither good for they and it can be a signal for that
default is reviewed and commented with other community of users to get
more feedback.

> The important thing for the distro is to make sure to provide options so
> the user can tweak the system as he/she wants/needs. Not that it will
> be perfect by default for his/her needs. And this is already the case
> for this tmpfs thing.

(...)

Sure, but there's always room for improvement and this is how open
communities work. Choosing a bad default setting can be seen as something
annoying for power users who change it and end of the problem, but a
newbie or newcomer can simply think: "heck, what a bad system is this
linux thingy that gets out of memory for running a simple uncompressing
task...".

There are defaults that make more sense than others and defaults should
me IMO, as neutral as possible :-)

>> There was a recent discussion in this same list about that entitled
>> "[Feedback needed] Setting the right size for /tmp" (it was opened by
>> me), I would recommend reading people's comments to get a wider outlook
>> on this with their pros and cons.
>
> With so much traffic, I usually miss some e-mails... I'll have to look
> for that one you started...

Sorry for not having attached the link, I was a bit hurry. Here it is:

http://lists.debian.org/debian-user/2011/11/msg02155.html
http://lists.debian.org/debian-user/2012/02/msg01614.html
http://lists.debian.org/debian-user/2012/03/msg00277.html

(the thread was splitted bewteen different months)

Greetings,

--
Camalen


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: jkmtar$q88$6@dough.gmane.org">http://lists.debian.org/jkmtar$q88$6@dough.gmane.org
 
Old 03-27-2012, 01:13 PM
Roger Leigh
 
Default how to increase space for tmpfs /tmp

On Sun, Mar 25, 2012 at 10:51:07AM +0000, Camalen wrote:
> On Sat, 24 Mar 2012 12:40:12 -0600, Javier Vasquez wrote:
> > On Sat, Mar 24, 2012 at 11:10 AM, Camalen <noelamac@gmail.com> wrote:
> >>>> You may also consider filing a bug, since the more people report
> >>>> problems with Debian's new, absurdly small /tmp, the more likely it
> >>>> is to get fixed.
> >> +5
> >>> Why?
> >> Because the default is giving some headaches to the users?
> > How many? Or how many would you consider critical mass to make things
> > change?
> > To me it's just not possible to provide defaults satisfying all users.
>
> Of course.
>
> But when something that was working stops doing it my auto-defense system
> sends me a warn (beep, beep!) and I have to find what have caused the
> problem. When a default setting is causing the problem then the default
> is not good for me. When other users complain for the same issue, then
> the default is neither good for they and it can be a signal for that
> default is reviewed and commented with other community of users to get
> more feedback.

As the person who created these defaults, just a few points for
everyone in this thread to consider:

The existing defaults are not intended to be universally usable.
They are intended to work on every system to provide a certain
base level of functionality. That being said, improvements are
always welcome. The defaults are intended to work on even
systems without swap, so are intentionally small:

/run RUN_SIZE 10%
/run/lock LOCK_SIZE 5MiB
/run/shm SHM_SIZE[=TMPFS_SIZE] 20%
/tmp TMP_SIZE[=TMPFS_SIZE] 20%
--------
50%+5MiB
--------

The intention here is that if every tmpfs is filled, you only commit
50% of core memory. Of course, if you have lots of swap space, you
can increase these limits massively. Or you can disable the use of
tmpfs (except for /run) and use normal filesystems. The run and lock
sizes are I think appropriate for all but the most extreme uses.
shm and tmp are very dependent upon specific application use, and
choosing sensible defaults here is hard.

Regarding altering of the size limits: currently hardcoded in
/lib/init/tmpfs.sh. We could compute these dynamically if we
know at the time how much swap is additionally available. Or
have different profiles depending upon expected usage.

Regarding the use of /tmp on tmpfs being the default. I still
think that tmpfs makes sense for /tmp. It is certainly appropriate
for many users. We can certainly improve the defaults if we
understand what problems users are having. But they need to be
reported.

A common (and very persuasive) argument for not mounting a tmpfs
on /tmp and instead using the root filesystem is that by default
we install with a single large root filesystem, and /tmp gets to
use all the free space there. This is certainly true, and is a
major reason why we should consider doing this. However, the
following points also need to be considered:

- having /tmp on / means that / needs to be writable by default
- having "limitless" space on /tmp means it can be abused by
both users and applications. It can lead to breakage on
systems with a limited /tmp if applications make the
(incorrect) assumption that they can store whatever they like
there. It's more sensible to provide a minimum guarantee.
- /var/tmp exists, and should be used in many of the cases where
/tmp is being filled.

It's hard to get a clear picture of what generally useful defaults
should be when you only get feedback from a handful of users.

What should the minimum space be for /tmp?
What is the minimum space an individual user or application should
be able to use?
Should certain applications be patched not to use /tmp for
storing "excessively large" files?
etc.

These are obviously not questions with straightforward answers.
But I hope they do help to provide some understanding as to why
simply not using tmpfs on /tmp is not necessarily the "right" or
best long-term strategy. This definitely needs more thought, but
it also needs a greater understanding of what users and applications
expect /tmp to provide.

Investigating what other init systems and distributions do might be
instructive here.

When we introduced these defaults, we wanted to make them configurable
directly in the installer, by making tmpfs mounts editable in the
partitioner (or removed entirely). I'd still like to do this, but it
needs someone with the time to add tmpfs filesystem support to d-i. I
took a look a few months back, but lacked the time or d-i expertise to
do this.

[There are prior discussions of this on -devel, which probably
include more detail and other things I unintentionally omitted.]


Regards,
Roger

--
.'`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120327131323.GC30121@codelibre.net">http://lists.debian.org/20120327131323.GC30121@codelibre.net
 
Old 03-27-2012, 02:58 PM
Camalen
 
Default how to increase space for tmpfs /tmp

On Tue, 27 Mar 2012 14:13:23 +0100, Roger Leigh wrote:

> On Sun, Mar 25, 2012 at 10:51:07AM +0000, Camalen wrote:
>> On Sat, 24 Mar 2012 12:40:12 -0600, Javier Vasquez wrote:

(...)

>> > To me it's just not possible to provide defaults satisfying all
>> > users.
>>
>> Of course.
>>
>> But when something that was working stops doing it my auto-defense
>> system sends me a warn (beep, beep!) and I have to find what have
>> caused the problem. When a default setting is causing the problem then
>> the default is not good for me. When other users complain for the same
>> issue, then the default is neither good for they and it can be a signal
>> for that default is reviewed and commented with other community of
>> users to get more feedback.
>
> As the person who created these defaults, just a few points for everyone
> in this thread to consider:

Ahem! So it were you... okay, okay... let me a minute so I can sharpen my
sword >:-) (just kidding).

> The existing defaults are not intended to be universally usable. They
> are intended to work on every system to provide a certain base level of
> functionality. That being said, improvements are always welcome.

That's understandable but maybe asking to the Debian community for
feedback would have been a good idea to see what other users think about
this, what problems they experience with the chosen default or providing
additional improvements. I (as a user) already did it so by asking here
and knowing about other's experience.

> The defaults are intended to work on even systems without swap, so are
> intentionally small:
>
> /run RUN_SIZE 10%
> /run/lock LOCK_SIZE 5MiB /run/shm SHM_SIZE[=TMPFS_SIZE]
> 20%
> /tmp TMP_SIZE[=TMPFS_SIZE] 20%
> --------
> 50%+5MiB
> --------

Which is the source of many of the user's problems and complaints.

> The intention here is that if every tmpfs is filled, you only commit 50%
> of core memory. Of course, if you have lots of swap space, you can
> increase these limits massively. Or you can disable the use of tmpfs
> (except for /run) and use normal filesystems. The run and lock sizes
> are I think appropriate for all but the most extreme uses. shm and tmp
> are very dependent upon specific application use, and choosing sensible
> defaults here is hard.

I've had no problems at all with "/run" and "/run/lock" and still keep
them using the default settings (tmpfs). With "/tmp" is another story.

(...)

> Regarding the use of /tmp on tmpfs being the default. I still think
> that tmpfs makes sense for /tmp. It is certainly appropriate for many
> users. We can certainly improve the defaults if we understand what
> problems users are having. But they need to be reported.

I already gave my POV on this. Having a "tmpfs" for "/tmp" can be a good
default as long as it accomodates the space properly. That is, I will
never give 100 MiB to /tmp, that's simply crazy for a system with 250 GiB
of hard disk space as any simple operating that uses /tmp will crash at
the middle of the run.

> A common (and very persuasive) argument for not mounting a tmpfs on /tmp
> and instead using the root filesystem is that by default we install with
> a single large root filesystem, and /tmp gets to use all the free space
> there. This is certainly true, and is a major reason why we should
> consider doing this.

I also share that feeling.

> However, the following points also need to be considered:
>
> - having /tmp on / means that / needs to be writable by default
> - having "limitless" space on /tmp means it can be abused by
> both users and applications. It can lead to breakage on systems with
> a limited /tmp if applications make the (incorrect) assumption that
> they can store whatever they like there. It's more sensible to
> provide a minimum guarantee.
> - /var/tmp exists, and should be used in many of the cases where
> /tmp is being filled.
>
> It's hard to get a clear picture of what generally useful defaults
> should be when you only get feedback from a handful of users.

IMO, the rule of thumb for applying a new default is asking ourselves if
the new default will cause any problem to the users. If yes, then don't
touch the old default and keep it the way it was. If we are not going to
get any improvement but just for the 10% of our user-base, then we are
failing the 90% of the rest.

> What should the minimum space be for /tmp? What is the minimum space an
> individual user or application should be able to use?
> Should certain applications be patched not to use /tmp for storing
> "excessively large" files?
> etc.

First questions that need to be asked (in this order) would be:

- Should we need to set tmpfs as default for /tmp?
- If yes, what could be the default size? Going to the limits or keep it
small and handy?

> These are obviously not questions with straightforward answers. But I
> hope they do help to provide some understanding as to why simply not
> using tmpfs on /tmp is not necessarily the "right" or best long-term
> strategy. This definitely needs more thought, but it also needs a
> greater understanding of what users and applications expect /tmp to
> provide.

Every user will find his/her way to manage this. But unless I get any
compelling reason to enable it again, it will be off by (my) default.

> Investigating what other init systems and distributions do might be
> instructive here.
>
> When we introduced these defaults, we wanted to make them configurable
> directly in the installer, by making tmpfs mounts editable in the
> partitioner (or removed entirely). I'd still like to do this, but it
> needs someone with the time to add tmpfs filesystem support to d-i. I
> took a look a few months back, but lacked the time or d-i expertise to
> do this.

Being configurable from the installer is a great idea provided it can be
also disabled from here. Anyway, most of the users will just keep the
default settings because they will doubt about what's the best for their
systems (keep tmpfs on/off, tpmfs size...).

> [There are prior discussions of this on -devel, which probably include
> more detail and other things I unintentionally omitted.]

Yes, I already was pointed to that thread and read it in detail. And
thanks for taking the time to write such a detailed explanation and share
your thoughts on this.

Greetings,

--
Camalen


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: jkskjc$di0$10@dough.gmane.org">http://lists.debian.org/jkskjc$di0$10@dough.gmane.org
 
Old 03-28-2012, 12:50 PM
Andrei POPESCU
 
Default how to increase space for tmpfs /tmp

On Ma, 27 mar 12, 14:58:52, Camalen wrote:
>
> IMO, the rule of thumb for applying a new default is asking ourselves if
> the new default will cause any problem to the users. If yes, then
> don't touch the old default and keep it the way it was.

I don't agree.

> If we are not going to get any improvement but just for the 10% of our
> user-base, then we are failing the 90% of the rest.

The improvement long term *could* be valuable enough to justify the
pain. The correct way is usually not the easy way.

One of the big reasons I love Debian is because it is not afraid to
choose the hard path[1] when the long term benefits are worth it.

[1] starting with it's commitment to free software and continuing with
Firefox renaming, removal of non-free firmware from the kernel,
multiarch, and many more.

Kind regards,
Andrei
--
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
 
Old 03-28-2012, 03:12 PM
Camalen
 
Default how to increase space for tmpfs /tmp

On Wed, 28 Mar 2012 15:50:50 +0300, Andrei POPESCU wrote:

> On Ma, 27 mar 12, 14:58:52, Camalen wrote:
>>
>> IMO, the rule of thumb for applying a new default is asking ourselves
>> if the new default will cause any problem to the users. If yes, then
>> don't touch the old default and keep it the way it was.
>
> I don't agree.

For any specific reason or just "don't agree" for the sake of not
agreeing? I'll be glad to hear your arguments on this :-)

>> If we are not going to get any improvement but just for the 10% of our
>> user-base, then we are failing the 90% of the rest.
>
> The improvement long term *could* be valuable enough to justify the
> pain. The correct way is usually not the easy way.

And what (or who) decides what is "correct"?

I've just seen another thread at this mailing list where "another" user
has been hit by this "correct" default. I don't mean that having "/tmp"
mounted as "tmpfs" is not correct but the default is clearly not suited
to many of the users as you can see.

> One of the big reasons I love Debian is because it is not afraid to
> choose the hard path[1] when the long term benefits are worth it.

(...)

Although that's your personal opinion as you can easily understand it has
nothing to do with the issue we are currently debating. Every user can/do
love Debian for their own/different reasons but none of our personal
reasons can be used as arguments to make changes in the defaul settings,
unless there's a strong technical reason that proves they're the right
thing to do, which I still don't see for this specific issue.

Greetings,

--
Camalen


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: jkv9oj$hqr$8@dough.gmane.org">http://lists.debian.org/jkv9oj$hqr$8@dough.gmane.org
 
Old 03-28-2012, 03:23 PM
Tom H
 
Default how to increase space for tmpfs /tmp

On Wed, Mar 28, 2012 at 8:50 AM, Andrei POPESCU
<andreimpopescu@gmail.com> wrote:
> On Ma, 27 mar 12, 14:58:52, Camalen wrote:
>>
>> IMO, the rule of thumb for applying a new default is asking ourselves if
>> the new default will cause any problem to the users. If yes, then
>> don't touch the old default and keep it the way it was.
>
> I don't agree.
>
>> If we are not going to get any improvement but just for the 10% of our
>> user-base, then we are failing the 90% of the rest.
>
> The improvement long term *could* be valuable enough to justify the
> pain. The correct way is usually not the easy way.
>
> One of the big reasons I love Debian is because it is not afraid to
> choose the hard path[1] when the long term benefits are worth it.
>
> [1] starting with it's commitment to free software and continuing with
> Firefox renaming, removal of non-free firmware from the kernel,
> multiarch, and many more.

There's also the problem that the more people are involved in a
decision the less likely that it'll be taken quickly or even be taken
at all; witness the endless upstart/systemd threads on -devel.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAOdo=SwD+5715uf-Ztoo-jLnv-9ya041SykDaNSS8MDD932_2Q@mail.gmail.com">http://lists.debian.org/CAOdo=SwD+5715uf-Ztoo-jLnv-9ya041SykDaNSS8MDD932_2Q@mail.gmail.com
 
Old 03-28-2012, 04:26 PM
Andrei POPESCU
 
Default how to increase space for tmpfs /tmp

On Mi, 28 mar 12, 15:12:19, Camalen wrote:
> On Wed, 28 Mar 2012 15:50:50 +0300, Andrei POPESCU wrote:
>
> > On Ma, 27 mar 12, 14:58:52, Camalen wrote:
> >>
> >> IMO, the rule of thumb for applying a new default is asking ourselves
> >> if the new default will cause any problem to the users. If yes, then
> >> don't touch the old default and keep it the way it was.
> >
> > I don't agree.
>
> For any specific reason or just "don't agree" for the sake of not
> agreeing? I'll be glad to hear your arguments on this :-)

I thought I did below but the short version would be
"You can't make an omelette without breaking eggs"

> >> If we are not going to get any improvement but just for the 10% of our
> >> user-base, then we are failing the 90% of the rest.
> >
> > The improvement long term *could* be valuable enough to justify the
> > pain. The correct way is usually not the easy way.
>
> And what (or who) decides what is "correct"?

I think there is no correct answer that would apply anywhere[1]. It just
happen that I agree with (most) of the choices taken by Debian and I say
this by having followed all major discussions on -devel, -project and a
few other mailing lists for several years now.

[1] except 42, of course

> I've just seen another thread at this mailing list where "another" user
> has been hit by this "correct" default. I don't mean that having "/tmp"
> mounted as "tmpfs" is not correct but the default is clearly not suited
> to many of the users as you can see.

As far as I can tell /tmp as tmpfs is in testing since a few months and
in unstable even longer. In my very humble opinion two threads in this
period is hardly enough to call it "not suited to many of the users".

> > One of the big reasons I love Debian is because it is not afraid to
> > choose the hard path[1] when the long term benefits are worth it.
>
> (...)
>
> Although that's your personal opinion as you can easily understand it has
> nothing to do with the issue we are currently debating. Every user can/do
> love Debian for their own/different reasons but none of our personal
> reasons can be used as arguments to make changes in the defaul settings,

I wasn't trying to use personal reasons as arguments, I was just trying
to suggest that popularity or ease of implementation (or whatever) of a
decision does not necessarily imply correctness and Debian has had the
courage to make unpopular decisions or choose the harder to implement
solution when it thought it was necessary.

I just happen to respect this in general, regardless if the decision
proves to be "good" or "wrong".

> unless there's a strong technical reason that proves they're the right
> thing to do, which I still don't see for this specific issue.

Well, isn't this your personal opinion (that there is no strong
technical reason)?

Kind regards,
Andrei
--
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
 
Old 03-28-2012, 05:02 PM
Camalen
 
Default how to increase space for tmpfs /tmp

On Wed, 28 Mar 2012 19:26:54 +0300, Andrei POPESCU wrote:

> On Mi, 28 mar 12, 15:12:19, Camalen wrote:
>> On Wed, 28 Mar 2012 15:50:50 +0300, Andrei POPESCU wrote:
>>
>> > On Ma, 27 mar 12, 14:58:52, Camalen wrote:
>> >>
>> >> IMO, the rule of thumb for applying a new default is asking
>> >> ourselves if the new default will cause any problem to the users. If
>> >> yes, then don't touch the old default and keep it the way it was.
>> >
>> > I don't agree.
>>
>> For any specific reason or just "don't agree" for the sake of not
>> agreeing? I'll be glad to hear your arguments on this :-)
>
> I thought I did below

In this thread?

> but the short version would be "You can't make an omelette without
> breaking eggs"

Which explains little about your arguments (that's a general stanza) >:-)

>> >> If we are not going to get any improvement but just for the 10% of
>> >> our user-base, then we are failing the 90% of the rest.
>> >
>> > The improvement long term *could* be valuable enough to justify the
>> > pain. The correct way is usually not the easy way.
>>
>> And what (or who) decides what is "correct"?
>
> I think there is no correct answer that would apply anywhere[1]. It just
> happen that I agree with (most) of the choices taken by Debian and I say
> this by having followed all major discussions on -devel, -project and a
> few other mailing lists for several years now.

Debian is a big project and as such it has decided in many fields for the
defaults but again, that's not what we are talking here, this is about a
specific default which is now hitting some users.

> [1] except 42, of course

Sorry, I'm afraid I don't get that :-)

>> I've just seen another thread at this mailing list where "another" user
>> has been hit by this "correct" default. I don't mean that having "/tmp"
>> mounted as "tmpfs" is not correct but the default is clearly not suited
>> to many of the users as you can see.
>
> As far as I can tell /tmp as tmpfs is in testing since a few months and
> in unstable even longer. In my very humble opinion two threads in this
> period is hardly enough to call it "not suited to many of the users".

AFAIK, the discussion was started time ago at some of the "-devel"
mailing lists... and then it reached this general mailing list as soon as
wheezy users started having problems (me included). Although I'm using
wheezy I'm not usually following each "-devel" list, that will be too
much time for me, so I "discovered" the "out of space" problem when I was
uncompressing a "tar.gz" file. As I never enountered this message before,
I started a thread asking for feedback and found other users in the same
boat.

I can't count the exact number of users being hit by this but I'm sure
I'm not alone. To get quasi-accurate numbers a user targeted questionnary
could help to discover the maths behind this :-)

>> > One of the big reasons I love Debian is because it is not afraid to
>> > choose the hard path[1] when the long term benefits are worth it.
>>
>> (...)
>>
>> Although that's your personal opinion as you can easily understand it
>> has nothing to do with the issue we are currently debating. Every user
>> can/do love Debian for their own/different reasons but none of our
>> personal reasons can be used as arguments to make changes in the defaul
>> settings,
>
> I wasn't trying to use personal reasons as arguments, I was just trying
> to suggest that popularity or ease of implementation (or whatever) of a
> decision does not necessarily imply correctness and Debian has had the
> courage to make unpopular decisions or choose the harder to implement
> solution when it thought it was necessary.

Since when getting an "out of space" error message printed at your screen
and a faulty operation is something that can be considered "by popular
decision"? Of course not, so the own nature of the error is not something
I'd put inside a "feature" but more close to a "bug".

> I just happen to respect this in general, regardless if the decision
> proves to be "good" or "wrong".

Well, good decisions can enpower Debian (or any other piece of software
because this is not Debian specific, I'm afraid more distributions will
have to decide for this also...) while bad decisions can decrease its
users-base (which means they can consider another distributions).

>> unless there's a strong technical reason that proves they're the right
>> thing to do, which I still don't see for this specific issue.
>
> Well, isn't this your personal opinion (that there is no strong
> technical reason)?

My strong technical reason is all but personal: I failed to uncompress a
simple tar.gz file by this "correct" default, I never had experienced
this problem before. Nothing personal at all ;-)

Greetings,

--
Camalen


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: jkvg6v$hqr$14@dough.gmane.org">http://lists.debian.org/jkvg6v$hqr$14@dough.gmane.org
 
Old 03-28-2012, 05:32 PM
Roger Leigh
 
Default how to increase space for tmpfs /tmp

On Tue, Mar 27, 2012 at 02:58:52PM +0000, Camalen wrote:
> On Tue, 27 Mar 2012 14:13:23 +0100, Roger Leigh wrote:
> > As the person who created these defaults, just a few points for everyone
> > in this thread to consider:
>
> > A common (and very persuasive) argument for not mounting a tmpfs on /tmp
> > and instead using the root filesystem is that by default we install with
> > a single large root filesystem, and /tmp gets to use all the free space
> > there. This is certainly true, and is a major reason why we should
> > consider doing this.
>
> I also share that feeling.
>
> > However, the following points also need to be considered:
> >
> > - having /tmp on / means that / needs to be writable by default
> > - having "limitless" space on /tmp means it can be abused by
> > both users and applications. It can lead to breakage on systems with
> > a limited /tmp if applications make the (incorrect) assumption that
> > they can store whatever they like there. It's more sensible to
> > provide a minimum guarantee.
> > - /var/tmp exists, and should be used in many of the cases where
> > /tmp is being filled.
> >
> > It's hard to get a clear picture of what generally useful defaults
> > should be when you only get feedback from a handful of users.
>
> IMO, the rule of thumb for applying a new default is asking ourselves if
> the new default will cause any problem to the users. If yes, then don't
> touch the old default and keep it the way it was. If we are not going to
> get any improvement but just for the 10% of our user-base, then we are
> failing the 90% of the rest.

I can understand that running out of space is annoying and
frustrating. That's not the intent of the changes by any means.

Defaulting to putting /tmp on the rootfs solves this /particular/
problem simply. Assuming that your rootfs has sufficient amounts
of free space. That's by no means a given. Some root filesystems
are small. Others are full. Some are NFS mounted and have very
poor performance for temporary files. The point is that there are
no guarantees. On some systems, /tmp on the rootfs will be far
worse than on tmpfs.

However, while this would solve the immediate problem, it does
create other less immediate but still important ones. Application
written with the assumption that they can create huge temporary files
will work well on these "fixed" systems, but will be broken by
default on smaller systems. The issues being reported are by and
large a symptom of that. In most of these cases, the best long-term
outcome would be for those applications to be fixed. Not to do so
would cause more long-term pain as a result of an easy short-term
fix.

It's for reasons such as this that I think use of /tmp should
come with certain requirements. Size is one issue. Lifetime is
another. The borderline between what is "temporary" and what is
just user data is not always clear. I've used Solaris systems in
the past which had a total /tmp size of just a few tens of
megabytes, and an enforced lifetime of just 60 minutes. That was
annoying, but it ensured that it was only used for *genuinely*
temporary data of limited size. Obviously that's far too extreme,
but there are extremes in the other direction, and I think quite a
few applications are abusing /tmp badly.

Applications should not be selfish, and should not blindly fill it.
Take the streaming media example from earlier today. Is it
appropriate to dump potentially limitless streams of data to /tmp?
/Obviously/, it's going to be filled to capacity at some point; any
application not coping with this /inevitability/ is broken.
If it's being streamed, isn't buffering sufficient? Otherwise, it
might as well be termed "downloading". And in the example of /tmp
being filled by big downloads, is /tmp the appropriate place for
that, either? I would personally say no. That's not its purpose.

Once I have internet at home and I can work on sysvinit again (I
just moved house and started a new job), I will certainly be looking
at this more closely. Initially this will be looking at improving
the tmpfs defaults, but we can certainly look at not making it the
default.

Note that sysvinit has both a git repo and a mailing list. Bug
reports (there are several on this issue) can be commented on, and
patches provided where appropriate and/or possible.


Regards,
Roger

--
.'`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120328173225.GF30121@codelibre.net">http://lists.debian.org/20120328173225.GF30121@codelibre.net
 

Thread Tools




All times are GMT. The time now is 09:40 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org