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-28-2012, 06:12 PM
Brian
 
Default how to increase space for tmpfs /tmp

On Wed 28 Mar 2012 at 15:12:19 +0000, Camaleón wrote:

> On Wed, 28 Mar 2012 15:50:50 +0300, Andrei POPESCU wrote:
>
> > 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"?

It's my package so I do. Hopefully, I make the same sensible decisions
Roger Leigh makes.

> 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.

For years I've gone with the Debian tmpfs defaults. Me and thousands of
others. We don't speak up so often as the ones who have problems. The
machine without swap space is a good point; one of mine is configured
like that.

But defaults are defaults. Files in /etc/default can be altered. Do I
really want portmap to listen on all interfaces? Do I want CUPS to load
a driver for a parallel port printer when I do not have one. No? Then I
change the situation. But if I do not it doesn't lead to disaster.

> > 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.

Andrei's 'hard path' is one which involves the primary concern being a
focus on technical excellence. It's pleasing to see you agree with this.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120328181227.GP16316@desktop">http://lists.debian.org/20120328181227.GP16316@desktop
 
Old 03-28-2012, 06:27 PM
Dom
 
Default how to increase space for tmpfs /tmp

On 28/03/12 18:32, Roger Leigh wrote:

On Tue, Mar 27, 2012 at 02:58:52PM +0000, Camaleón 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.


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.


Thank you for that. I do appreciate how much work goes into this sort of
thing.


This change has caused me a number of (admittedly not too serious)
problems. I don't run the latest hardware. I can't afford to. I chose
Debian nearly 10 years ago because it was the only distro that I could
find that I could get to install on what I had at the time.


Some of my PCs are very small and under-powered. I am somewhat proud of
the fact that I manage to install and run Wheezy (cli only) on a PIMMX
with 32MB of RAM and 2GB disk. I mostly use that machine as an ssh
terminal to manage my other systems. Obviously 32MB of physical RAM is
not enough to manage much in the way of tmpfs, unlike those of us who
are able to run multiples of GB or RAM.


May I suggest that, if you're looking into the installer, that you
consider setting a low memory limit on the use of tmpfs for /tmp.
Something like: If system has < 256MB physical, set TMPFS=no ? This
would need to apply to updates too.


I think the main issue I had was that /tmp was moved to ramfs without
anycomment (that I can recall, I may be wrong) shown by apt-listchanges.
I have been told that it was discussed in the developers list, but I'm
not a Debian dev. I'm a user.


--
Dom


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Archive: 4F735828.2020202@rpdom.net">http://lists.debian.org/4F735828.2020202@rpdom.net
 
Old 03-28-2012, 06:55 PM
Andrei POPESCU
 
Default how to increase space for tmpfs /tmp

On Mi, 28 mar 12, 17:02:23, Camaleón wrote:
> On Wed, 28 Mar 2012 19:26:54 +0300, Andrei POPESCU wrote:
>
> > On Mi, 28 mar 12, 15:12:19, Camaleón wrote:
> >> On Wed, 28 Mar 2012 15:50:50 +0300, Andrei POPESCU wrote:
> >>
> >> > On Ma, 27 mar 12, 14:58:52, Camaleón 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) >:-)

Well, so is yours, unless we are talking past each other. I was
specifically addressing only that paragraph, out of context.

It seems to me you are expecting specific arguments about the /tmp on
tmpfs issue. As far as I recall you did read through the debian-devel
discussion(s), what point is there for me to repeat it here (even if my
memory is faulty and you did not read it)?

> > [1] except 42, of course
>
> Sorry, I'm afraid I don't get that :-)

http://en.wikipedia.org/wiki/42_(Hitchhiker%27s_Guide_to_the_Galaxy)#Answer_to_ the_Ultimate_Question_of_Life.2C_the_Universe.2C_a nd_Everything_.2842.29

> 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".
...
> 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 ;-)

You expected to be able to uncompress an archive of unspecified size to
/tmp on a testing system.

1. you may have had similar issues uncompressing that on any other
filesystem (small partition, quota, etc.)
2. changes in behavior are to be expected on testing, otherwise one
should stick with stable and carefully read the release notes before
upgrading
3. there is still time to adjust the defaults before the release and the
responsible maintainer even asked for feedback in this thread.

How else would you suggest this to be handled?

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

On Mi, 28 mar 12, 19:27:52, Dom wrote:
>
> I think the main issue I had was that /tmp was moved to ramfs
> without anycomment (that I can recall, I may be wrong) shown by
> apt-listchanges. I have been told that it was discussed in the
> developers list, but I'm not a Debian dev. I'm a user.

+1 on the NEWS.Debian entry.

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

On Wed, 28 Mar 2012 18:32:25 +0100, Roger Leigh wrote:

> On Tue, Mar 27, 2012 at 02:58:52PM +0000, Camaleón wrote:

(...)

>> > 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.

(...)

I already shared my thoughts on why I think this is a *bad* default as it
is now, so I'm not going to keep telling the same all over again. I only
hope at the time Wheezy is released:

- The installer (at least in the "expert" flavour) allows the user to
enable/disable this and/or set a default sane value for the "tmpfs" size,
being automatically or manually set.

- The upgrade routine asks the user for this change so this is not being
applied silently but consciously.

- This new setting is documented in the Installation Guide so people can
be at least aware of this option, how can be configured, how can be
turned off, and some user-case examples so they can make their own
estimatations based on their system configuration and needs.

- A simple tweak for modifying this option once the system has been
installed (this is already done) and how it could be applied on the fly
without rebooting a running system.

Greetings,

--
Camaleón


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: jkvqfe$hqr$19@dough.gmane.org">http://lists.debian.org/jkvqfe$hqr$19@dough.gmane.org
 
Old 03-28-2012, 08:09 PM
Camaleón
 
Default how to increase space for tmpfs /tmp

On Wed, 28 Mar 2012 19:12:27 +0100, Brian wrote:

> On Wed 28 Mar 2012 at 15:12:19 +0000, Camaleón wrote:
>
>> On Wed, 28 Mar 2012 15:50:50 +0300, Andrei POPESCU wrote:
>>
>> > 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"?
>
> It's my package so I do. Hopefully, I make the same sensible decisions
> Roger Leigh makes.

Glad the current default it matches your needings. Hope you understand
that's not the case for others.

>> 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.
>
> For years I've gone with the Debian tmpfs defaults. Me and thousands of
> others. We don't speak up so often as the ones who have problems. The
> machine without swap space is a good point; one of mine is configured
> like that.

I neither tell much about all of the things that work, that's a bit
obvious and I bet 95% of this mailing lists posts neither do. We write
here because something does not work as expected or because we don't know
how to setup something and that's what have happened in this case.

> But defaults are defaults. Files in /etc/default can be altered. Do I
> really want portmap to listen on all interfaces? Do I want CUPS to load
> a driver for a parallel port printer when I do not have one. No? Then I
> change the situation. But if I do not it doesn't lead to disaster.

(...)

You have said the "magic" word: disaster.

Maybe you (or me) don't think it is a disaster to see an application
hanging because it runs "out of space" but there can be users who don't
have the capacity of thinking the same becasue they lack of the expertise
required to understand what's going on with their system. For they it can
be a "disaster".

Greetings,

--
Camaleón


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: jkvr6a$hqr$20@dough.gmane.org">http://lists.debian.org/jkvr6a$hqr$20@dough.gmane.org
 
Old 03-28-2012, 08:47 PM
Camaleón
 
Default how to increase space for tmpfs /tmp

On Wed, 28 Mar 2012 21:55:01 +0300, Andrei POPESCU wrote:

> On Mi, 28 mar 12, 17:02:23, Camaleón wrote:

(...)

>> > 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)
>> >:-)
>
> Well, so is yours, unless we are talking past each other. I was
> specifically addressing only that paragraph, out of context.

I didn't know you were interested in my arguments... they can be read
here:

http://lists.debian.org/debian-user/2011/11/msg02155.html
http://lists.debian.org/debian-user/2011/11/msg02207.html
http://lists.debian.org/debian-user/2012/03/msg00280.html

> It seems to me you are expecting specific arguments about the /tmp on
> tmpfs issue. As far as I recall you did read through the debian-devel
> discussion(s), what point is there for me to repeat it here (even if my
> memory is faulty and you did not read it)?

I read the thread it was mentioned when I first asked for feedback, which
was this:

http://lists.debian.org/debian-devel/2011/11/threads.html#00281

But to be sincere, I don't remember "all" of the contents of the posts
nor "who" posted there "what"... and now you tell, I can't see any post
belonging to you in that thread. Maybe you made your comments afterwards?

>> > [1] except 42, of course
>>
>> Sorry, I'm afraid I don't get that :-)
>
> http://en.wikipedia.org/wiki/42_(Hitchhiker%27s_Guide_to_the_Galaxy)#Answer_to_ the_Ultimate_Question_of_Life.2C_the_Universe.2C_a nd_Everything_.2842.29

Thanks, firt time I see. I didn't know about it...

>> 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".
> ...
>> 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 ;-)
>
> You expected to be able to uncompress an archive of unspecified size to
> /tmp on a testing system.

"Unspecified size"?

It was just the kernel source (75 MiB). Wow. How. Big. >:-)

> 1. you may have had similar issues uncompressing that on any other
> filesystem (small partition, quota, etc.)

I doubt it becasue I tend to put special care for that can't happen (my netbook
has a 250 GiB. hard disk with only 2 partitions: /swap (2 GiB) and "/" (the
remaining space). Since I returned "/tmp" to the root filesystem I've had no
more "hiccups".

> 2. changes in behavior are to be expected on testing, otherwise one
> should stick with stable and carefully read the release notes before
> upgrading

Yup and I fully agree with you in this. That's why in my first post
("[Feedback needed] Setting the right size for /tmp") I asked for
"feedback" and I wasn't complaining at all for this setting.

> 3. there is still time to adjust the defaults before the release and the
> responsible maintainer even asked for feedback in this thread.

Yes! And I already wrote some things that we should care about for this
is introduced in Wheezy "smoothly".

> How else would you suggest this to be handled?

Glad you ask. I already mentioned some points here:

http://lists.debian.org/debian-user/2012/03/msg01857.html

***
- The installer (at least in the "expert" flavour) allows the user to
enable/disable this and/or set a default sane value for the "tmpfs" size,
being automatically or manually set.

- The upgrade routine asks the user for this change so this is not being
applied silently but consciously.

- This new setting is documented in the Installation Guide so people can
be at least aware of this option, how can be configured, how can be
turned off, and some user-case examples so they can make their own
estimatations based on their system configuration and needs.

- A simple tweak for modifying this option once the system has been
installed (this is already done) and how it could be applied on the fly
without rebooting a running system.
***

Greetings,

--
Camaleón


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

On Mi, 28 mar 12, 20:47:45, Camaleón wrote:
> On Wed, 28 Mar 2012 21:55:01 +0300, Andrei POPESCU wrote:
>
> > On Mi, 28 mar 12, 17:02:23, Camaleón wrote:
>
> (...)
>
> >> > 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)
> >> >:-)
> >
> > Well, so is yours, unless we are talking past each other. I was
> > specifically addressing only that paragraph, out of context.
>
> I didn't know you were interested in my arguments... they can be read
> here:
>
> http://lists.debian.org/debian-user/2011/11/msg02155.html
> http://lists.debian.org/debian-user/2011/11/msg02207.html
> http://lists.debian.org/debian-user/2012/03/msg00280.html

We are still talking past each other on this one. Let me try again[1]: I
was only disagreeing with you on the rather general statement that
defaults should not change when they create problems for users. Nothing
more.

[1] but I won't be posting anymore on this, it's OT already

> > It seems to me you are expecting specific arguments about the /tmp on
> > tmpfs issue. As far as I recall you did read through the debian-devel
> > discussion(s), what point is there for me to repeat it here (even if my
> > memory is faulty and you did not read it)?
>
> I read the thread it was mentioned when I first asked for feedback, which
> was this:
>
> http://lists.debian.org/debian-devel/2011/11/threads.html#00281
>
> But to be sincere, I don't remember "all" of the contents of the posts
> nor "who" posted there "what"... and now you tell, I can't see any post
> belonging to you in that thread. Maybe you made your comments afterwards?

I most probably didn't contribute at all. What for? People more
knowledgeable than me and with more real life experience were already
debating the issue with interesting arguments for both "sides".

> > You expected to be able to uncompress an archive of unspecified size to
> > /tmp on a testing system.
>
> "Unspecified size"?

If you did mention a size I must have missed it, sorry for that.

> It was just the kernel source (75 MiB). Wow. How. Big. >:-)

Since this created problems for you I'm assuming either a small amount
of RAM (less than 512 MB?[2]) which points to a lower spec machine that
would need special care anyway, or that something else was already
hogging /tmp (which kinda' proves Roger's point).

[2] 20% of 512 MB is still aprox. 100MB. My laptop is up 2 days and I'am
running iceweasel, xxxterm, libreoffice, aptitude, mutt, pidgin, but
/tmp usage is still below 1MB (844 KB according to 'df -h').

> > 1. you may have had similar issues uncompressing that on any other
> > filesystem (small partition, quota, etc.)
>
> I doubt it becasue I tend to put special care for that can't happen (my netbook
> has a 250 GiB. hard disk with only 2 partitions: /swap (2 GiB) and "/" (the
> remaining space). Since I returned "/tmp" to the root filesystem I've had no
> more "hiccups".

You could have also considered uncompressing the tarball somewhere else,
like $HOME/tmp or $HOME/src, but it sure is a valid solution, especially
if you often use /tmp for such things and don't care for the potential
benefits of the tmpfs approach.

> Glad you ask. I already mentioned some points here:

Already saw that and I may comment on your suggestions there, because I
want to let this sub-thread die.

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

On Mi, 28 mar 12, 19:57:34, Camaleón wrote:
>
> - The upgrade routine asks the user for this change so this is not being
> applied silently but consciously.

IMVHO an entry in the release notes and NEWS.Debian would be necessary,
but sufficient.

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

On 20120329_011019, Andrei POPESCU wrote:
> On Mi, 28 mar 12, 20:47:45, Camaleón wrote:
> > On Wed, 28 Mar 2012 21:55:01 +0300, Andrei POPESCU wrote:
> >
> > > On Mi, 28 mar 12, 17:02:23, Camaleón wrote:
> >
> > (...)
> >
> > >> > 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)
> > >> >:-)
> > >
> > > Well, so is yours, unless we are talking past each other. I was
> > > specifically addressing only that paragraph, out of context.
> >
> > I didn't know you were interested in my arguments... they can be read
> > here:
> >
> > http://lists.debian.org/debian-user/2011/11/msg02155.html
> > http://lists.debian.org/debian-user/2011/11/msg02207.html
> > http://lists.debian.org/debian-user/2012/03/msg00280.html
>
> We are still talking past each other on this one. Let me try again[1]: I
> was only disagreeing with you on the rather general statement that
> defaults should not change when they create problems for users. Nothing
> more.
>
> [1] but I won't be posting anymore on this, it's OT already
>
> > > It seems to me you are expecting specific arguments about the /tmp on
> > > tmpfs issue. As far as I recall you did read through the debian-devel
> > > discussion(s), what point is there for me to repeat it here (even if my
> > > memory is faulty and you did not read it)?
> >
> > I read the thread it was mentioned when I first asked for feedback, which
> > was this:
> >
> > http://lists.debian.org/debian-devel/2011/11/threads.html#00281
> >
> > But to be sincere, I don't remember "all" of the contents of the posts
> > nor "who" posted there "what"... and now you tell, I can't see any post
> > belonging to you in that thread. Maybe you made your comments afterwards?
>
> I most probably didn't contribute at all. What for? People more
> knowledgeable than me and with more real life experience were already
> debating the issue with interesting arguments for both "sides".
>
> > > You expected to be able to uncompress an archive of unspecified size to
> > > /tmp on a testing system.
> >
> > "Unspecified size"?
>
> If you did mention a size I must have missed it, sorry for that.
>
> > It was just the kernel source (75 MiB). Wow. How. Big. >:-)
>
> Since this created problems for you I'm assuming either a small amount
> of RAM (less than 512 MB?[2]) which points to a lower spec machine that
> would need special care anyway, or that something else was already
> hogging /tmp (which kinda' proves Roger's point).
>
> [2] 20% of 512 MB is still aprox. 100MB. My laptop is up 2 days and I'am
> running iceweasel, xxxterm, libreoffice, aptitude, mutt, pidgin, but
> /tmp usage is still below 1MB (844 KB according to 'df -h').
>
> > > 1. you may have had similar issues uncompressing that on any other
> > > filesystem (small partition, quota, etc.)
> >
> > I doubt it becasue I tend to put special care for that can't happen (my netbook
> > has a 250 GiB. hard disk with only 2 partitions: /swap (2 GiB) and "/" (the
> > remaining space). Since I returned "/tmp" to the root filesystem I've had no
> > more "hiccups".
>
> You could have also considered uncompressing the tarball somewhere else,
> like $HOME/tmp or $HOME/src, but it sure is a valid solution, especially
^^^^^^^^^ ^^^^^^^^^

On my computer that is running wheezy neither of these suggestions work,
because, I think, these are not mount points supporting access to external
physical disk hardware. I tested this suggestion this morning. I don't
fully understand this, but I have been told that access to the original
/tmp file requires an entry in /etc/fstab. Think about it. Who is supplying
this extra hardware? Any specialized software that requires scratch files
because the work is too large to fit in ram is dead in the water with this
change, and changing the setting of RAMTMP does not fix the problem, or
any of the work-arounds that have been suggested so far. I think this is
a serious flaw in the current wheezy, a release critical flaw perhaps.

My particular problem is a project in which I regularly need to sort
files 2 to 3 GB in size on a computer with less than 1 GB of ram and
370 GB of rotating disk. But I am sure there are other problems
needing real, physical scratch space running very nicely on computers
old enough to have once run woody. And now they are to be broken by
something in wheezy software? Can this happen? Really?

I hope some work-around that actually survives testing is suggested soon.





--
Paul E Condon
pecondon@mesanetworks.net


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120328225803.GB6463@big.lan.gnu">http://lists.debian.org/20120328225803.GB6463@big.lan.gnu
 

Thread Tools




All times are GMT. The time now is 05:42 AM.

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