how to increase space for tmpfs /tmp

[shirish शिरीष]

Hi all,
I got this error, does anybody know how I can give more space to tmpfs ?

Downloaded, time 4575.50sec, speed 29kB/sec,
texlive-latex-extra-doc_2009-10_2011.20120322-1_all.debdelta
Error: applying of delta for texlive-latex-extra-doc failed: :
Sorry, not enough disk space (581788kB) in directory /tmp for applying
delta (needs 668963kB) (retriable)


I tried this command :-

$sudo mount -o size=734003200 /tmp


This gave me this :-

$ df -hT
Filesystem Type Size
Used Avail Use% Mounted on
rootfs rootfs 84G
16G 65G 20% /
udev devtmpfs 996M
0 996M 0% /dev
tmpfs tmpfs 201M
744K 200M 1% /run
/dev/disk/by-uuid/somuuidno. ext4 84G 16G 65G 20% /
tmpfs tmpfs 5.0M
0 5.0M 0% /run/lock
tmpfs tmpfs 700M
0 700M 0% /tmp
tmpfs tmpfs 401M
84K 401M 1% /run/shm
/dev/sda10 ext4 84G
77G 3.2G 97% /home
tmpfs tmpfs 700M
0 700M 0% /tmp
tmpfs tmpfs 700M
0 700M 0% /tmp


The only change I have done here is just masked/not shared the uuid
number of the disk. Even after doing this change I got the same error
as before. What's more now I can see two entries for tmpfs as well but
still a no go, any ideas anybody ?

--
          Regards,
          Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
065C 6D79 A68C E7EA 52B3  8D70 950D 53FB 729A 8B17


--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/CADdDZReg_zKg7vy5XJxy3TV...@mail.gmail.com

[shirish शिरीष]

please CC me if anybody does answer this, sorry for top-posting.

2012/3/24 shirish शिरीष <shiri...@gmail.com>:

[Joey Hess]

shirish शिरीष wrote:
> I got this error, does anybody know how I can give more space to tmpfs ?
>
> Downloaded, time 4575.50sec, speed 29kB/sec,
> texlive-latex-extra-doc_2009-10_2011.20120322-1_all.debdelta
> Error: applying of delta for texlive-latex-extra-doc failed: :
> Sorry, not enough disk space (581788kB) in directory /tmp for applying
> delta (needs 668963kB) (retriable)

Edit /etc/default/rcS, set RAMTMP=no, reboot. Or, set TMPDIR to point to
something like $HOME/tmp

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.

--
see shy jo

[Javier Vasquez]

2012/3/24 Joey Hess <jo...@debian.org>:

Why?

You can always configure as you wish. Take a look at:

/etc/default/tmpfs

There you can configure TMPFS_SIZE and TMP_SIZE, which are the ones
asked for. And if you definitely don't want to use tmpfs, then you
can RAMTMP=yes as you suggested.

I think this is a matter of configuration, and we all might want
different settings for our purposes, :-)

Thanks,

--
Javier.

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

Archive: http://lists.debian.org/CALUrRGfNyLUZNqLjbnb8v8K2...@mail.gmail.com

[Camaleón]

On Sat, 24 Mar 2012 11:00:49 -0600, Javier Vasquez wrote:

> 2012/3/24 Joey Hess <jo...@debian.org>:
>> shirish शिरीष wrote:
>>> I got this error, does anybody know how I can give more space to tmpfs
>>> ?
>>>
>>> Downloaded, time 4575.50sec, speed 29kB/sec,
>>> texlive-latex-extra-doc_2009-10_2011.20120322-1_all.debdelta
>>>  Error: applying of delta for texlive-latex-extra-doc failed:  :
>>> Sorry, not enough disk space (581788kB) in directory /tmp for applying
>>> delta (needs 668963kB) (retriable)
>>
>> Edit /etc/default/rcS, set RAMTMP=no, reboot. Or, set TMPDIR to point
>> to something like $HOME/tmp
>>
>> 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?

> You can always configure as you wish. Take a look at:
>
> /etc/default/tmpfs
>
> There you can configure TMPFS_SIZE and TMP_SIZE, which are the ones
> asked for. And if you definitely don't want to use tmpfs, then you can
> RAMTMP=yes as you suggested.
>
> I think this is a matter of configuration, and we all might want
> different settings for our purposes, :-)

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.

Greetings,

--
Camaleón

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

Archive: http://lists.debian.org/jkkv6o$7bd$1...@dough.gmane.org

[Javier Vasquez]

On Sat, Mar 24, 2012 at 11:10 AM, Camaleón <noel...@gmail.com> wrote:
> On Sat, 24 Mar 2012 11:00:49 -0600, Javier Vasquez wrote:
>
>> 2012/3/24 Joey Hess <jo...@debian.org>:
>>> shirish शिरीष wrote:
>>>> I got this error, does anybody know how I can give more space to tmpfs
>>>> ?
>>>>
>>>> Downloaded, time 4575.50sec, speed 29kB/sec,
>>>> texlive-latex-extra-doc_2009-10_2011.20120322-1_all.debdelta
>>>>  Error: applying of delta for texlive-latex-extra-doc failed:  :
>>>> Sorry, not enough disk space (581788kB) in directory /tmp for applying
>>>> delta (needs 668963kB) (retriable)
>>>
>>> Edit /etc/default/rcS, set RAMTMP=no, reboot. Or, set TMPDIR to point
>>> to something like $HOME/tmp
>>>
>>> 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.

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.

Moreover, you can shut debian settings off, and use fstab if you'd
like, as follows:

tmpfs /tmp tmpfs nodev,nosuid,relatime,size=2G 0 0

Current setting is not the most fortunate for some (neither for me),
but users still have the ability to configure as they wish, which BTW
can serve way better than any default now, or even in the future.

>> You can always configure as you wish.  Take a look at:
>>
>> /etc/default/tmpfs
>>
>> There you can configure TMPFS_SIZE and TMP_SIZE, which are the ones
>> asked for.  And if you definitely don't want to use tmpfs, then you can
>> RAMTMP=yes as you suggested.
>>
>> I think this is a matter of configuration, and we all might want
>> different settings for our purposes, :-)
>
> 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...

I won't probably talk more about this, :-). I believe the question
has been addressed (with options, and suggestions for complains), and
if not, maybe the original poster can ask further, :-)

>
> Greetings,
>
> --
> Camaleón

Thanks,

--
Javier.

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

Archive: http://lists.debian.org/CALUrRGdKaMgbYhq4CyQ5mrJJ...@mail.gmail.com

[shirish शिरीष]

at bottom :-

2012/3/24 Javier Vasquez <j.e.va...@gmail.com>:

> 2012/3/24 Joey Hess <jo...@debian.org>:
>> shirish शिरीष wrote:
>>> I got this error, does anybody know how I can give more space to tmpfs ?
>>>
>>> Downloaded, time 4575.50sec, speed 29kB/sec,
>>> texlive-latex-extra-doc_2009-10_2011.20120322-1_all.debdelta
>>>  Error: applying of delta for texlive-latex-extra-doc failed:  :
>>> Sorry, not enough disk space (581788kB) in directory /tmp for applying
>>> delta (needs 668963kB) (retriable)
>>
>> Edit /etc/default/rcS, set RAMTMP=no, reboot. Or, set TMPDIR to point to
>> something like $HOME/tmp
>>
>> 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.
>>
>> --
>> see shy jo
>
>
> Why?
>
> You can always configure as you wish.  Take a look at:
>
> /etc/default/tmpfs
>
> There you can configure TMPFS_SIZE and TMP_SIZE, which are the ones
> asked for.  And if you definitely don't want to use tmpfs, then you
> can RAMTMP=yes as you suggested.
>
> I think this is a matter of configuration, and we all might want
> different settings for our purposes, :-)

Hi all,
Thank you Joey Hess and Javier Vasquez for answering my query but I
wish some examples would have been given alongwith it.

How do I write values of TMPFS_SIZE and TMP_SIZE

This is what it looks like atm :-

# 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%

# TMP_SIZE: maximum size of /tmp
#
# No default size.
TMP_SIZE=

Now my questions are :-

a. From where would TMPFS_Size be used ? Would it take from the space
allocated from / (which has enough empty space) or does it take from
/home. Note that I have two partitions / , /home and of course swap is
also good around 4 GB.

$ free -h
total used free shared buffers cached
Mem: 2.0G 1.8G 134M 0B 72M 840M
-/+ buffers/cache: 954M 1.0G
Swap: 4.6G 212M 4.4G

b. The second question is how do I phrase the two ?
tmpfs is given as 20% . 20% is default for what and from where ?

c. What do I write at TMP_SIZE= if I want to say 900 MiB or 1 GiB .


> Thanks,
>
> --
> Javier.

Looking forward for help and advice.

--
          Regards,
          Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
065C 6D79 A68C E7EA 52B3  8D70 950D 53FB 729A 8B17

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

Archive: http://lists.debian.org/CADdDZRkboP8_xS6RNctE9MXF...@mail.gmail.com

[Henrique de Moraes Holschuh]

On Sat, 24 Mar 2012, Joey Hess wrote:
> shirish शिरीष wrote:
> > I got this error, does anybody know how I can give more space to tmpfs ?
> >
> > Downloaded, time 4575.50sec, speed 29kB/sec,
> > texlive-latex-extra-doc_2009-10_2011.20120322-1_all.debdelta
> > Error: applying of delta for texlive-latex-extra-doc failed: :
> > Sorry, not enough disk space (581788kB) in directory /tmp for applying
> > delta (needs 668963kB) (retriable)
>
> Edit /etc/default/rcS, set RAMTMP=no, reboot. Or, set TMPDIR to point to
> something like $HOME/tmp

You don't need to reboot because of the size change.

"mount -o remount,size=<desired size> /tmp" works, at least for
increasing size. One of the good things of a tmpfs is that you can
resize it dynamically.

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

Hmm, yes, it can certaily be raised by popular demand. But what would
probably help more is a set of profiles of /tmp sizes based on the
amount of system ram to provide the initial default size.

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh

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

Archive: http://lists.debian.org/2012032421...@khazad-dum.debian.net

[Javier Vasquez]

2012/3/24 shirish शिरीष <shiri...@gmail.com>:
>

> ...

>
> How do I write values of TMPFS_SIZE and TMP_SIZE
>
> This is what it looks like atm :-
>
> # 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. Though if you feel like it's
too agressive, you can set something different.

When using %, the percentage is with respect to RAM.

I would recommend you also looking at swappiness setting
(vm.swappiness), :-) When you use absolute sizes, those sizes can go
beyond RAM, as long as they fit into RAM+Swap, that's why I mentioned
swappiness, though a bit off topic.

>
> # TMP_SIZE: maximum size of /tmp
> #
> # No default size.
> TMP_SIZE=

This is also as per your needs. You might want to use all of the RAM
reducing if you'd like other tmpfs areas such as /run and /run/lock,
plus some margin. Or you could use some other heuristic, more or less
conservative.

I would use half the RAM if I want to be conservative, :-). And if
agressive, then whole RAM, hoping to swap when in need (I usually have
in swap same amount of RAM).

You can google around this, and you can find the following information
useful (though not debian):

https://wiki.archlinux.org/index.php/Fstab#tmpfs

Notice there's no restriction to go beyond RAM size again, since you
can always swap.

Finally, you do not need to touch /etc/default/tmpfs if you don't want
to. Just set the entry in your /etc/fstab as I mentioned previously,
kind of:

tmpfs /tmp tmpfs nodev,nosuid,relatime,size=2G 0 0

Just make sure the size you use doesn't exceed RAM+Swap...

>
> Now my questions are :-
>
> a. From where would TMPFS_Size be used ? Would it take from the space
> allocated from / (which has enough empty space) or does it take from
> /home. Note that I have two partitions / , /home and of course swap is
> also good around 4 GB.
>
> $ free -h
>             total       used       free     shared    buffers     cached
> Mem:          2.0G       1.8G       134M         0B        72M       840M
> -/+ buffers/cache:       954M       1.0G
> Swap:         4.6G       212M       4.4G
>

There's no magic, just experimentation. I think I provided enough
hints, but from your setting: 2g RAM + 4.6g Swap, I would go with the
2g, or even 3g... It doesn't mean you'll be using all that amount of
tmp area, it means you can load through vim a 2g or a 3g file if you'd
like, :-) Vim by default loads in /tmp...

> b. The second question is how do I phrase the two ?
> tmpfs is given as 20% . 20% is default for what and from where ?

Didn't understand. TMPFS_SIZE is kind of the default if no other
setting is found. The rest are specific.

>
> c. What do I write at TMP_SIZE= if I want to say 900 MiB or 1 GiB .

Do the math, :-) I believe you can use a suffix also. But again, you
can always use fstab without touching debian stuff...

>
>
>> Thanks,
>>
>> --
>> Javier.

--
Javier.

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

Archive: http://lists.debian.org/CALUrRGdzOfDvLLUHOKGSbb1Qte0+96¢PQanni1r...@mail.gmail.com

[Henrique de Moraes Holschuh]

On Sun, 25 Mar 2012, shirish शिरीष wrote:
> How do I write values of TMPFS_SIZE and TMP_SIZE

AFAIK, it will accept whatever "mount" accepts for the "size=" parameter for
tmpfs filesystems. You can find that information on the mount(8) manpage.

> This is what it looks like atm :-
>
> # 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%

This means 20% of the system RAM.

> # TMP_SIZE: maximum size of /tmp
> #
> # No default size.
> TMP_SIZE=

Which means use whatever is in TMPFS_SIZE, I think.

> a. From where would TMPFS_Size be used ? Would it take from the space
> allocated from / (which has enough empty space) or does it take from
> /home. Note that I have two partitions / , /home and of course swap is
> also good around 4 GB.

It lives in virtual memory, so it is stored in system RAM. Data inside a
tmpfs can be swapped to disk. Unused space in a tmpfs is very cheap, but
AFAIK the tmpfs size _does_ increase the size of some page tables, so if you
really need to know exactly how many resources are taken by unused tmpfs
space, we'd need to ask in LKML for an expert opinion.

> b. The second question is how do I phrase the two ?
> tmpfs is given as 20% . 20% is default for what and from where ?

AFAIK, it's 20% of the available system RAM at kernel boot. I am not sure
it takes into account RAM explicitly set aside for hugepages, but you likely
don't have to worry about that.

> c. What do I write at TMP_SIZE= if I want to say 900 MiB or 1 GiB .

TMP_SIZE=1G
TMP_SIZE=900M

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh

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

Archive: http://lists.debian.org/2012032421...@khazad-dum.debian.net

[Stan Hoeppner]

On 3/24/2012 4:02 PM, Javier Vasquez wrote:
> 2012/3/24 shirish शिरीष <shiri...@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-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/4F6EB69...@hardwarefreak.com

[Camaleón]

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

> On Sat, Mar 24, 2012 at 11:10 AM, Camaleón <noel...@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 río 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,

--
Camaleón

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

Archive: http://lists.debian.org/jkmtar$q88$6...@dough.gmane.org

[Paul E Condon]

OK, Stan,

I'm convinced by your argument, but I'm not ready to switch to XFS and
ext2. My root partition is ext3 and contains plenty of space (~50GB)
for /tmp. Also, I have been being bothered by running out of space for
intermediate files during 'sort' of largish files. So, ... how do I
shut down tmpfs? On my plain vanilla wheezy tmpfs seems also to be
involved in something called rootfs which is in use. Do I have to
reboot to get rid of the tmpfs mount of /tmp? On this machine, I have
a 60GB partition that I have been using with the -T option in sort to
make it work again, but I can't make that partition BE mounted as /tmp
until I have umount-ed the tmpfs mount at /tmp. At least that is what
I think my problem is.

TIA
--
Paul E Condon
peco...@mesanetworks.net

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

Archive: http://lists.debian.org/20120325230...@big.lan.gnu

[Henrique de Moraes Holschuh]

On Sun, 25 Mar 2012, Paul E Condon wrote:
> > 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.

You are, of course, aware of the term "bit rot"?

ext2 is mostly unused nowadays, and it gets little attention and testing.
It depends heavily on the VFS layer pagecache, and other areas of the kernel
to work well. But THOSE areas are not staying put. So, ext2 *will* bit
rot.

> I'm convinced by your argument, but I'm not ready to switch to XFS and
> ext2. My root partition is ext3 and contains plenty of space (~50GB)

I advise you to not switch anything to ext2. XFS is fine, it is actively
developed, regression-tested, and heavily used everywhere. ext2 is not
(anymore).

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh

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

Archive: http://lists.debian.org/20120326012...@khazad-dum.debian.net

[Jochen Spieker]

Henrique de Moraes Holschuh:

> On Sun, 25 Mar 2012, Paul E Condon wrote:
>>> 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.
>
> You are, of course, aware of the term "bit rot"?
>
> ext2 is mostly unused nowadays, and it gets little attention and testing.
> It depends heavily on the VFS layer pagecache, and other areas of the kernel
> to work well. But THOSE areas are not staying put. So, ext2 *will* bit
> rot.

I was under the impression that at least ext3 (and maybe even ext4)
shares a lot of code with ext2. Is this wrong?

J.
--
I am no longer prepared to give you the benefit of the doubt.
[Agree] [Disagree]
<http://www.slowlydownward.com/NODATA/data_enter2.html>

[Henrique de Moraes Holschuh]

On Mon, 26 Mar 2012, Jochen Spieker wrote:
> Henrique de Moraes Holschuh:
> > On Sun, 25 Mar 2012, Paul E Condon wrote:
> >>> 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.
> >
> > You are, of course, aware of the term "bit rot"?
> >
> > ext2 is mostly unused nowadays, and it gets little attention and testing.
> > It depends heavily on the VFS layer pagecache, and other areas of the kernel
> > to work well. But THOSE areas are not staying put. So, ext2 *will* bit
> > rot.
>
> I was under the impression that at least ext3 (and maybe even ext4)
> shares a lot of code with ext2. Is this wrong?

I am not sure, but it could actually make the bit rot more likely.

People already try hard to not break anything when changing stuff in the
kernel, and update code using old interfaces (otherwise ext2 wouldn't even
build) but corner cases and subtle interactions can get past undetected, and
that's where bit rot starts to set in.

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh


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

Archive: http://lists.debian.org/20120326104...@khazad-dum.debian.net

[Paul E Condon]

On 20120326_074231, Henrique de Moraes Holschuh wrote:
> On Mon, 26 Mar 2012, Jochen Spieker wrote:
> > Henrique de Moraes Holschuh:
> > > On Sun, 25 Mar 2012, Paul E Condon wrote:
> > >>> 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.
> > >
> > > You are, of course, aware of the term "bit rot"?
> > >
> > > ext2 is mostly unused nowadays, and it gets little attention and testing.
> > > It depends heavily on the VFS layer pagecache, and other areas of the kernel
> > > to work well. But THOSE areas are not staying put. So, ext2 *will* bit
> > > rot.
> >
> > I was under the impression that at least ext3 (and maybe even ext4)
> > shares a lot of code with ext2. Is this wrong?
>
> I am not sure, but it could actually make the bit rot more likely.
>
> People already try hard to not break anything when changing stuff in the
> kernel, and update code using old interfaces (otherwise ext2 wouldn't even
> build) but corner cases and subtle interactions can get past undetected, and
> that's where bit rot starts to set in.
>

Please address my OT question in my OT branch of this
"increase-ramfs-howto" discussion.

How do I turn off ramfs on a wheezy installation on which it is
already there? Preferably without doing a reboot? I am sure ramfs is
doing me no good, but I want to avoid creating new problems by
removing it in a clumsy way.

IMHO, ext3 was introduced in order to correct some bit rot problems in
ext2, as well as to introduce journaling, as such it is not surprising
that it shares a lot of code with ext2. The intention was, I think, to
leave behind the parts of the code that rotted the bits, while
introducing a major new feature. I can imagine that in certain
restricted applications ext2 never executes the part of its code that
rots bits, and as a consequence Stan has never had problems with it.

But I have never had problems with ext3, and all my disks are
formatted in ext3, so I incline toward a path that is the least change
from my present situation. I labeled my post in a way that I hoped
would make it clear that I did not want to engage in the larger (more
interesting???) question of ramfs, in general, and particularly XFS,
which I view as a possible alternative to ext4, to which I have not
yet seen fit to migrate.

So how do I turn off ramfs on a wheezy box where it was installed as
part of the initial net-inst install, and seems to be involved it
the proper functioning of the file system root ( / ) ???

Suggestions?

--
Paul E Condon
peco...@mesanetworks.net

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

Archive: http://lists.debian.org/20120326172...@big.lan.gnu

[Stan Hoeppner]

On 3/26/2012 12:29 PM, Paul E Condon wrote:

> Please address my OT question in my OT branch of this
> "increase-ramfs-howto" discussion.
>
> How do I turn off ramfs on a wheezy installation on which it is
> already there? Preferably without doing a reboot? I am sure ramfs is
> doing me no good, but I want to avoid creating new problems by
> removing it in a clumsy way.

Start a new thread for this issue. I dunno how to perma-disable tmpfs
mounted on /tmp. I don't have the time right now. Figuring that out is
the time consuming part. Once you have that done, you simply create
/tmp in your root filesystem with appropriate permissions.

drwxrwxrwt 4 root root

> IMHO, ext3 was introduced in order to correct some bit rot problems in
> ext2, as well as to introduce journaling, as such it is not surprising
> that it shares a lot of code with ext2. The intention was, I think, to
> leave behind the parts of the code that rotted the bits, while
> introducing a major new feature. I can imagine that in certain
> restricted applications ext2 never executes the part of its code that
> rots bits, and as a consequence Stan has never had problems with it.

Don't use slang jargon if you're not familiar with it. ;) Read up on
"bit rot" and "software rot" so you understand what the OP was referring
to when he used the term "bit rot". He simply meant that programmers
may no longer be taking proper care in making sure the EXT2 code is
maintained to work properly in newer kernels. I disagree with his
assertion here, but I can foresee a day in the future where his
sentiments of today may prove correct.

> But I have never had problems with ext3, and all my disks are
> formatted in ext3, so I incline toward a path that is the least change
> from my present situation. I labeled my post in a way that I hoped
> would make it clear that I did not want to engage in the larger (more
> interesting???) question of ramfs, in general, and particularly XFS,
> which I view as a possible alternative to ext4, to which I have not
> yet seen fit to migrate.

For you Paul, there is no compelling reason to switch from EXT3 to
anything else. Not at this time.

> So how do I turn off ramfs on a wheezy box where it was installed as
> part of the initial net-inst install, and seems to be involved it
> the proper functioning of the file system root ( / ) ???

You don't "turn off" tmpfs as it's used by other system functions. You
simply want to mount /tmp on a different (real) filesystem. As I
mentioned above, try unmounting /tmp and then creating a /tmp with the
permissions I mentioned above. Then search for the answer to disabling
the system level mount of /tmp on tmpfs.

--
Stan

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

Archive: http://lists.debian.org/4F70BAB3...@hardwarefreak.com

[Paul E Condon]

Thanks, Stan.

I had tried to couch my request in the terms that were being used here
without any real understanding of the depths of their inadequacy. I
had already tried to simple mount a spare partition of adequate size
for /tmp, but I got, variously, a response that /tmp was not mounted,
or that it was already mounted. When I tried to umount it, the
response was that it was not mounted. Never that it was busy and
therefore the request should confirmed. Since my last email, a job
that had been running for several days ended, and with that my desire
to do this *without reboot* is gone. I have started trying to
understand what is happening with multiple reboots.

My /etc/fstab is (and always has been from well before I became concerned about ramfs) :

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
# / was on /dev/sda1 during installation
LABEL=pla1 / ext3 errors=remount-ro 0 1
# /mpa2 was on /dev/sda2 during installation
UUID=0fde9fde-fe8c-4119-8690-5809cab2fa7c /mpa2 ext3 defaults 0 2
# /mpa3 was on /dev/sda3 during installation
UUID=e3e6afa5-53d8-44cc-b856-e137c56bd11f /mpa3 ext3 defaults 0 2
# /mpb1 was on /dev/sdb1 during installation
UUID=9e1e016e-aea7-4500-bc96-c8d03229c918 /mpb1 ext3 defaults 0 2
# swap was on /dev/sda4 during installation
UUID=c79a09f3-60af-4255-b54f-13a3c40441b7 none swap sw 0 0
/dev/scd0 /media/cdrom0 udf,iso9660 user,noauto 0 0
/dev/fd0 /media/floppy0 auto rw,user,noauto 0 0

Note that there is no mention of /tmp. This because I want it on the
'root' disk device where it can dynamically share space with /etc,
/boot, /root, etc.

But my 'df' shows:

root@gq:~# df
Filesystem 1K-blocks Used Available Use% Mounted on
rootfs 56710460 6198380 47631312 12% /
udev 580748 0 580748 0% /dev
tmpfs 116428 676 115752 1% /run
/dev/disk/by-uuid/bdef667c-a248-4cb7-b509-943e28fe0f8f 56710460 6198380 47631312 12% /
tmpfs 5120 0 5120 0% /run/lock
tmpfs 232852 0 232852 0% /tmp
tmpfs 232852 0 232852 0% /run/shm
/dev/sda2 9612516 152684 8971540 2% /mpa2
/dev/sda3 9612516 152684 8971540 2% /mpa3
/dev/sdb1 240365208 52997752 175157532 24% /mpb1
/dev/sde1 480046848 279587324 176074552 62% /media/wdp5
/dev/sdd1 480696480 360827236 95450448 80% /media/wdp6
/dev/sdc1 480040596 142041440 313614496 32% /media/wdp7
/dev/sdf1 480688980 295026152 161245236 65% /media/wdp8
root@gq:~#

which does not appear to me to conform to the above /etc/fstab. I do
have a problem with ramfs in that it has apparently been overlaid on a
reasonable, traditional file system, and interferes with the normal
operation of UNIX 'sort', which defaults to using /tmp for scratch
files. How this came to be the case, is a puzzle to me. The long
thread on how to increase the space allocated to ramfs prompted, plus
your reasonable thinking about why it may not be reasonable, at all,
to use ramfs in some situations, encouraged me to ask how I can free
myself from this nonsensical situation that I am in.

On reboot, all this weird stuff is still present in 'df', but I have
discovered a partial fix. There are in /tmp, a few short files as
follows. It differs from reboot to reboot what is there. On the most
recent reboot, I found:

root@gq:~# ls -l /tmp
total 0
drwx------ 2 root root 40 20120326_181914 pulse-PKdhtXMmr18n
root@gq:~#

This seems to be something left over from starting pulse during
boot. When I delete it, I can umount /tmp, and things start working
more to my liking. This is a real drag. It saves perhaps a few thousand
machine cycles once each reboot, i.e. about once a week at most. And
in return bollixes up a very traditional Debian system. Not a fair
trade-off, IMHO.

And finally, the remnant 'df' after this kludge is:

root@gq:~# df
Filesystem 1K-blocks Used Available Use% Mounted on
rootfs 56710460 6245884 47583808 12% /
udev 580720 0 580720 0% /dev
tmpfs 116424 664 115760 1% /run
/dev/disk/by-uuid/bdef667c-a248-4cb7-b509-943e28fe0f8f 56710460 6245884 47583808 12% /
tmpfs 5120 0 5120 0% /run/lock
tmpfs 232844 0 232844 0% /run/shm
/dev/sda2 9612516 152684 8971540 2% /mpa2
/dev/sda3 9612516 152684 8971540 2% /mpa3
/dev/sdb1 240365208 52997752 175157532 24% /mpb1
root@gq:~#

Note that there are TWO lines pertaining to '/'. I do not like this. I
think I can live with 'rootfs instead of a proper, on disk device for
'/', but that great long uuid forces me to adjust the width on my
xterm windows and wastes space on my screen and generally annoys me as
an example of reverse progress.

I can live with the '/run/*' being in ram, as doing so will allow me
to continue to describe my system is a plain vanilla Debian/Wheezy
system when asking for help here, but beyond that, I see no advantage,
and a lot of bother each time whatever I do as work-around breaks. So,
I think my desire to 'turn off ramfs' is still a somewhat accurate
description of what I want. I would like to have ramfs made inactive
from before grub starts. It gains me nothing and forces me to use
jargon that I do not understand, etc.

Suggestions?
--
Paul E Condon
peco...@mesanetworks.net

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

Archive: http://lists.debian.org/20120327021...@big.lan.gnu

[Dom]

On 27/03/12 03:15, Paul E Condon wrote:
> On 20120326_135131, Stan Hoeppner wrote:
>> On 3/26/2012 12:29 PM, Paul E Condon wrote:
>>
>>> So how do I turn off ramfs on a wheezy box where it was installed as
>>> part of the initial net-inst install, and seems to be involved it
>>> the proper functioning of the file system root ( / ) ???
>>
>> You don't "turn off" tmpfs as it's used by other system functions. You
>> simply want to mount /tmp on a different (real) filesystem. As I
>> mentioned above, try unmounting /tmp and then creating a /tmp with the
>> permissions I mentioned above. Then search for the answer to disabling
>> the system level mount of /tmp on tmpfs.

This has been mentioned here quite recently.

Edit /etc/default/rcS.

At the end of the file you will find this entry:

# mount /tmp as a tmpfs
RAMTMP=yes

Change the "yes" to "no".

Reboot.

This will only affect /tmp. There are other entries for the other ramfs
filesystems, but they take very little memory and so can be as they are.

--
Dom

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

Archive: http://lists.debian.org/4F7156BD...@rpdom.net

[Roger Leigh]

On Sun, Mar 25, 2012 at 10:51:07AM +0000, Camaleón wrote:
> On Sat, 24 Mar 2012 12:40:12 -0600, Javier Vasquez wrote:
> > On Sat, Mar 24, 2012 at 11:10 AM, Camaleón <noel...@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-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20120327131...@codelibre.net

[Camaleón]

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

> On Sun, Mar 25, 2012 at 10:51:07AM +0000, Camaleón 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,

--
Camaleón

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

Archive: http://lists.debian.org/jkskjc$di0$1...@dough.gmane.org

[Paul E Condon]

On 20120327_065717, Dom wrote:
> On 27/03/12 03:15, Paul E Condon wrote:
> >On 20120326_135131, Stan Hoeppner wrote:
> >>On 3/26/2012 12:29 PM, Paul E Condon wrote:
> >>
> >>>So how do I turn off ramfs on a wheezy box where it was installed as
> >>>part of the initial net-inst install, and seems to be involved it
> >>>the proper functioning of the file system root ( / ) ???
> >>
> >>You don't "turn off" tmpfs as it's used by other system functions. You
> >>simply want to mount /tmp on a different (real) filesystem. As I
> >>mentioned above, try unmounting /tmp and then creating a /tmp with the
> >>permissions I mentioned above. Then search for the answer to disabling
> >>the system level mount of /tmp on tmpfs.
>
> This has been mentioned here quite recently.
>
> Edit /etc/default/rcS.
>
> At the end of the file you will find this entry:
>
> # mount /tmp as a tmpfs
> RAMTMP=yes
>
> Change the "yes" to "no".
>
> Reboot.
>
> This will only affect /tmp. There are other entries for the other
> ramfs filesystems, but they take very little memory and so can be as
> they are.
>
> --
> Dom

Thanks. It works. I feel much better now.

--
Paul E Condon
peco...@mesanetworks.net

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

Archive: http://lists.debian.org/20120327155...@big.lan.gnu

[Andrei POPESCU]

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.

> 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

[Camaleón]

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 :-)

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

--
Camaleón


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

Archive: http://lists.debian.org/jkv9oj$hqr$8...@dough.gmane.org

[Tom H]

On Wed, Mar 28, 2012 at 8:50 AM, Andrei POPESCU
<andreim...@gmail.com> 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.
>
>> 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-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/CAOdoSwD+5715uf-Ztoo-jLnv...@mail.gmail.com

[Andrei POPESCU]

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 ;) 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 :p

> 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)? :)

[Camaleón]

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) >:-)

>> >> 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 :p

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,

--
Camaleón


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

Archive: http://lists.debian.org/jkvg6v$hqr$1...@dough.gmane.org

[Roger Leigh]

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.

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-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20120328173...@codelibre.net

[Dom]

> 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-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/4F735828...@rpdom.net

[Brian]

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-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20120328181227.GP16316@desktop

[Andrei POPESCU]

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 :p
>
> 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_and_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?

[Andrei POPESCU]

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.

[Camaleón]

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-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/jkvqfe$hqr$1...@dough.gmane.org

[Camaleón]

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-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/jkvr6a$hqr$2...@dough.gmane.org

[Camaleón]

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 :p
>>
>> 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_and_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-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/jkvtdh$hqr$2...@dough.gmane.org

[Andrei POPESCU]

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.

[Andrei POPESCU]

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.

[Paul E Condon]

^^^^^^^^^ ^^^^^^^^^

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
peco...@mesanetworks.net

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

Archive: http://lists.debian.org/2012032822...@big.lan.gnu

[Michael Biebl]

On 28.03.2012 20:27, Dom wrote:
> This change has caused me a number of (admittedly not too serious)
> problems.

To get a better feeling for what kind of problems users with
tmpfs-on-tmp run into, I think filing bugs against the affected packages
would be a great idea.
Ideally, usertagged, so they can easily be found [1].
Or file them against initscript/sysvinit and we re-assign them later
accordingly.

This way we can make a better decision if this particular change needs
to be reverted, tweaked or can be kept.

Roger,
what do you think?

Imho having more data can't hurt.

Michael


[1] I'd suggest

User: pkg-sysvi...@lists.alioth.debian.org
Usertags: tmp-on-tmpfs

--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[Javier Vasquez]

On Sun, Mar 25, 2012 at 12:09 AM, Stan Hoeppner <st...@hardwarefreak.com> wrote:
> On 3/24/2012 4:02 PM, Javier Vasquez wrote:
>> 2012/3/24 shirish शिरीष <shiri...@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.
> ...

Hmm, but you omitted swapping. Using your same link, you'll see that
you can use whole RAM, and that doesn't mean oversizing, specially
with the OP swap size...

First some more data form the link:

********************
tmpfs puts everything into the kernel internal caches and grows and
shrinks to accommodate the files it contains and is able to swap
unneeded pages out to swap space. It has maximum size limits which can
be adjusted on the fly via 'mount -o remount ...'
...
If you compare it to ramfs (which was the template to create tmpfs)
you gain swapping and limit checking.
...
Since tmpfs lives completely in the page cache and on swap, all tmpfs
pages currently in memory will show up as cached. It will not show up
as shared or something like that. Further on you can check the actual
RAM+swap use of a tmpfs instance with df(1) and du(1).
********************

So yes, one needs to be careful, not to oversize your tmpfs. That's
completely true, but the limit is not physical RAM, it is actually
RAM+Swap, as I mentioned before.

On this thread, it is asked about how to got with huge files to be
handled by tmpfs, well, debian still gives the option to set /tmp as a
regular partition for example, but if you also have enough swap space,
then by setting the right tmpfs size, you can still get away with it
through tmpfs. Actually in this case I suggested 2g or even 3g for
tmpfs, which was discarded because it sounded dangerous at first by
looking only at RAM, and not considering at all the available swap,
which in my mind and experience is a mistake.

>
> The OP would likely be far better off simply mounting /tmp on his root
> filesystem as was always done in the past.

I don't agree. Actually the OP has plenty of swap, so he could get
away with 2g or 3g of tmpfs with no risk.

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

This is true, but his swap area already provides that in his case.

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

Just in case, although totally OT, I use ext4 for everything, and I
don't have any problems, :-) And before tmpfs, I kept /tmp in ext4
then, without problems either, so I don't think there's need to
specially recommend ext2. But this is opinion based on self
experience only.

And I'm sorry to reply even though it has been asked to close the
thread, but I believe there's need to realize that we're not talking
just about RAM.

And on small RAM boxes, things can still work with enough swap, and
for them there was a rule of thumb that said one needed to double at
least the RAM size, and one can play then with total of 3 times RAM
size...

The same way people is recommending disk partitions, one could
recommend increase of swap space, whether through more swap partitions
or even swap files (there's no need to create new partitions for
swapping). And one can always change whatever wanted...

I think this time I won't come back to the thread, :-)


--
Javier.

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

Archive: http://lists.debian.org/CALUrRGfFkX4DTt2ZUhr1OX5B...@mail.gmail.com

[Andrei POPESCU]

On Mi, 28 mar 12, 16:58:03, Paul E Condon wrote:
> >
> > 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.

You must be misunderstanding me, I meant "some directory in your home",
because on most systems /home has enough space.

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

Err... your original /tmp is a directory on / not a file[1] and if you
don't mount anything there your system will happily use the available
space on / (the root partition).

[1] unless you had a dedicated partition, but AFAIK in such a case you
wouldn't get a tmpfs anyway

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

Why do you think such scratch space should be in /tmp (regardless of
whether /tmp is on tmpfs, a separate partition or just a directory on
/)?

Kind regards,
Andrei
P.S. I accidentally did some re-wrapping, how long do you set your
lines?

[Roger Leigh]

On Thu, Mar 29, 2012 at 01:29:32AM +0200, Michael Biebl wrote:
> On 28.03.2012 20:27, Dom wrote:
> > This change has caused me a number of (admittedly not too serious)
> > problems.
>
> To get a better feeling for what kind of problems users with
> tmpfs-on-tmp run into, I think filing bugs against the affected packages
> would be a great idea.
> Ideally, usertagged, so they can easily be found [1].
> Or file them against initscript/sysvinit and we re-assign them later
> accordingly.
>
> This way we can make a better decision if this particular change needs
> to be reverted, tweaked or can be kept.
>
> Roger,
> what do you think?

That sounds fine by me. It would be particularly helpful to know
more about the specific machine and software in use rather than
"it doesn't work". In particular:

- the size and free space on the root filesystem
- the amount of system memory
- the amount of swap
- which applications and/or shell commands you were using which caused
you to run out of space. The size of the files created would be
useful to know.

While the existing defaults may be better, we do have the means to
configure it or disable it, and this could potentially be done in
the installer once we know more about the requirements. If we can't
fix it nicely for wheezy, we can always change the default or
document how to disable it in the release notes.


Thanks,

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-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20120329093...@codelibre.net

[Camaleón]

On Thu, 29 Mar 2012 01:10:19 +0300, Andrei POPESCU wrote:

> On Mi, 28 mar 12, 20:47:45, Camaleón wrote:

(...)

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

(...)

That's the problem, Andrei. The nebook has 2 GiB of RAM, enough for not
having to care about this and the operation I was performing was browsing
a 75 MiB tar.gz file with Midnight Commander. That's simply what flooded
tpmfs and made MC to abort.

Greetings,

--
Camaleón


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

Archive: http://lists.debian.org/jl1qep$2ge$3...@dough.gmane.org

[Camaleón]

On Thu, 29 Mar 2012 01:36:36 +0300, Andrei POPESCU wrote:

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

I don't usually pay much attention to what "NEWS.Debian" says (it depends
on the available time I have) until I have any problem -which means is
too late- but "Release Notes" is a must for anyone installing/upgrading
their systems. It would be nice to have a mention about this setting
there.

Besides, if Debian wants to (or is interested in) promoting this feature,
a few practical samples (use cases) on how to set a good size for tmpfs
will help people to keep this enabled and having a better understanding
on this.

Greetings,

--
Camaleón


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

Archive: http://lists.debian.org/jl1r66$2ge$4...@dough.gmane.org

[Andrei POPESCU]

On Jo, 29 mar 12, 14:09:29, Camaleón wrote:
>
> That's the problem, Andrei. The nebook has 2 GiB of RAM, enough for not
> having to care about this and the operation I was performing was browsing
> a 75 MiB tar.gz file with Midnight Commander. That's simply what flooded
> tpmfs and made MC to abort.

Maybe I misunderstood, is that the compressed or the uncompressed size?
2GB RAM gives me a 403 MB /tmp ...

[Camaleón]

On Thu, 29 Mar 2012 18:52:07 +0300, Andrei POPESCU wrote:

> On Jo, 29 mar 12, 14:09:29, Camaleón wrote:
>>
>> That's the problem, Andrei. The nebook has 2 GiB of RAM, enough for not
>> having to care about this and the operation I was performing was
>> browsing a 75 MiB tar.gz file with Midnight Commander. That's simply
>> what flooded tpmfs and made MC to abort.
>
> Maybe I misunderstood, is that the compressed or the uncompressed size?

It's the usual compressed kernel source file, e.g.:

http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.2.13.tar.bz2

> 2GB RAM gives me a 403 MB /tmp ...

"tmpfs" for "/tmp" was set to 423 MiB as I explained here¹ which seemed
to be not enough because, despite of the size, I run "out of space".

http://lists.debian.org/debian-user/2011/11/msg02155.html

Greetings,

--
Camaleón


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

Archive: http://lists.debian.org/jl2286$2ge$1...@dough.gmane.org

[Dom]

On 29/03/12 17:22, Camaleón wrote:
> On Thu, 29 Mar 2012 18:52:07 +0300, Andrei POPESCU wrote:
>
>> On Jo, 29 mar 12, 14:09:29, Camaleón wrote:
>>>
>>> That's the problem, Andrei. The nebook has 2 GiB of RAM, enough for not
>>> having to care about this and the operation I was performing was
>>> browsing a 75 MiB tar.gz file with Midnight Commander. That's simply
>>> what flooded tpmfs and made MC to abort.
>>
>> Maybe I misunderstood, is that the compressed or the uncompressed size?
>
> It's the usual compressed kernel source file, e.g.:
>
> http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.2.13.tar.bz2
>
>> 2GB RAM gives me a 403 MB /tmp ...
>
> "tmpfs" for "/tmp" was set to 423 MiB as I explained here¹ which seemed
> to be not enough because, despite of the size, I run "out of space".
>
> http://lists.debian.org/debian-user/2011/11/msg02155.html

The current kernel source file uncompresses to over 500MB. I'm guessing
that mc uncompresses the whole file to examine it, so it will exceed
your tmpfs size.

Disclaimer: I've never used Midnight Commander

--
Dom

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

Archive: http://lists.debian.org/4F749B37...@rpdom.net

[Camaleón]

On Thu, 29 Mar 2012 18:26:15 +0100, Dom wrote:

> On 29/03/12 17:22, Camaleón wrote:
>> On Thu, 29 Mar 2012 18:52:07 +0300, Andrei POPESCU wrote:
>>
>>> On Jo, 29 mar 12, 14:09:29, Camaleón wrote:
>>>>
>>>> That's the problem, Andrei. The nebook has 2 GiB of RAM, enough for
>>>> not having to care about this and the operation I was performing was
>>>> browsing a 75 MiB tar.gz file with Midnight Commander. That's simply
>>>> what flooded tpmfs and made MC to abort.
>>>
>>> Maybe I misunderstood, is that the compressed or the uncompressed
>>> size?
>>
>> It's the usual compressed kernel source file, e.g.:
>>
>> http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.2.13.tar.bz2
>>
>>> 2GB RAM gives me a 403 MB /tmp ...
>>
>> "tmpfs" for "/tmp" was set to 423 MiB as I explained here¹ which seemed
>> to be not enough because, despite of the size, I run "out of space".
>>
>> http://lists.debian.org/debian-user/2011/11/msg02155.html
>
> The current kernel source file uncompresses to over 500MB. I'm guessing
> that mc uncompresses the whole file to examine it, so it will exceed
> your tmpfs size.

Yes, that's what happened. The space that was needed by "utar" it
exceeded the tmpfs default settings.

> Disclaimer: I've never used Midnight Commander

I use it almost every day for everything.

Greetings,

--
Camaleón

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

Archive: http://lists.debian.org/jl28jb$2ge$1...@dough.gmane.org

[Keith McKenzie]

On 29/03/12 18:26, Dom wrote:
> Disclaimer: I've never used Midnight Commander

Give it a go, you may fall in love with it, like many have. :)

Keith

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

Archive: http://lists.debian.org/4F74C849...@gmail.com

[Andrei POPESCU]

On Jo, 29 mar 12, 14:21:58, Camaleón wrote:
>
> I don't usually pay much attention to what "NEWS.Debian" says

Do you have apt-listchanges installed? It's Priority: standard now.

[Paul E Condon]

Why? Because the last time I looked which was long ago, using /tmp for
scratch space was recommended practice in the FHS. I didn't decide to
use /tmp when I started using it. /tmp was used by Debian packages and
I used the packages. Then I read the FHS to try to understand how they
managed to just do something that I well knew required scratch space.
And there it was. Maybe not a requirement, but an indication that this
was a useful result of coding to the standard. I question whether any
debian package manager has ever released a package to testing without
first doing some tests to be sure it used /tmp in a reasonable
fashion. Whenever a software item arrived for packaging, my
understanding is, that the bulk of the work of packaging is bringing
it into compliance with FHS. As a consequence, I have very little
patience with the argument that developers would sudden lose all self
control and good sense merely because they have this new feature called
tmpfs or ramfs. There is no record of them having been, as a group, so
foolish.

Also, today I am having an experience which seems to indicate that
approx, the debian repository cacher, also has used /tmp for scratch
files. In fact, after several hours of poking at it, I have abandoned
use of approx for the while until this whole thing is sorted out by
people who actually understand how Debian works, which is a small
group of experts to which I surely don't deserve to belong.

Kind regards,

--
Paul E Condon
peco...@mesanetworks.net


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

Archive: http://lists.debian.org/20120330040...@big.lan.gnu

[Tom H]

I understand Andrei's suggestion to be that you set TMPDIR to a
directory in home when launching the particular job that needs a large
TMPDIR.

Someone pointed out, in this thread or another tmpfs one, that the
limit for the tmpfs size of "/tmp" is "RAM+SWAP" so you could increase
the size of your swap to accommodate your sort - or simply disable
tmpfs for "/tmp" on this box.

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

Archive: http://lists.debian.org/CAOdoSyhbUEwdT8cS4JXUgj3...@mail.gmail.com

[Andrei POPESCU]

On Jo, 29 mar 12, 22:02:00, Paul E Condon wrote:
> >
> > Why do you think such scratch space should be in /tmp (regardless of
> > whether /tmp is on tmpfs, a separate partition or just a directory on
> > /)?
>
> Why? Because the last time I looked which was long ago, using /tmp for
> scratch space was recommended practice in the FHS.

Sure, but it is not even required and there is absolutely no mention
about the size. A good behaving program should (as far as I understand)

- fail gracefully if there is not enough space in /tmp
- obey $TMPFS

This change is uncovering some programs and practices that made
unfounded assumptions about the size of /tmp and some don't even obey
$TMPFS so you have no way to easily assign them more temporary space.

You know the saying: "Assumption is the mother of all ..." :)

Kind regards,
Andrei

[Camaleón]

On Fri, 30 Mar 2012 00:20:14 +0300, Andrei POPESCU wrote:

> On Jo, 29 mar 12, 14:21:58, Camaleón wrote:
>>
>> I don't usually pay much attention to what "NEWS.Debian" says
>
> Do you have apt-listchanges installed? It's Priority: standard now.

For this system I don't know... going to check. Yes, it's installed but
eminently omitted/unused.

Greetings,

--
Camaleón


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

Archive: http://lists.debian.org/jl4f9u$8pu$5...@dough.gmane.org

[Paul E Condon]

It is my understanding that the directory that one wishes to use in
TMPDIR must be mentioned in a line in /etc/fstab for this to work, and
a block special mountable device must be mentioned in that line. And
this is the way it does work on my system. Choise of TMPDIR did not
have this restriction in the past. This change has implications for
many packages. My point is that competent developers should check this
out. I have found a way forward on my personal situation without
pressing this discussion further. Your suggestion is not useful for
addressing the problem that I was trying to describe. If I am wrong,
my bad. But if this is true, there will be a lot of pain and anguish.

Enough said. Thankyou.

--
Paul E Condon
peco...@mesanetworks.net

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

Archive: http://lists.debian.org/2012033020...@big.lan.gnu

[Paul E Condon]

On 20120329_095413, Andrei POPESCU wrote:

> On Mi, 28 mar 12, 16:58:03, Paul E Condon wrote:
> > >
> > > 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.
>
> You must be misunderstanding me, I meant "some directory in your home",
> because on most systems /home has enough space.

No. You misunderstand me. There is a new extra requirement on TMPDIR, a
restriction on ones choise of its value. A directory entry on a disk
file system is not enough. It must be a directory entry that has a line
in /etc/fstab that enables its use as a mount point to real separate
partition. At least that is the way it is now. If this restriction were
removed by some change in the implementation that I know not how to do...
then your suggestion would likely work and the old way of using /tmp
would also work.

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

In UNIX all directories are files ... special files that serve a
special system defined function, but files in the sense that they are
not inodes, or sectors, or blocks, etc. Linux follows UNIX on this
innovation of long ago.

> Err... your original /tmp is a directory on / not a file[1] and if you
> don't mount anything there your system will happily use the available
> space on / (the root partition).
>
> [1] unless you had a dedicated partition, but AFAIK in such a case you
> wouldn't get a tmpfs anyway

I don't know why I get a tmpfs. I didn't ask for it. I have supposed
it came with a new way of doing file handling in the system software,
part of a new implementation that was supposed to be a work-alike
replacement of the previous version.

I never had a dedicated partion for /tmp and now it is required. That,
to me, is a change. I fixed it when I learned that it is now required,
and I think it would be nice to go back to the old way because the old
way did not require a separate partition. But I repeat myself. Enough.
What happens will happen.

>
> > 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?
>
> Why do you think such scratch space should be in /tmp (regardless of
> whether /tmp is on tmpfs, a separate partition or just a directory on
> /)?
>
> Kind regards,
> Andrei
> P.S. I accidentally did some re-wrapping, how long do you set your
> lines?

The default in mutt, whatever that is. I like defaults. That is the
main thing that originally attracted me to Debian. It offered defaults
that worked.

--
Paul E Condon
peco...@mesanetworks.net


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

Archive: http://lists.debian.org/2012033020...@big.lan.gnu

[Tom H]

On Fri, Mar 30, 2012 at 4:12 PM, Paul E Condon

Not quite!

To expand on what I think was Andrei's suggestion, you can run mc, for
example, this way "TMPDIR=/home/user/tmp mc"; mc will create tmp files
in "/home/user/tmp" as long as "/home/user/tmp" exists.

Two other solutions are to use the "RAM+SWAP" method mentioned above
or to revert back to the previous behavior of "/tmp" by disabling the
use of tmpfs for it with "RAMTMP=no" in "/etc/default/rcS" and either
allowing "/tmp" to be on "/" or create a separate partition for it and
mount it via "/etc/fstab".

With "My point is that competent developers should check this out"
you're implying that the person who made this change isn't competent;
not a particularly useful, helpful, or kind thing to say...

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

Archive: http://lists.debian.org/CAOdoSxsK4i8PuE_beefJzRG...@mail.gmail.com

[Paul E Condon]

Not quite.
Debian is an amazingly large organization with amazingly well worked
out system of division of labor, but maybe not perfect division of
labor. Things *can* be missed. Things *can* be miscommunicated or
misunderstood. Lord knows I do a *lot* of misunderstanding, and too
much miscommunicating. But still I think there is a problem. My
perception is that no suggestion that I have seen so far checks out
for me when I try to follow the suggestion in what I do. I don't
think I have misunderstood the suggestion, but maybe I have. I think
continued efforts to convince me that there is no problem by exercises
in pure reason are failing. I will stop responding to them in order
to free up your valuable time for more promising endeavors. I mean
no offense. Consider me to be invincibly ignorant, to borrow a phrase
for R. Catholic apologetics.

Peace.

--
Paul E Condon
peco...@mesanetworks.net

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

Archive: http://lists.debian.org/2012033021...@big.lan.gnu

[Andrei POPESCU]

On Vi, 30 mar 12, 14:44:37, Paul E Condon wrote:
>
> No. You misunderstand me. There is a new extra requirement on TMPDIR, a
> restriction on ones choise of its value. A directory entry on a disk
> file system is not enough. It must be a directory entry that has a line
> in /etc/fstab that enables its use as a mount point to real separate
> partition. At least that is the way it is now. If this restriction were
> removed by some change in the implementation that I know not how to do...
> then your suggestion would likely work and the old way of using /tmp
> would also work.

I really have no idea what you are talking about, but there is no new
requirement on TMPDIR.

> In UNIX all directories are files ... special files that serve a
> special system defined function, but files in the sense that they are
> not inodes, or sectors, or blocks, etc. Linux follows UNIX on this
> innovation of long ago.

From this point of view, sure, but this is not what I was talking about.

> > Err... your original /tmp is a directory on / not a file[1] and if you
> > don't mount anything there your system will happily use the available
> > space on / (the root partition).
> >
> > [1] unless you had a dedicated partition, but AFAIK in such a case you
> > wouldn't get a tmpfs anyway
>
> I don't know why I get a tmpfs. I didn't ask for it. I have supposed
> it came with a new way of doing file handling in the system software,
> part of a new implementation that was supposed to be a work-alike
> replacement of the previous version.

/tmp on tmpfs has been optional before, it's just that the initscript
maintainers decided to make it default.

> I never had a dedicated partion for /tmp and now it is required. That,
> to me, is a change. I fixed it when I learned that it is now required,
> and I think it would be nice to go back to the old way because the old
> way did not require a separate partition. But I repeat myself. Enough.
> What happens will happen.

There is no *requirement* for /tmp to be a separate partition. I really
don't understand how you came to this conclusion.

> > P.S. I accidentally did some re-wrapping, how long do you set your
> > lines?
> The default in mutt, whatever that is. I like defaults. That is the
> main thing that originally attracted me to Debian. It offered defaults
> that worked.

Mutt uses an external editor for writing e-mails

,----[ man muttrc ]
| editor
| Type: path
| Default: “”
|
| This variable specifies which editor is used by mutt. It defaults to the
| value of the $VISUAL, or $EDITOR, environment variable, or to the
| string “/usr/bin/editor” if neither of those are set.
`----

Kind regards,
Andrei

[Paul E Condon]

On 20120331_003333, Andrei POPESCU wrote:
> On Vi, 30 mar 12, 14:44:37, Paul E Condon wrote:
> >
> > No. You misunderstand me. There is a new extra requirement on TMPDIR, a
> > restriction on ones choise of its value. A directory entry on a disk
> > file system is not enough. It must be a directory entry that has a line
> > in /etc/fstab that enables its use as a mount point to real separate
> > partition. At least that is the way it is now. If this restriction were
> > removed by some change in the implementation that I know not how to do...
> > then your suggestion would likely work and the old way of using /tmp
> > would also work.
>
> I really have no idea what you are talking about, but there is no new
> requirement on TMPDIR.

Perhaps you are thinking of an officially published requirement. What
I mean 'requirement' is a condition which by trial is found to be
necessary for it to work. I tried cases that did not meet this
condition and none of them worked, and conditions which did meet this
condition did work. The test was simple. I found a file of output
from find on a large file structure and tried to sort in on inode
number. I got an error message about insufficient file space without
any attempt at a fix, then I tried several values for TMPDIR and
several different entries in /etc/fstab. Some combinations
successfully sorted the file. Some aborted with the same error message
as the base trial. The pattern was clear. There must be an entry in
/etc/fstab and the entry must be usable to mount an existing partition
on an existing disk in the plain-vanilla traditional way. Putting an
entry in that would choke on mount -a, also did no good in letting
sort run to completion.

But Andrei, I don't think either of us is going to actually fix the
problem. And I do think that we have already generated enough noise
here to attract the attention of someone who can. That person, or
persons, has already probably tried to verify my claim, and has
already succeeded, or not. The process is underway. Let us stop this
fruitless back and forth and wait and see. I have recieved two
messages telling me that the problem is surely not in coreutils, which
I do not doubt. But no one yet has told me that they have tried to
repeat my test and have not found a problem. But maybe I have
misunderstood some messages. In which case it is still worthwhile
stopping this discussion, so let us do so.

Peace.

OK. I don't know how to fix it, and am at a loss to find out how. Lines
do get longer as they are quoted. I use emacs to write mail.

--
Paul E Condon
peco...@mesanetworks.net


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

Archive: http://lists.debian.org/2012033022...@big.lan.gnu

[Andrei POPESCU]

On Vi, 30 mar 12, 16:40:18, Paul E Condon wrote:
>
> Perhaps you are thinking of an officially published requirement. What
> I mean 'requirement' is a condition which by trial is found to be
> necessary for it to work. I tried cases that did not meet this
> condition and none of them worked, and conditions which did meet this
> condition did work. The test was simple. I found a file of output
> from find on a large file structure and tried to sort in on inode
> number. I got an error message about insufficient file space without
> any attempt at a fix, then I tried several values for TMPDIR and
> several different entries in /etc/fstab. Some combinations
> successfully sorted the file. Some aborted with the same error message
> as the base trial. The pattern was clear. There must be an entry in
> /etc/fstab and the entry must be usable to mount an existing partition
> on an existing disk in the plain-vanilla traditional way. Putting an
> entry in that would choke on mount -a, also did no good in letting
> sort run to completion.

Please post the exact commands you have tried and the error messages.
From the paragraph above it is not very clear to me what you did, but I
assure you TMPDIR works fine without an entry in fstab. Just make sure
the directory exists and you have sufficient space on that partition.

> OK. I don't know how to fix it, and am at a loss to find out how. Lines
> do get longer as they are quoted. I use emacs to write mail.

It's nothing critical, it's just that sometimes I like to split your
paragraphs to insert comments and vim's automatic re-wrapping is still a
bit unpredictable for me. Emacs probably has an e-mail "mode" and a
typical text width is 72.

As I'm not familiar with Emacs and this is buried deep in the tmpfs
thread, if you are interested to fine tune this you should probably
start a new thread.

[Tom H]

On Fri, Mar 30, 2012 at 4:44 PM, Paul E Condon
<peco...@mesanetworks.net> wrote:
> On 20120329_095413, Andrei POPESCU wrote:
>> On Mi, 28 mar 12, 16:58:03, Paul E Condon wrote:


>> > > 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.
>>
>> You must be misunderstanding me, I meant "some directory in your home",
>> because on most systems /home has enough space.
>
> No. You misunderstand me. There is a new extra requirement on TMPDIR, a
> restriction on ones choise of its value. A directory entry on a disk
> file system is not enough. It must be a directory entry that has a line
> in /etc/fstab that enables its use as a mount point to real separate
> partition. At least that is the way it is now. If this restriction were
> removed by some change in the implementation that I know not how to do...
> then your suggestion would likely work and the old way of using /tmp
> would also work.

There's no extra requirement!

If you set up "/tmp" as a "real separate partition", that's the "/tmp"
that the system'll use (it looks like it'll be a bind-mount over a
tmpfs "/tmp" if you don't set "RAMTMP=no" in "/etc/default/rcS").

Pre-tmp-as-tmpfs, if you don't set up "/tmp" as a "real separate
partition", "/tmp" is a directory on "/".

Post-tmp-as-tmpfs, if you don't set up "/tmp" as a "real separate
partition", "/tmp" is a mount-point for a tmpfs filesystem the default
"RAMTMP=yes" set in "/etc/default/rcS".

By default, the size of this filesystem is 20% of RAM because there
are other tmpfs filesystems set up by default ("/run", "/run/lock",
"/run/shm") and they've been sized, respectively, at 10% of RAM, 5MiB,
20% of RAM so that the total of tmpfs filesystems adds up to
"50%+5MiB" for systems that don't have any swap set up to be able to
operate in the event that the tmpfs filesystems are used up fully.

If you want a larger tmpfs "/tmp", you can change "TMP_SIZE" in
"/etc/default/tmpfs" (or, untested, edit "/etc/fstab" and add a "tmpfs
/tmp tmpfs size=xxx 0 0"). I'd mentioned earlier someone else's
suggestion that you can set the maximum size of to RAM+SWAP. It's
probably safer to set it to 20%_of_RAM+SWAP.

If you don't want to use tmpfs for "/tmp", you simply set "RAMTMP=no"
in "/etc/default/rcS".

> I never had a dedicated partion for /tmp and now it is required. That,
> to me, is a change. I fixed it when I learned that it is now required,
> and I think it would be nice to go back to the old way because the old
> way did not require a separate partition. But I repeat myself. Enough.

Having a tmpfs filesystem for "/tmp" doesn't mean that a dedicated
partition is required for "/tmp".

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

Archive: http://lists.debian.org/CAOdoSyAu73zFeceL7O3bi+L...@mail.gmail.com

[Paul E Condon]

What you say doesn't work for me, but something else does.

Peace.

--
Paul E Condon
peco...@mesanetworks.net

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

Archive: http://lists.debian.org/2012033117...@big.lan.gnu

[Paul E Condon]

On 20120331_114636, Andrei POPESCU wrote:
> On Vi, 30 mar 12, 16:40:18, Paul E Condon wrote:
> >
> > Perhaps you are thinking of an officially published requirement. What
> > I mean 'requirement' is a condition which by trial is found to be
> > necessary for it to work. I tried cases that did not meet this
> > condition and none of them worked, and conditions which did meet this
> > condition did work. The test was simple. I found a file of output
> > from find on a large file structure and tried to sort in on inode
> > number. I got an error message about insufficient file space without
> > any attempt at a fix, then I tried several values for TMPDIR and
> > several different entries in /etc/fstab. Some combinations
> > successfully sorted the file. Some aborted with the same error message
> > as the base trial. The pattern was clear. There must be an entry in
> > /etc/fstab and the entry must be usable to mount an existing partition
> > on an existing disk in the plain-vanilla traditional way. Putting an
> > entry in that would choke on mount -a, also did no good in letting
> > sort run to completion.
>
> Please post the exact commands you have tried and the error messages.
> From the paragraph above it is not very clear to me what you did, but I
> assure you TMPDIR works fine without an entry in fstab. Just make sure
> the directory exists and you have sufficient space on that partition.

The exact commands depended on the exact setup of my systems. (I have
3) I happen to have a setup with multiple partitions, some of them
unused or easily repurposed. I set up test cases. I try a few
commands. And I dismantle the setup if some of the resources need to
be returned to their normal use. The exact commands, without extensive
documentation would just lead to further fruitless discussion, IMHO.
My system is working now with /tmp on its own partition. When the
problem I encountered is fixed, I will return to the old way of doing
things. This experience has been difficult for me. I thought I had
found an issue that needs fixing for the common good. I still think
that. But I have done what I can, and it is clearly not enough.

Peace.

--
Paul E Condon
peco...@mesanetworks.net


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

Archive: http://lists.debian.org/2012033117...@big.lan.gnu

[Andrei POPESCU]

On Sb, 31 mar 12, 11:08:39, Paul E Condon wrote:
> >
> > Having a tmpfs filesystem for "/tmp" doesn't mean that a dedicated
> > partition is required for "/tmp".
>
> What you say doesn't work for me, but something else does.

Show us (what doesn't work) :)

Kind regards,
Andrei

[Paul E Condon]

On 20120401_130449, Andrei POPESCU wrote:
> On Sb, 31 mar 12, 11:08:39, Paul E Condon wrote:
> > >
> > > Having a tmpfs filesystem for "/tmp" doesn't mean that a dedicated
> > > partition is required for "/tmp".
> >
> > What you say doesn't work for me, but something else does.
>
> Show us (what doesn't work) :)

My statement was made in response to a statement by another person
whose name you have snipped out. It is just as well that you did this
snipping, because, now I regret writing precisely that in response to
that remark.

What *does* work for me is a separate partition for /tmp, which is
something that I never had to have before. Having to set up such as
part of a dist-upgrade, or full-upgrade, or re-install breaks the 'it
just works' paradigm. I think it was not really working in squeeze as
well, but until quite recently, I was unaware of the meaning of some
error messages and unable to design and execute diagnostic to tests, or
to formulate questions that would evoke helpful explanations. (You do
realize by now that I do have communication problems, I hope.)

Peace.
--
Paul E Condon
peco...@mesanetworks.net


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

Archive: http://lists.debian.org/2012040118...@big.lan.gnu

[Tom H]

On Sun, Apr 1, 2012 at 2:52 PM, Paul E Condon <peco...@mesanetworks.net> wrote:
> On 20120401_130449, Andrei POPESCU wrote:
>> On Sb, 31 mar 12, 11:08:39, Paul E Condon wrote:
>>>>
>>>> Having a tmpfs filesystem for "/tmp" doesn't mean that a dedicated
>>>> partition is required for "/tmp".
>>>
>>> What you say doesn't work for me, but something else does.
>>
>> Show us (what doesn't work) :)
>
> My statement was made in response to a statement by another person
> whose name you have snipped out. It is just as well that you did this
> snipping, because, now I regret writing precisely that in response to
> that remark.
>
> What *does* work for me is a separate partition for /tmp, which is
> something that I never had to have before. Having to set up such as
> part of a dist-upgrade, or full-upgrade, or re-install breaks the 'it
> just works' paradigm. I think it was not really working in squeeze as
> well, but until quite recently, I was unaware of the meaning of some
> error messages and unable to design and execute diagnostic to tests, or
> to formulate questions that would evoke helpful explanations. (You do
> realize by now that I do have communication problems, I hope.)

I gave up on this thread when I saw the cryptic and useless "What you
say doesn't work for me, but something else does" but now that you've
explained what you think works, I have to add that you've made very
little sense throughout this thread and that your problem cannot have
been the migration of "/tmp" to tmpfs.

If your server could run in the past with "/tmp" as a directory on
"/", it cannot be that setting "RAMTMP=no" in "/etc/default/rcS"
wouldn't solve whatever (hopefully non-philosophical) problem you have
with "/tmp" as a tmpfs mount. You must have a new or upgraded
application that's using "/tmp" differently, or are using the system
differently.

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

Archive: http://lists.debian.org/CAOdo=SwqcWGxJrvY_gjM93QqHV_...@mail.gmail.com

[Roger Leigh]

On Fri, Mar 30, 2012 at 02:12:03PM -0600, Paul E Condon wrote:
> It is my understanding that the directory that one wishes to use in
> TMPDIR must be mentioned in a line in /etc/fstab for this to work, and
> a block special mountable device must be mentioned in that line.

This understanding is incorrect. TMPDIR is just an environment
variable which may be set to any directory of your choice, which
will then be used as the default place to put temporary files.
It does not care about fstab or any other settings.

> And
> this is the way it does work on my system. Choise of TMPDIR did not
> have this restriction in the past. This change has implications for
> many packages.

I sincerely doubt it does work this way on your system. There has
not, and will not be, any change to TMPDIR. Not least of which it
being an application-level feature typically used by functions
opening/creating temporary files, none of which have been changed.
What is or is not mounted on /tmp will not make one jot of
difference.

> My point is that competent developers should check this
> out.

I will be happy to investigate upon better understanding of what
"this" actually is. It will need some concrete information though,
including exact details of how to reproduce any problems, and it
should also show it's something that was working in stable, otherwise
it's not a related issue. I'll need to know what you did, what you
observed and what you expected; currently you haven't provided any
useful information.

Just for the record, when these changes were introduced (nearly a
year ago, BTW), I extensively tested with *all* combinations of
RAMTMP and fstab entries. I made sure they all worked, including
every feature such as overriding the defaults. In all this time, no
one has complained that the logic was broken. (That the defaults
were suboptimal, sure, but not that it did not work.)


There is *no* magic going on here. Read the init scripts to confirm
this for yourself.
mountkernfs.sh:
- if RAMTMP=yes, a tmpfs is mounted on /tmp. The defaults are taken
from /etc/default/tmpfs (or /etc/fstab in preference if an entry
for tmpfs on /tmp exists).
- if RAMTMP=no, we do nothing. Nothing *at all*.
mountall.sh:
- if there's an entry for /tmp in /etc/fstab, it's mounted just like
a regular filesystem. So if RAMTMP was no, and no entry exists in
fstab, nothing will be mounted.

So, as I already mentioned to you in private email last week, which
you appear to have either not read or misunderstood, according to the
continuing discussion here, all you need to do is:
1) Set RAMTMP=no
2) Remove any entries for /tmp from /etc/fstab
and /tmp will just be the same directory on the root filesystem you
had previously.

Other than defaulting to mounting a tmpfs on /tmp, there have been
*no other changes*!! I tend to suspect from this thread that the
problems you are experiencing are entirely self-inflicted, because
they make no logical sense--there's no requirement for a /tmp
entry, and no suggestion of one, and the TMPDIR stuff does not
square with reality.


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-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20120402133...@codelibre.net

[Paul E Condon]

Regret.

Peace.
--
Paul E Condon
peco...@mesanetworks.net

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

Archive: http://lists.debian.org/2012040213...@big.lan.gnu

[Paul E Condon]

Roger,

The possibility that I am hallucinating has occurred to me. I don't
know what I can do to clear my mind. I continue to see my vision. If
what I see is real, others will find it. If real, perhaps it is
hardware dependent. I don't know. I do know that I have nothing
further to give to this discussion. Please accept my inadequacy and
move on. I, of course, with have to learn to live with it, but I will
try very had to be quiet about it in public, and try to speak of it
only to my psychiatrist.

Peace.

--
Paul E Condon
peco...@mesanetworks.net

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

Archive: http://lists.debian.org/2012040214...@big.lan.gnu

[Roger Leigh]

On Mon, Apr 02, 2012 at 08:50:25AM -0600, Paul E Condon wrote:
> On 20120402_143034, Roger Leigh wrote:
> > Other than defaulting to mounting a tmpfs on /tmp, there have been
> > *no other changes*!! I tend to suspect from this thread that the
> > problems you are experiencing are entirely self-inflicted, because
> > they make no logical sense--there's no requirement for a /tmp
> > entry, and no suggestion of one, and the TMPDIR stuff does not
> > square with reality.
>

> The possibility that I am hallucinating has occurred to me. I don't
> know what I can do to clear my mind. I continue to see my vision. If
> what I see is real, others will find it. If real, perhaps it is
> hardware dependent. I don't know. I do know that I have nothing
> further to give to this discussion. Please accept my inadequacy and
> move on. I, of course, with have to learn to live with it, but I will
> try very had to be quiet about it in public, and try to speak of it
> only to my psychiatrist.

Er, what?! There's no need to "learn to live" with any problems.
And as for the comments about hallucinations and psychiatrists,
they add zero value to this discussion. Please just keep it to the
facts. If you want help, provide the information so that we can
help you, otherwise it's entirely worthless--no one, not you, not me
and not anyone on this list is gaining anything from it.

If there are problems, clearly state what they are, and I will do
my best to help. But so far, you've provided no useful information
whatsoever, making it impossible to help you. The comments you
have made do not make sense. They are certainly not true for any
of the systems I've seen unless you've manually changed the init
scripts to behave the way you've described.

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-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20120402155...@codelibre.net

[Camaleón]

On Wed, 28 Mar 2012 16:58:03 -0600, Paul E Condon wrote:

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

As others already have stated, your problem is solved by either:

1. Disabling the usage of "tmpfs" by "/tmp"
aka: "conservative/what-just-works" approach
alias: "take it from the disk, babe"

This is a setting you can easily tweak from "/etc/default/rcS" file by
editing the variable "RAMTMP=no" and this has no additional requirements,
that is, you can have:

1.1 A physical dedicated mount point for "/tmp" in your hard
disk. The size limit here is imposed by the size of the "/tmp"
partition.

1.2 Or you can have no "/tmp" mount point at all in which case
the whole root mount point "/" will be used to hold the data
that need to be placed under "/tmp". The size limit here is
imposed by the size of the whole "/" partition.

2. Enabling the usage of "tmpfs" by "/tmp"
aka: "need for speed/living in the edge" approach
alias: "take it from the RAM, babe"

This is now the default setting which can lead to some problems because
the default value for this parameter is calculated taking into account a
unique variable (the computer's RAM size) and thus setting the size of "/
tmp" as little/much as 20% of its value. This default value can be, of
course, customized by the user so you can adjust the size to be used as
litte/big as you want (though there are also size limits).

Hope now is more clear :-)

Greetings,

--
Camaleón

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

Archive: http://lists.debian.org/jlcl4c$mab$9...@dough.gmane.org

[Paul E Condon]

I made my system work to my liking by *putting*/tmp*into*/etc/fstab*.
It had never been there before, and it was your private message that
prompted me to think of doing that. I wanted to see what malfunction
you were thinking about when the line was there in order to better
communicate about the problem, but it made the system work, not fail
in a different way. I cannot understand how or why this worked, but
the system once worked flawlessly without the line in /etc/fstab, and
now works flawlessly with the line. (In this context, fail means that
sort aborted with an error message saying that it had run out of
scratch space. When it does that, it also takes care to release
all the space that it might have accumulated during the failed run,
ie. it fails gracefully.)

During my tests, I noticed that there was always a line in df,
concerning /tmp in tmpfs. With RAMTMP=yes the line was labeled tmpfs,
but with RAMTMP=no, the line was labeled 'overflow', or something else
that I misremember as overflow. Now I surmise that tmpfs is being used
during boot whatever the setting of RAMTMP, and is not being shut down
correctly towards the end of the boot process after the loader is
capable of reading /etc/defaults/rcS. Of course, it can't be as
simple as that, and of course, I can't really understand, but that's
the best I can come up with. There are reasons why I am not a DD.

I now understand that df just reads /proc and displays what it finds
in 'df' format. I could have looked at /proc, I suppose, but at the
time that I was testing I didn't really know where or how 'df' got the
information, and I definitely didn't know where to look in /proc, if I
had thought to verify the 'df' output by checking it against /proc.

If this phenomena cannot be replicated by anyone else then it surely
should not be investigated by anyone in the Debian establishment. The
box is about twelve years old. It was purchased as a grey box from
Frys in California back in the days when the grocery store was still a
active part of the business. I had always found it to be compatible
with Debian, before, but it certainly doesn't seem compatible with
peace in the Debian community, now.

Have I become confused by the not understanding the distinction between
'yes' and 'no'? What other explanation? It flat out doesn't happen the
way you describe.

Suggestions for me to gather information to help work the issue?
I'll try.
Would you believe my reports? I am well known as having
hallucinations. It's in the Debian archives.

--
Paul E Condon
peco...@mesanetworks.net

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

Archive: http://lists.debian.org/2012040217...@big.lan.gnu

[Roger Leigh]

On Mon, Apr 02, 2012 at 11:55:02AM -0600, Paul E Condon wrote:
> During my tests, I noticed that there was always a line in df,
> concerning /tmp in tmpfs. With RAMTMP=yes the line was labeled tmpfs,
> but with RAMTMP=no, the line was labeled 'overflow', or something else
> that I misremember as overflow. Now I surmise that tmpfs is being used
> during boot whatever the setting of RAMTMP, and is not being shut down
> correctly towards the end of the boot process after the loader is
> capable of reading /etc/defaults/rcS. Of course, it can't be as
> simple as that, and of course, I can't really understand, but that's
> the best I can come up with. There are reasons why I am not a DD.

Have a look at /etc/init.d/mountoverflowtmp.

Your root filesystem is full. This triggers the mounting of a
tmpfs on /tmp *irrespective* of the RAMTMP option, in order to
allow you to log in.

Solution: free up some space on your root filesystem, and all
will return to normal. Mounting a filesystem on /tmp would have
solved this specific problem by making more than a megabyte of
free space available, which would avoid triggering this condition.

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-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20120402205...@codelibre.net

[Andrei POPESCU]

[hope you don't mind the CC, but I figured you don't follow debian-user
very closely]

On Lu, 02 apr 12, 21:56:20, Roger Leigh wrote:
>
> Have a look at /etc/init.d/mountoverflowtmp.
>
> Your root filesystem is full. This triggers the mounting of a
> tmpfs on /tmp *irrespective* of the RAMTMP option, in order to
> allow you to log in.

Interesting, where can I read more about it? I already checked
README.Debian for binary package initscripts.

(i.e. is it Debian specific, when was it introduced, what are the
"symptoms", etc.)

[Roger Leigh]

On Tue, Apr 03, 2012 at 12:26:21AM +0300, Andrei POPESCU wrote:
> [hope you don't mind the CC, but I figured you don't follow debian-user
> very closely]

No worries, but I am a subscriber.

> On Lu, 02 apr 12, 21:56:20, Roger Leigh wrote:
> >
> > Have a look at /etc/init.d/mountoverflowtmp.
> >
> > Your root filesystem is full. This triggers the mounting of a
> > tmpfs on /tmp *irrespective* of the RAMTMP option, in order to
> > allow you to log in.
>
> Interesting, where can I read more about it? I already checked
> README.Debian for binary package initscripts.
>
> (i.e. is it Debian specific, when was it introduced, what are the
> "symptoms", etc.)

It's just the script, AFAICT. It issues a warning at boot if it's
ever used. Looking at the logs, it's been around since at least
2007. It's not specifically documented anywhere.

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-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20120402224...@codelibre.net

[Paul E Condon]

On 20120402_215620, Roger Leigh wrote:
> On Mon, Apr 02, 2012 at 11:55:02AM -0600, Paul E Condon wrote:
> > During my tests, I noticed that there was always a line in df,
> > concerning /tmp in tmpfs. With RAMTMP=yes the line was labeled tmpfs,
> > but with RAMTMP=no, the line was labeled 'overflow', or something else
> > that I misremember as overflow. Now I surmise that tmpfs is being used
> > during boot whatever the setting of RAMTMP, and is not being shut down
> > correctly towards the end of the boot process after the loader is
> > capable of reading /etc/defaults/rcS. Of course, it can't be as
> > simple as that, and of course, I can't really understand, but that's
> > the best I can come up with. There are reasons why I am not a DD.
>
> Have a look at /etc/init.d/mountoverflowtmp.
>
> Your root filesystem is full. This triggers the mounting of a
> tmpfs on /tmp *irrespective* of the RAMTMP option, in order to
> allow you to log in.
>
> Solution: free up some space on your root filesystem, and all
> will return to normal. Mounting a filesystem on /tmp would have
> solved this specific problem by making more than a megabyte of
> free space available, which would avoid triggering this condition.
>
>
> Regards,
> Roger

Roger,

Many thanks for being so patient with me. df does say the disk
is full, but please read further.

My root filesystem disk is a nominal 60GB partition on an 80GB HD.
Other partitions are 2ea ext3 partitions of 19GB and one swap
partition for the rest of the 80GB. (All partitions (except swap)
are ext3 on all my disks.)

As I say, df says it is full. But du -k -s -c says there slightly
less than 3.74GB of data on the whole disk. Removing some data
from the root filesystem can be done but before I do that I would
like to understand what is occupying 15/16ths of the disk, and how to
remove that and how to keep it from coming back. I think it is
very very unlikely that tmpfs is to blame, but I ask your help because
you have gotten me this far, and you already know how difficult I can
be but nevertheless persist in helping me. What should I do?

This is the ls of the root file system:

root@gq:/# ls -l /
total 116
drwxr-xr-x 2 root root 4096 20120326_175618 bin
drwxr-xr-x 3 root root 4096 20120325_095914 boot
drwxr-xr-x 13 root root 3360 20120402_162358 dev
drwxr-xr-x 137 root root 12288 20120402_163817 etc
drwxr-xr-x 2 root root 4096 20120402_164014 home
lrwxrwxrwx 1 root root 32 20120313_070235 initrd.img -> /boot/initrd.img-3.2.0-2-686-pae
lrwxrwxrwx 1 root root 32 20120216_114920 initrd.img.old -> /boot/initrd.img-3.2.0-1-686-pae
drwxr-xr-x 17 root root 12288 20120326_175618 lib
drwx------ 2 root root 16384 20110611_113359 lost+found
drwxr-xr-x 12 root root 4096 20120328_040453 media
drwxr-xr-x 2 root root 4096 20120328_034547 mnt
drwxr-xr-x 3 root root 4096 20110611_113408 mpa2
drwxr-xr-x 3 root root 4096 20110611_113416 mpa3
drwxr-xr-x 2 root root 4096 20110611_113426 mpb1
drwxr-xr-x 4 root root 4096 20120402_164008 mpb2
drwxr-xr-x 2 root root 4096 20110611_113530 opt
dr-xr-xr-x 90 root root 0 20120402_161618 proc
drwx------ 9 root root 4096 20120402_163817 root
drwxr-xr-x 16 root root 780 20120402_161710 run
drwxr-xr-x 2 root root 12288 20120326_175619 sbin
drwxr-xr-x 2 root root 4096 20110504_055428 selinux
drwxr-xr-x 2 root root 4096 20110611_113530 srv
drwxr-xr-x 13 root root 0 20120402_161619 sys
drwxr-xr-x 3 root root 4096 20120402_171701 tmp
drwxr-xr-x 10 root root 4096 20110611_113530 usr
drwxr-xr-x 12 root root 4096 20120203_162430 var
lrwxrwxrwx 1 root root 28 20120313_070235 vmlinuz -> boot/vmlinuz-3.2.0-2-686-pae
lrwxrwxrwx 1 root root 28 20120216_114920 vmlinuz.old -> boot/vmlinuz-3.2.0-1-686-pae
root@gq:/#

This is the du command and results:
root@gq:/# du -k -s -c /[^pm]* /m[^e]*
7172 /bin
18420 /boot
0 /dev
8556 /etc
4 /home
0 /initrd.img
0 /initrd.img.old
202628 /lib
16 /lost+found
4 /opt
1200 /root
668 /run
7576 /sbin
4 /selinux
4 /srv
0 /sys
20 /tmp
2873144 /usr
508676 /var
0 /vmlinuz
0 /vmlinuz.old
4 /mnt
20 /mpa2
20 /mpa3
4 /mpb1
111516 /mpb2
3739656 total
root@gq:/#

The tricky file argument in the command keeps du from including /media
and /proc in the total file space count but picks up space from
everything else in /. At the time this was done I had already moved
the contents of /home into the directory /mpb2. I could have moved it
back, but I wanted to compose this letter and send as a higher
priority task. /mpa2 and /mpa3 are the second and third partitions of
the HD that holds the root partition. Xwindows is not installed. I
access this computer via ssh from another, newer computer running Squeeze.

My experience is that under 4GB is about the right size for a Debian
installation when loaded with the packages that I like to have, but
maybe I have been doing something terribly wrong for a long time. I
really don't know what the size should be in terms of the general
experience of other Debian users. I've never been to an installfest,
etc.

Why the disagreement between df and du ? How is it possible?
I could swap the two disks on the system and have the 250GB HD be
the root file system. But it would probably become filled up to its
capacity with me being no closer to understanding how I might keep
the fill-up from happening again.

Here is the actual output of df:

root@gq:/# df
Filesystem 1K-blocks Used Available Use% Mounted on
rootfs 56710460 54282104 0 100% /
udev 580720 0 580720 0% /dev
tmpfs 116424 668 115756 1% /run
/dev/disk/by-uuid/bdef667c-a248-4cb7-b509-943e28fe0f8f 56710460 54282104 0 100% /
tmpfs 5120 0 5120 0% /run/lock
tmpfs 232844 0 232844 0% /run/shm
/dev/sda2 9612516 152684 8971540 2% /mpa2
/dev/sda3 9612516 152684 8971540 2% /mpa3
/dev/sdb1 57677500 184268 54563380 1% /tmp
/dev/sdb2 182687364 303444 173103848 1% /mpb2
root@gq:/#

If you know what's wrong, please tell me. If you want more information please ask. I need help.
--
Paul E Condon
peco...@mesanetworks.net

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

Archive: http://lists.debian.org/2012040302...@big.lan.gnu

[Stan Hoeppner]

On 4/2/2012 9:43 PM, Paul E Condon wrote:

> This is the du command and results:
> root@gq:/# du -k -s -c /[^pm]* /m[^e]*

> 4 /home

Is your /home empty? Your du command seems to think so. That's hard to
believe. It would mean you ever created any users. A newly created
empty dir has a size of 4KB.

> 0 /initrd.img
> 0 /initrd.img.old
> 0 /vmlinuz
> 0 /vmlinuz.old

How are these files occupying 0 KB of disk?

> 20 /mpa2
> 20 /mpa3
> 4 /mpb1

Do these 3 dirs you created really only contain 44 KB total?

> Why the disagreement between df and du ? How is it possible?

See the discrepancies above? Your du isn't reflecting reality of what's
on disk. And the issue isn't sparse files as that would cause du to
show you're full but df would say you have tons of actual on disk free
space.

It seems clear that your ext3 / filesystem is actually full. You are
actually using 54282104 blocks. Go through your directories manually to
find the files that are eating up that other 15/16ths of your partition.
Given the space in question, I'd say you may likely have some
downloaded ISOs, or other large files, probably in your /home/paul/
directory.

--
Stan

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

Archive: http://lists.debian.org/4F7A8072...@hardwarefreak.com

[Paul E Condon]

On 20120402_234538, Stan Hoeppner wrote:
> On 4/2/2012 9:43 PM, Paul E Condon wrote:
>
> > This is the du command and results:
> > root@gq:/# du -k -s -c /[^pm]* /m[^e]*
>
> > 4 /home
>
> Is your /home empty? Your du command seems to think so. That's hard to

Yes. It was empty at the time at which the du command was run. The
normal contents of /home had been moved to /mpb2. I say where the
/home stuff is in the post to which you replied. When I did the move,
I had no idea that I was going to find this puzzle, but I do recall
thinking that the move went very fast, too fast for there to be much
data in /home.

> believe. It would mean you ever created any users. A newly created
> empty dir has a size of 4KB.

At 4KB per extra user, it would take over 12000 extra users to account
for the missing extra space. I don't think I could have created that
many users and not remember. And I don't remember doing such a wild
thing. And the directories are not there. So I probably didn't do it.
And if they were there, du would have found them and counted them.

>
> > 0 /initrd.img
> > 0 /initrd.img.old
> > 0 /vmlinuz
> > 0 /vmlinuz.old
>
> How are these files occupying 0 KB of disk?

That is part of my problem. The disk seems to be corrupted.

>
> > 20 /mpa2
> > 20 /mpa3
> > 4 /mpb1
>
> Do these 3 dirs you created really only contain 44 KB total?
>
> > Why the disagreement between df and du ? How is it possible?
>
> See the discrepancies above? Your du isn't reflecting reality of what's

Yes, I see them. I made my post because I saw them and wanted help in
explaining them. But how can you conclude that it is du that is wrong?

> on disk. And the issue isn't sparse files as that would cause du to
> show you're full but df would say you have tons of actual on disk free
> space.
>
> It seems clear that your ext3 / filesystem is actually full. You are

All the numbers from du are consistent with my memory of what was on the
disks. A lot of empty space. Only the disk full indication from df is
surprising to me. It is an 80GB disk with Wheezy and no Xwindows or Gnome
on it, and only a skeleton /home. Clearly the info from df and du are
incompatible. Could you explain why you conclude it is du that is wrong?
It is a Wheezy root disk, which in my experience should contain no more
than 5 or 6 GB in my experience.

> actually using 54282104 blocks. Go through your directories manually to
> find the files that are eating up that other 15/16ths of your partition.

Isn't that what du automates? Traversing a directory tree and tallying
the space used. Before this experience I would have trusted running du
far more than any manual operation that I performed. If 15 parts out 16
is stuff that shouldn't be there, I would expect a random peek would
have high probability of seeing the bad stuff immediately. But no,
I don't see anything but stuff that is on pretty much any Debian box.

> Given the space in question, I'd say you may likely have some
> downloaded ISOs, or other large files, probably in your /home/paul/
> directory.

I am quite certain that I have never downloaded .ISOs onto this computer.
I have been using this computer for development and data processing. I burn my CDs
on a different computer. I know how I organize my /home on any computer.
On this computer, the place where I normally put large files is unpopulate,
or, perhaps hidden from view by some strange malfunction. But do you actually
see in what I presented, a reason for choosing to believe the df display and
not believe the du display. What reasoning did you go thru? I'm trying to
learn. And I need help on this.

But just because I'm sure I haven't put large files on this disk,
don't conclude that I have refused to look for them. Because of your
comments, I have looked again. I see nothing that is amiss. Except, of
course, the two programs, df and du don't agree. I suppose I could just
wipe the disk and start over. But I don't want to do that. I'd like to
understand what went wrong so that maybe I can avoid it in future.

Thanks for your comments.

--
Paul E Condon
peco...@mesanetworks.net

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

Archive: http://lists.debian.org/20120403080...@big.lan.gnu

[Dom]

On 03/04/12 09:08, Paul E Condon wrote:
> On 20120402_234538, Stan Hoeppner wrote:
>> On 4/2/2012 9:43 PM, Paul E Condon wrote:
>>
>>> This is the du command and results:
>>> root@gq:/# du -k -s -c /[^pm]* /m[^e]*
>>
>>> 4 /home
>>
>> Is your /home empty? Your du command seems to think so. That's hard to
>
> Yes. It was empty at the time at which the du command was run. The
> normal contents of /home had been moved to /mpb2. I say where the
> /home stuff is in the post to which you replied. When I did the move,
> I had no idea that I was going to find this puzzle, but I do recall
> thinking that the move went very fast, too fast for there to be much
> data in /home.

Did the data move over correctly? I'm just wondering if it is still on
the original disk somewhere, like in the /mpb2 directory before the new
filesystem was mounted over it.

I'd try bringing the system up in recovery mode, unmount all ext3 file
systems (except /, obviously) and run the du command again. You might
find data that was concealed under the mount points.

>>
>>> 0 /initrd.img
>>> 0 /initrd.img.old
>>> 0 /vmlinuz
>>> 0 /vmlinuz.old
>>
>> How are these files occupying 0 KB of disk?
>
> That is part of my problem. The disk seems to be corrupted.

No. This is normal and the correct behaviour. Those files are symlinks
to the real files and take no space other than a single directory entry
each.

>
>>
>>> 20 /mpa2
>>> 20 /mpa3
>>> 4 /mpb1
>>
>> Do these 3 dirs you created really only contain 44 KB total?
>>
>>> Why the disagreement between df and du ? How is it possible?
>>
>> See the discrepancies above? Your du isn't reflecting reality of what's
>
> Yes, I see them. I made my post because I saw them and wanted help in
> explaining them. But how can you conclude that it is du that is wrong?

I suspect it isn't. It isn't showing files because it can't get to them.
So my suggestion above.

Regards.
--
Dom

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

Archive: http://lists.debian.org/4F7ABBFB...@rpdom.net

[Roger Leigh]

On Tue, Apr 03, 2012 at 09:59:39AM +0100, Dom wrote:
> I'd try bringing the system up in recovery mode, unmount all ext3
> file systems (except /, obviously) and run the du command again. You
> might find data that was concealed under the mount points.

It's even possible that it's under /tmp.

--
.''`. 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-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20120403091...@codelibre.net

[Vincent Lefevre]

On 2012-03-24 11:00:49 -0600, Javier Vasquez wrote:
> You can always configure as you wish. Take a look at:
>
> /etc/default/tmpfs

The file says:

# NOTE: This file is deprecated. Please see rcS(5) for details on how
# to configure tmpfs size limits.

--
Vincent Lefèvre <vin...@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

Archive: http://lists.debian.org/2012040309...@xvii.vinc17.org

[Roger Leigh]

On Tue, Apr 03, 2012 at 11:16:08AM +0200, Vincent Lefevre wrote:
> On 2012-03-24 11:00:49 -0600, Javier Vasquez wrote:
> > You can always configure as you wish. Take a look at:
> >
> > /etc/default/tmpfs
>
> The file says:
>
> # NOTE: This file is deprecated. Please see rcS(5) for details on how
> # to configure tmpfs size limits.

It's still perfectly fine to use this file. The only reason
it's deprecated is that there's now a better way to define
limits (just add an entry to /etc/fstab like for any other
filesystem). But if you want to use it, feel free. As and
when it is obsoleted, we'll automatically create fstab
entries for you (should we decide to do that). The advantage
of the fstab method is that it's compatible with all other
init systems.


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-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20120403094...@codelibre.net

[Roger Leigh]

On Sat, Mar 24, 2012 at 06:00:23PM -0300, Henrique de Moraes Holschuh wrote:
> On Sat, 24 Mar 2012, Joey Hess wrote:
> > Edit /etc/default/rcS, set RAMTMP=no, reboot. Or, set TMPDIR to point to
> > something like $HOME/tmp
>
> You don't need to reboot because of the size change.
>
> "mount -o remount,size=<desired size> /tmp" works, at least for
> increasing size. One of the good things of a tmpfs is that you can
> resize it dynamically.
>
> > 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.
>
> Hmm, yes, it can certaily be raised by popular demand. But what would
> probably help more is a set of profiles of /tmp sizes based on the
> amount of system ram to provide the initial default size.

I noticed yesterday that Fedora is planning to go for using
tmpfs on /tmp as well.

http://www.phoronix.com/scan.php?page=news_item&px=MTA4MTg

http://fedoraproject.org/wiki/Features/tmp-on-tmpfs

Note that the latter has useful advice and notes in the Q&A
section which does pertain to the problems discussed in this
thread. It's clear that some of the problems will be fixed
as they are additionally found in Fedora, particularly WRT
the storage of large files on /tmp. It also notes that a
number of other distributions are also picking this up as
well, e.g. Ubuntu and Arch, so we are by no means alone in
implementing this.

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-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20120403101...@codelibre.net

[Vincent Lefevre]

On 2012-03-25 10:51:07 +0000, Camaleón wrote:
> 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)

Thanks, but not all users want to spend all their time reading long
threads. Shouldn't there be something in the Debian FAQ and/or wiki
(I couldn't find anything) in order to have a common resource for
such information?

--
Vincent Lefèvre <vin...@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

Archive: http://lists.debian.org/2012040310...@xvii.vinc17.org

[Vincent Lefevre]

On 2012-03-27 14:13:23 +0100, Roger Leigh wrote:
> 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.

What do you mean by "abused"? If it is limitless, there should be
no possible abuse.

IMHO, to avoid breakage due to limited space and due to some user
taking all the space, there should be some compromise, such as:
for any memory storage system (RAM+swap, tmpfs, disk...), there
should be some space normally not used, and reserved for root (and
possibly special system users/groups[*]) in case the normal space
gets filled. AFAIK, this is already the case for disk space.

[*] or arbitrary users, who could have their own reserved space to
be able to do minimal work when some other user took all the space
(i.e. a common pool that has the precedence + quotas on extra pools,
which would be much smaller).

> - /var/tmp exists, and should be used in many of the cases where
> /tmp is being filled.

But what is applications do not know in advance what to use, given
the fact that the RAM+swap is much more limited than disk space in
practice? Should there be a new FS to transparently use tmpfs for
small files and disk space (/var/tmp or similar) for large files,
and being able to move files from tmpfs to disk space when a file
increases (without changing the pathname)?

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

I have scripts that build and test software, and rm -rf everything
after the tests and/or "make install". So, I was using /tmp for that
(because it is faster than normal disk space, and cleaned-up at boot
time in case something is left over). For small software, it is OK,
but for large ones, /tmp got full. Should I use /var/tmp, even though
/tmp would be OK in most cases? IMHO, the best solution would be some
"union" FS as suggested above.

> What is the minimum space an individual user or application should
> be able to use?

IMHO, the default limit should be the full space minus some small
space to avoid breakage. This is more flexible than strict quotas.

> Should certain applications be patched not to use /tmp for
> storing "excessively large" files?

The problem is that /tmp would be OK for some users and not for
other users, in particular if the applications don't know in
advance the amount of data they will need to store temporarily.

If the answer is "in doubt, do not use /tmp" (possibly affecting
most applications), then this would probably mean that /tmp should
not use tmpfs.

--
Vincent Lefèvre <vin...@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


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

Archive: http://lists.debian.org/2012040311...@xvii.vinc17.org

[Vincent Lefevre]

On 2012-03-28 18:32:25 +0100, Roger Leigh wrote:
> 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.

FYI, Firefox/Iceweasel uses /tmp for that. For instance, click on
a link to a PDF file to view it with a PDF viewer; the file is
stored in /tmp. It isn't even removed after the application is
closed (quitting Iceweasel has the effect to remove it, but the
browser can run for several days/weeks).

[Vincent Lefevre]

On 2012-03-28 19:12:27 +0100, Brian wrote:
> But defaults are defaults. Files in /etc/default can be altered.

This is OK for system-wide settings, such as:

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

but /tmp is used by end users, who may have different needs, even
if they use the same applications. What if some user wants tmpfs
while some other user (on the same machine) prefers a large /tmp
size? If this can't be determined at the user-level side, there
should be at least some documentation to describe what can be done
with /tmp and what shouldn't be.

[Claudius Hubig]

Hello Vincent,

Vincent Lefevre <vin...@vinc17.net> wrote:
> On 2012-03-28 18:32:25 +0100, Roger Leigh wrote:
> FYI, Firefox/Iceweasel uses /tmp for that. For instance, click on
> a link to a PDF file to view it with a PDF viewer; the file is
> stored in /tmp. It isn't even removed after the application is
> closed (quitting Iceweasel has the effect to remove it, but the
> browser can run for several days/weeks).

And they happily obey TMPDIR if set, so that each user on a machine
(you brought that problem up in your other post) can redirect it
whereever he wants.

Best regards,

Claudius

--
Linux - Where do you want to fly today?
-- Unknown source
Please use GPG: ECB0C2C7 4A4C4046 446ADF86 C08112E5 D72CDBA4
http://chubig.net telnet://nightfall.org:4242

[Vincent Lefevre]

On 2012-04-03 13:54:55 +0200, Claudius Hubig wrote:
> Vincent Lefevre <vin...@vinc17.net> wrote:
> > On 2012-03-28 18:32:25 +0100, Roger Leigh wrote:
> > FYI, Firefox/Iceweasel uses /tmp for that. For instance, click on
> > a link to a PDF file to view it with a PDF viewer; the file is
> > stored in /tmp. It isn't even removed after the application is
> > closed (quitting Iceweasel has the effect to remove it, but the
> > browser can run for several days/weeks).
>
> And they happily obey TMPDIR if set, so that each user on a machine
> (you brought that problem up in your other post) can redirect it
> whereever he wants.

which is bad for the following reason. One has /tmp and /var/tmp
with a different usage:
* /tmp: guaranteed to be fast, but may be very limited in size.
And it can (and often will) be clean-up at boot time.
* /var/tmp: should have enough space (in practice not less than
/tmp), but may be significantly slower than /tmp, and files
survive reboots.
So, depending on what an application will do and will expect, it
should choose /tmp or /var/tmp, certainly not obey $TMPDIR, for
which the application doesn't know anything about it. Well, $TMPDIR
is good for libraries, to be controlled by applications, but not if
one has specific requirements. Applications can also have config
files, but not all of them do for the storage location of temporary
data.

Examples:
* A mail message that is being composed: the temporary file should
not be stored in /tmp, because in case of sudden power loss (this
unfortunately happens), system crash or reboot, the work is lost!
That's why I now have "set tmpdir=/var/tmp" in my .muttrc, after
losing several messages I was writing.
* Files temporarily stored by a web browser should also be in
/var/tmp, possibly except if they are very small.
* For GCC, /tmp should normally be used for speed reason.

The idea of everything being set up by an environment variable
(which is inherited) is a bad thing. For instance, if the tmpdir
Mutt variable didn't exist, I would have to set TMPDIR=/var/tmp;
but one can execute shell commands from Mutt, e.g. a compilation
(probably not the best example, but well...), and GCC would have
then be executed with TMPDIR=/var/tmp, making it artificially
slower.

Similarly, scripts that build large software and use mktemp should
specify the temporary directory explicitly instead of setting
TMPDIR globally, because one may still want GCC to use /tmp for
its temporary files.

--
Vincent Lefèvre <vin...@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


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

Archive: http://lists.debian.org/2012040313...@xvii.vinc17.org

[Camaleón]

On Tue, 03 Apr 2012 12:31:57 +0200, Vincent Lefevre wrote:

> On 2012-03-25 10:51:07 +0000, Camaleón wrote:
>> 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)
>
> Thanks, but not all users want to spend all their time reading long
> threads.

Neither I do.

This was my reply to Javier who pointed out he was missing the messages
so I provided a direct link to him in the event he wanted to review them.

> Shouldn't there be something in the Debian FAQ and/or wiki (I couldn't
> find anything) in order to have a common resource for such information?

Agree, this will be very useful for telling users where to look when they
experience a problem with this >:-)

I think I have an account for the wiki but I can't redact a full article
about this matter (I know my limits and this goes beyond them). If
someone has something in mind is his/her knowledge on this is good enough
to make a first sketch, I will be glad to create the wiki page.

Greetings,

--
Camaleón

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

Archive: http://lists.debian.org/jlevf7$8qv$5...@dough.gmane.org

[Paul E Condon]

On 20120403_101348, Roger Leigh wrote:
> On Tue, Apr 03, 2012 at 09:59:39AM +0100, Dom wrote:
> > I'd try bringing the system up in recovery mode, unmount all ext3
> > file systems (except /, obviously) and run the du command again. You
> > might find data that was concealed under the mount points.
>
> It's even possible that it's under /tmp.

Some issues with some suggestions:

1) If the data is actually there, it is obviously on my rootfs (/) which
I obviously can't examine in recovery mode. Or can I examine it by some
trickery that someone will tell about?

2) I used mv to move the data, from past experience I judged the execution
time of mv to be consistent with the same about of data the showed up on
/mpb2 according to du.

3) Stan says that the disk is full and that du is just wrong. I say that
'obviously' the outputs of df and du disagree, and with the possibility
of there being some corruption of magnetic marks of disk, it is difficult
to say which report is closer to the truth. How does one decide? Beyond
choosing the one that better fits ones expectations and desires? (wishful
thinking)

4) I started making proparations to wipe and reinstall on the problem computer.
To do that I was working on an entirely different computer (the one on which I
read my mail). I wanted to clean up some partitioning there. This other computer
is running Squeeze. I installed kpartx, tried to use it, and got a real surprise:

root@big:~# kpartx -l /dev/sda
/proc/misc: No entry for device-mapper found
Is device-mapper driver missing from kernel?
Failure to communicate with kernel device-mapper driver.
sda1 : 0 39061504 /dev/sda 2048
sda2 : 0 39061504 /dev/sda 39063552
sda4 : 0 894738434 /dev/sda 82032638
sda5 : 0 894738432 /dev/dm-2 2
root@big:~#

I have never thought about the question being ask in the error message.
I have no idea what the 'good' answer should be for a Debian built
kernel. I do have backups of all my data and highish speed access to
the internet. Perhaps I should take a deep breath and reinstall all three
of my computers. This course of action will take a long time, and it will
keep me from asking (or answering) questions on this list for a long time.

Is device-mapper driver a standard part of all Debian kernels? Is df
really more to be trusted than du when used on a disk that could have
become corrupted? The original problem computer continues to limp
along. It doesn't issue error messages. But that is hardly a reason
for believing it is all OK. As I understand du, it works by walking
the directory tree and tallying the space used by all the objects that
it finds. The -s option only affects how verbose it is in reporting
what it has found. In other words, if du doesn't find something on a
disk, why should one search manually and expect to find something that
it missed. Maybe I should look for something that absolutely should
not be there and is a clue about what made the disk 'go south'?


Advice?
Comment?
Thanks for reading this.

--
Paul E Condon
peco...@mesanetworks.net

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

Archive: http://lists.debian.org/20120403181...@big.lan.gnu

[Stan Hoeppner]

On 4/3/2012 1:18 PM, Paul E Condon wrote:

> 3) Stan says that the disk is full and that du is just wrong.

That's not actually what I said. There is a subtle but distinct difference:

Me: "Your du isn't reflecting reality of what's
on disk."

"Your du" implies both the exact command line w/switches you're
executing and du itself, not just du. Did you ever drop caches as I
recommended? Sometimes the in memory inode and extent maps don't match
what's on disk. So it's possible df isn't reporting used blocks
correctly, which is why I instructed you to drop caches, 'least I think
I did.

$ echo 3 > /proc/sys/vm/drop_caches

then run df and du.

Keep in mind I don't have knowledge of what all you've done to those
filesystems and when, what may have gone wrong, if anything, etc.
Neither does anyone else here but you. So it may take a while to figure
out what the problem is.

--
Stan

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

Archive: http://lists.debian.org/4F7B42C6...@hardwarefreak.com

[Bob Proulx]

Paul E Condon wrote:

> Roger Leigh wrote:
> > Dom wrote:
> > > I'd try bringing the system up in recovery mode, unmount all ext3
> > > file systems (except /, obviously) and run the du command again. You
> > > might find data that was concealed under the mount points.
> >
> > It's even possible that it's under /tmp.
>
> Some issues with some suggestions:
>
> 1) If the data is actually there, it is obviously on my rootfs (/) which
> I obviously can't examine in recovery mode. Or can I examine it by some
> trickery that someone will tell about?

There is no trickery. The root filesystem is plainly available when
booted into recovery mode. Simply run the du commands there.

Why do you think it needs trickery?

> 2) I used mv to move the data, from past experience I judged the execution
> time of mv to be consistent with the same about of data the showed up on
> /mpb2 according to du.

You used 'mv' to move what data? I looked through your previous
postings but don't see any background on this. You are moving data?
What data?

> 4) I started making proparations to wipe and reinstall on the
> problem computer. To do that I was working on an entirely different
> computer (the one on which I read my mail). I wanted to clean up
> some partitioning there. This other computer is running Squeeze. I
> installed kpartx, tried to use it, and got a real surprise:
>
> root@big:~# kpartx -l /dev/sda

Stop! Proceed no further.

What are you trying to do here? Why are you using kpartx here?

What does the kernel say about your partitions:

cat /proc/partitions

> /proc/misc: No entry for device-mapper found
> Is device-mapper driver missing from kernel?
> Failure to communicate with kernel device-mapper driver.
> sda1 : 0 39061504 /dev/sda 2048
> sda2 : 0 39061504 /dev/sda 39063552
> sda4 : 0 894738434 /dev/sda 82032638
> sda5 : 0 894738432 /dev/dm-2 2
> root@big:~#

All pretty much expected. What did you expect? The above is
*exactly* what I would expect to see.

But why are you trying to use kpartx on /dev/sda here? Stop! You are
off lost in the woods. Stay on the trail. (I could explain the
various uses of kpartx but I don't think it would help so will refrain.)

> the internet. Perhaps I should take a deep breath and reinstall all three
> of my computers. This course of action will take a long time, and it will
> keep me from asking (or answering) questions on this list for a long time.

Oh, don't tease us so! :-)

> Is device-mapper driver a standard part of all Debian kernels?

It is a kernel module. Modules are only loaded if you need them. You
don't need this one and so it hasn't been loaded.

> Is df really more to be trusted than du when used on a disk that
> could have become corrupted?

If you suspect disk corruption here (I don't, I think it is fine) then
run fsck on the filesystem.

> As I understand du, it works by walking the directory tree and
> tallying the space used by all the objects that it finds. The -s
> option only affects how verbose it is in reporting what it has
> found. In other words, if du doesn't find something on a disk, why
> should one search manually and expect to find something that it
> missed. Maybe I should look for something that absolutely should not
> be there and is a clue about what made the disk 'go south'?

There are many reasons for disk space to be visible in one context and
invisible in another context. That isn't unusual at all.

Any disk space under a mounted filesystem is invisible. But it is
still used disk space. This can happen when /tmp is used for lots of
files and disk space but then another /tmp is mounted on top of it.
This additional one covers up the one below it.

Any files that have been written to but have been unlinked from the
directory will consume space but be invisible. This often happens
with log files. A program writes a log file. It writes a lot of data
to the log file. A person sees that and thinks, I will remove the
file. That is the worst possible thing to do. Having removed the
file from the directory the program is still writing to it. Therefore
the disk space used by it is still used by it. The space will only be
freed up when the program writing to it is killed. This is all due to
the filesystem using reference counting. The file is only freed when
all of the file handles to it are reduced to zero. As long as at
least one file handle points to the file then it cannot be freed.

By reading your messages I think either of these two reasons are very
likely.

Bob

[Andrei POPESCU]

On Ma, 03 apr 12, 12:31:57, Vincent Lefevre wrote:
>
> Thanks, but not all users want to spend all their time reading long
> threads. Shouldn't there be something in the Debian FAQ and/or wiki
> (I couldn't find anything) in order to have a common resource for
> such information?

I'm quite certain that it will be documented in the Release Notes, but
the feature is not frozen yet. A wiki page for the wheeze and sid users
might be useful, as long as it is kept up-to-date and later moved to the
apropiate document.

[Andrei POPESCU]

On Ma, 03 apr 12, 10:13:48, Roger Leigh wrote:
> On Tue, Apr 03, 2012 at 09:59:39AM +0100, Dom wrote:
> > I'd try bringing the system up in recovery mode, unmount all ext3
> > file systems (except /, obviously) and run the du command again. You
> > might find data that was concealed under the mount points.
>
> It's even possible that it's under /tmp.

This possibility should eventually make its way in the Release Notes,
unless you do a 'mv /tmp /tmp-old && mkdir /tmp' on upgrade.

[Roger Leigh]

On Wed, Apr 04, 2012 at 11:25:40AM +0300, Andrei POPESCU wrote:
> On Ma, 03 apr 12, 10:13:48, Roger Leigh wrote:
> > On Tue, Apr 03, 2012 at 09:59:39AM +0100, Dom wrote:
> > > I'd try bringing the system up in recovery mode, unmount all ext3
> > > file systems (except /, obviously) and run the du command again. You
> > > might find data that was concealed under the mount points.
> >
> > It's even possible that it's under /tmp.
>
> This possibility should eventually make its way in the Release Notes,
> unless you do a 'mv /tmp /tmp-old && mkdir /tmp' on upgrade.

It would normally be cleaned on boot anyway, so I think we can
avoid putting this in the Release Notes if we clean it automatically.
I'm thinking it would probably be best if we delay mounting tmpfs on
/tmp until after this has been done. And also unifying the
overflowtmp logic since unless you look at the boot failures
carefully, it's not clear why this happens.


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-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20120404083...@codelibre.net

[Andrei POPESCU]

On Mi, 04 apr 12, 09:38:44, Roger Leigh wrote:
>
> It would normally be cleaned on boot anyway, so I think we can
> avoid putting this in the Release Notes if we clean it automatically.

Isn't this dangerous? (It's unclear to me if /tmp is cleaned in squeeze
by default or not)

> I'm thinking it would probably be best if we delay mounting tmpfs on
> /tmp until after this has been done. And also unifying the
> overflowtmp logic since unless you look at the boot failures
> carefully, it's not clear why this happens.

+1 for the overflowtmp. It's a nice safety mechanism, but given that
it's not known and/or documented it may create more havoc than good.

[Roger Leigh]

On Wed, Apr 04, 2012 at 12:14:43PM +0300, Andrei POPESCU wrote:
> On Mi, 04 apr 12, 09:38:44, Roger Leigh wrote:
> >
> > It would normally be cleaned on boot anyway, so I think we can
> > avoid putting this in the Release Notes if we clean it automatically.
>
> Isn't this dangerous? (It's unclear to me if /tmp is cleaned in squeeze
> by default or not)

It is, along with /var/run and /var/lock. See
/etc/init.d/mountall-bootclean.sh and /lib/init/bootclean.sh.

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-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20120404093...@codelibre.net