2012/5/27 Adam Borowski wrote:

> First, you're benchmarking the speed of process creation, not of file
> operations. Starting up seq or mv takes ages compared to an in-memory
> file write.

They may be slower than in-memory operations, but they're definitely
faster than fsync(). So if there was fsync() there would have been a
noticeable difference in time. But there were no difference. So there
were no fsync(). And my HDD was not blinking during that test as well.

> Then, pray tell, where exactly do your tests include a fsync()? You're
> using a 0-byte file (ie, without an actual data block). And even if you
> added some actual data, your test would do a writeout exactly once --
> after the first rename, all data blocks would be already on the disk.

Well, you said that rename calls fsync, I checked that. You're saying I
should have written something there before renaming? Let's check it too:
$ cd /path/to/empty/ext3/dir/
$ time for i in `seq 10000`; do echo 12345 > 1; mv 1 2; rm -f 2; done
real 0m20.125s
user 0m4.283s
sys 0m14.066s
$ cd /path/to/empty/tmpfs/dir/
$ time for i in `seq 10000`; do echo 12345 > 1; mv 1 2; rm -f 2; done
real 0m20.005s
user 0m4.076s
sys 0m13.088s
Still no difference. Both tests took 19-20 seconds And again there
were no HDD blinking during the test. Fsync() is a myth?

> Please fix your tests, then. Because, yes, tmpfs doesn't speed up fork(),
> exec(), setlocale(), getopt() and such.

True. These tests are useless as a benchmarks. They only prove that
there's no fsync(), nothing else. I could write that in C, but it's
pointless. Because there're still no *real* applications doing that!
And if there're no applications doing heavy rename() in /tmp then what
are we testing this for? Why are we moving *default* /tmp to tmpfs?
To make these useless tests faster?

Where's the real application becoming better after all?

--
Serge


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAOVenEp5qZB-rBwnYbrEwF2z7b99njMkeBMK8Z0s4omO6q4q9g@mail.gmail. com">http://lists.debian.org/CAOVenEp5qZB-rBwnYbrEwF2z7b99njMkeBMK8Z0s4omO6q4q9g@mail.gmail. com

On Sat, May 26, 2012 at 04:39:34PM -0400, Joey Hess wrote:
> Roger Leigh wrote:
> > I did want to have this for wheezy (#633299). But I lacked the time
> > and familiarity with the d-i code, and the d-i developers also have
> > higher priorities.
>
> Personally, this d-i developer has as one priority that the system d-i
> installs be broadly useful. d-i has at times needed to frob files in
> /etc to achieve this goal, and I have not ruled out the possibility that
> it might need to do so again...

Note that the initscripts respect all the settings in /etc/fstab,
and this includes noauto. While it would be possible to set the
default size and enable/disable by editing /etc/default/tmpfs, it's
also possible to configure the size by writing an fstab entry
with the size limit, with or without noauto.

Given the issues with the default size, and that we now use %VM,
it would be nice if the installer could perhaps accommodate the
use of tmpfs by automatically adding a certain size to the
swap size calculation, and if needed adding this to the fstab
entry.


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-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120527200805.GT22466@codelibre.net">http://lists.debian.org/20120527200805.GT22466@codelibre.net

On Sun, May 27, 2012 at 10:46:27PM +0800, Thomas Goirand wrote:
> On 05/25/2012 07:44 PM, Roger Leigh wrote:
> > However, the majority of
> > software which finds the tmpfs too small has unreasonable expectations
> > of what can be expected to be available (by default).
> >
> We welcome you to rewrite / patch these software then!
> Good luck, the list is huge, and growing every day this
> thread is alive.

(As an aside, could you possibly reduce the number of mails you're
sending. You've sent at least 12 today, and most of them all
said essentially the same thing.)


Regarding space usage on /tmp, I think I mentioned this before, but
I'm not sure it was on-list, so I'll reiterate it here.

The primary cause of problems is simply that the tmpfs /tmp isn't
big enough. Applications are creating files which use up all the
space. I'd like us to consider the problem in terms of what
guarantees are offered by the system in terms of minimum and
maximum available space on /tmp. Consider the default: /tmp is
on the rootfs, and there is a single filesystem (which might be
very large or quite small, and may have lots of free space or
very little). In this case, we offer no guarantees about the
available space. Now in the typical case, we might well have
tens, or even hundreds, of GiB available, which can be used by
files under /tmp. But this is not guaranteed. There might be
next to no free space. Now consider tmpfs mounted on /tmp: the
size specifies the total available space. This is guaranteed to
be available; it's both the minimum and maximum, so while it /might/
place a lower upper limit on size than a regular filesystem would,
it also guarantees that this space will be available, which is a
guarantee a regular filesystem does not offer (unless you have a
dedicated filesystem for /tmp, which is getting outside the scope
of this discussion).

If the default size of the tmpfs is too small, we should decide
what is a reasonable size, and ensure that the installer makes
sure sufficient swap is available by default, or disables tmpfs
on /tmp if this is not possible.


My other comment is regarding software having reasonable
expectations about the space they can use and, just as importantly,
how they cope when those expectations are not met.

In the example of streaming video using all the space on /tmp, the
space used is approxiately proportional to the length of the video
stream being downloaded. Looked at another way, the file is of
completely arbitrary size, and the application should be able to deal
with running out of space--resources are not finite, and failure should
be expected given the indeterminism implicit in the downloading. Is
/tmp even appropriate for this use?

Another example was not having enough space when processing images.
As mentioned by Neil Williams, it's important to tailor the
software and hardware to requirements, and others mentioned issues
with what happens when the tmpfs starts swapping. You obviously
don't want to swap unless you absolutely have to. I process multi-GiB
images using 8GiB RAM, 16GiB swap and a 6GiB tmpfs on /tmp. They get
copied to /tmp, have multiple operations performed on the temporary
copy, and get written back out. The performance is great--it's always
working on in-memory data, with a single copy to/from a regular
filesystem. But this was not a default configuration--it was
deliberately configured for the job. This will always be needed to get
optimal performance, whether you use a tmpfs or not. The system was
tailored to meet the expectations of the image processing software.

The best size for /tmp is of course the size which lets you store all
your data without it getting full. However, when its size is
essentially unlimited, there's a danger here. Software can assume
that it can fill it without restriction, and not need to deal with
space restrictions. While this isn't a problem on a desktop with
vast amounts of disc space, it does mean the software is essentially
imposing this requirement on *all* systems, including resource-
constrained systems, or else it's basically broken. This is not a
new problem--it's been an issue with mc as long as I remember. But
that does not make it desirable.


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-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120527213208.GU22466@codelibre.net">http://lists.debian.org/20120527213208.GU22466@codelibre.net

On Sun, May 27, 2012 at 10:01:22PM +0200, Tollef Fog Heen wrote:
> ]] Thomas Goirand
>
> > Come on, WE CAN! Let's create a /run/tmp *now*, it wont cost us much,
> > then later applications can slowly use it if they want. Worst case:
> > not a lot of app uses it, and the /run/tmp tmpfs isn't used much,
> > which isn't a problem. Best case: everyone that needs a fast space
> > has it and switches to it, and everyone is happy.
>
> How is this significantly different from /run/user/$user ? If it's not,
> we should just use that instead.

/run/user is AFAICT not for user data, it's for session metadata for
user services such as pidfiles, sockets and state. i.e. the user
equivalent of /var/run. Its size should be only a few KiB at most.


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-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120527213511.GV22466@codelibre.net">http://lists.debian.org/20120527213511.GV22466@codelibre.net

On 05/28/2012 05:32 AM, Roger Leigh wrote:
> On Sun, May 27, 2012 at 10:46:27PM +0800, Thomas Goirand wrote:
>> On 05/25/2012 07:44 PM, Roger Leigh wrote:
>>> However, the majority of
>>> software which finds the tmpfs too small has unreasonable expectations
>>> of what can be expected to be available (by default).
>>>
>> We welcome you to rewrite / patch these software then!
>> Good luck, the list is huge, and growing every day this
>> thread is alive.
>
> (As an aside, could you possibly reduce the number of mails you're
> sending. You've sent at least 12 today, and most of them all
> said essentially the same thing.)

I'll do that when people will stop ignoring arguments posted on the very
first message of the thread, like the fact so many popular applications
are writing big files to /tmp, and that it's simply unrealistic to
believe we can fix them all before Wheezy. You seem to forget it once
more in this post as well.

> The primary cause of problems is simply that the tmpfs /tmp isn't
> big enough. Applications are creating files which use up all the
> space. I'd like us to consider the problem in terms of what
> guarantees are offered by the system in terms of minimum and
> maximum available space on /tmp. Consider the default: /tmp is
> on the rootfs, and there is a single filesystem (which might be
> very large or quite small, and may have lots of free space or
> very little). In this case, we offer no guarantees about the
> available space. Now in the typical case, we might well have
> tens, or even hundreds, of GiB available, which can be used by
> files under /tmp. But this is not guaranteed. There might be
> next to no free space. Now consider tmpfs mounted on /tmp: the
> size specifies the total available space. This is guaranteed to
> be available; it's both the minimum and maximum, so while it /might/
> place a lower upper limit on size than a regular filesystem would,
> it also guarantees that this space will be available

Unless I didn't understand how tmpfs work, you have no guarantee as
well. Once your memory is eaten by apps, and your swap gets full, you
are in the exact same situation as having your /tmp holding partition
full, at the exception that your system becomes totally unusable and
unstable.

> If the default size of the tmpfs is too small, we should decide
> what is a reasonable size, and ensure that the installer makes
> sure sufficient swap is available by default, or disables tmpfs
> on /tmp if this is not possible.

There's simply no such thing. You can't decide arbitrarily how big the
.ppt files the user will import, what kind of MySQL dbs in use, or how
big the archives opened by mc will be.

> My other comment is regarding software having reasonable
> expectations about the space they can use and, just as importantly,
> how they cope when those expectations are not met.
>
> In the example of streaming video using all the space on /tmp, the
> space used is approxiately proportional to the length of the video
> stream being downloaded. Looked at another way, the file is of
> completely arbitrary size, and the application should be able to deal
> with running out of space--resources are not finite, and failure should
> be expected given the indeterminism implicit in the downloading. Is
> /tmp even appropriate for this use?

As you wrote, nothing is infinite. I don't think that /tmp is worse than
/home like other said. Your /home could become full as well.

> Another example was not having enough space when processing images.
> As mentioned by Neil Williams, it's important to tailor the
> software and hardware to requirements, and others mentioned issues
> with what happens when the tmpfs starts swapping. You obviously
> don't want to swap unless you absolutely have to. I process multi-GiB
> images using 8GiB RAM, 16GiB swap and a 6GiB tmpfs on /tmp. They get
> copied to /tmp, have multiple operations performed on the temporary
> copy, and get written back out. The performance is great--it's always
> working on in-memory data, with a single copy to/from a regular
> filesystem. But this was not a default configuration--it was
> deliberately configured for the job. This will always be needed to get
> optimal performance, whether you use a tmpfs or not. The system was
> tailored to meet the expectations of the image processing software.

Unfortunately, we aren't talking about having /tmp using tmpfs by
default if there's more than X GB of RAM. This is an unconditional
default that we're talking about here. If it was let's say using tmpfs
if there's more than 4GB of RAM, I don't think there would be so many
people complaining that this might be a bad choice.

> The best size for /tmp is of course the size which lets you store all
> your data without it getting full. However, when its size is
> essentially unlimited, there's a danger here. Software can assume
> that it can fill it without restriction, and not need to deal with
> space restrictions. While this isn't a problem on a desktop with
> vast amounts of disc space, it does mean the software is essentially
> imposing this requirement on *all* systems, including resource-
> constrained systems, or else it's basically broken. This is not a
> new problem--it's been an issue with mc as long as I remember. But
> that does not make it desirable.

Right. We never wished to be in the current situation. Nobody denies it.
But it's the way it is, and we have to deal with it.

Thomas


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4FC30B67.5090903@goirand.fr">http://lists.debian.org/4FC30B67.5090903@goirand.fr

Hi,

On Fri, May 25, 2012 at 02:22:24AM +0300, Serge wrote:
> What's a temporary file? Really, why would applications temporarily store
> its data in a file? They do that to *free some memory*. Placing those files
> back to memory renders the whole process of writing the file useless.
> If the files are small and can stay in memory why would application save it
> to file?

how, or why, would an application know that I have enough memory to keep
it all there, while you don't? The fail-safe way to code an application
without copious special-casing is to use a file and then let the systems
administrator decide what to do with it. If the application insists on
keeping everything in memory, the systems administrator can, at best,
add more swap, but if it uses a file, he can decide either way.

> Since it's only reasonable to store large data sets in temporary files,
> standard sets no size limits for these files. So if application's author
> had actually read FHS he should expect these directories to handle
> large files.

It's not, see below. Also, most of the time, /tmp goes into / (on
smaller systems), and is thus typically *very* much limited in space.
Granted, the user can relocate /tmp to another place later, once he
became aware of the limit...

Running out of space in /tmp should be a one-time event for any system
that one installs, since thereafter, /tmp will have enough space
configured for the desired purposes. No need to make it non-tmpfs.

> Who uses /tmp
> =============
> Let's check the real world and see what applications actually use /tmp.

> And the most important thing: file managers, browsers, image editors,
> cd burners — these are not some rare scientific stuff, but a common
> programs, that most people use every day. Putting them on a small tmpfs
> will break them. Putting them on large tmpfs may slow down or freeze
> the system due to heavy swapping.

I wanted to make the argument that php uses /tmp as the session save
path (it used to be there), but discovered, that someone has
re-configured that to now be in /var/lib/php5, so I'd say put that on a
tmpfs as well. Lots of small files with frequent accesses... whoever
wants those on a real disk?!?

> is to extend partitioner with a new option "Configure tmpfs partitions".
> That option should allow to mount anything as tmpfs (not just /tmp, but
> also /var/run, /media, /opt or whatever the user might want). It would be
> nice to have the `size` option there as well.

Having /var/run on a tmpfs may be a good idea, though.

> Q: I extremely care about my / fs and want to use it as rarely as possible.
> A: There're a lot of options:
> * symlink or mount-bind /tmp to i.e. /home/tmp
> * have /tmp on a separate partition (common and probably best solution)
> * you hate partitions? make /home/tmp_ext3fs.img and loop-mount it.
> That would solve your problem without making your system unstable because
> of high memory usage, or break programs because of no free space in /tmp.

It used to be /usr/tmp in olden days, just to have that out of / and
give it more space at the same time, too. One might also consider to
then merge /tmp with /var/tmp, eg. by way of symlinking them, as the one
who is strapped on memory, might as well be strapped on Internet
bandwidth to download that unfinished ISO that blew up his /tmp on
tmpfs, then re-getting the rest of it after rebooting...

> Q: /tmp on tmpfs increases apps performance.
> A: What apps? Real apps don't write files during performance-critical
> operations. Even if they do, they write large files. And large files are

Dead wrong.

Eg. web application's session data very frequently goes there, and/or
the sysadmin wants it to go onto a tmpfs.

> Q: gcc writes small files in /tmp
> A: usually it does not, especially when used with -pipe option

Changing all (generated?) Makefiles floating around out there, and
getting the changes committed upstream to actually benefit from that is
easier than using a tmpfs, of course.

> That's it. Thanks for reading.
>
> PS: should I had filled this as a bugreport?

I request that the bug be tagged wontfix.


Kind regards,
--Toni++


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120528110346.GA19463@spruce.wiehl.oeko.net">http ://lists.debian.org/20120528110346.GA19463@spruce.wiehl.oeko.net

On Mon, 28 May 2012 13:03:47 +0200
Toni Mueller <toni@debian.org> wrote:
> It's not, see below. Also, most of the time, /tmp goes into / (on
> smaller systems), and is thus typically *very* much limited in space.

If the theory is to design for the "trained chicken" install (and it still is, right?), then / gets the entire disk minus whatever gets assigned to swap. The sort of administrator who knows why she would want /home, /usr, and /var mounted separately can also be trusted to do whatever the right thing for her situation is with /tmp.

HOWEVER, what's currently missing is the ability in the installer to put /tmp on / (AFAICT). Giving it a partition puts it on disk, not doing anything puts it on tmpfs. Yes, it's a single-line change to fstab on your first boot, but still.

Over the past decade or so of writing one-off scripts I have (rightly or wrongly) formed the habit that /tmp is a 1777 area of disk where I can dump large things I don't want in memory at the moment (and therefore also a poor man's very asynchronous IPC domain -- yes, it's not supposed to be, but I think we'll also all admit we've done that at some point). Much better developers than me seem to have formed this opinion too (cf browsers' behavior while it waits for you to tell it what to do with an unknown content-type: it's a disk-based pipe to whatever program you pick to open it, except now it's a memory-based pipe, and I think /tmp on tmpfs is breaking those developers' expectations). We may be wrong, but apparently a lot of us don't yet trust the swapping algorithm to put the right stuff on disk yet. Also, I'd be more comfortable with tmpfs if it could be quota'd with standard quota tools.

> Having /var/run on a tmpfs may be a good idea, though.

Gah! I want *somewhere* I can park stuff on disk. Why are people so against that? Can we at least keep /var/tmp? (But I'm more worried about /var filling up than /, personally.) And how many of these are we going to do? Right now on my Squeeze laptop I have /lib/init/rw, /dev/shm, and /tmp. Do we really need more things that look like on-disk directories but aren't? (Then again I'm still grumpy about sysfs.) Though actually /var/run makes more sense than /tmp, since it's pretty much just for pids and sockets.

>
> I request that the bug be tagged wontfix.

Despite what I said above, I agree. The argument about web applications' session info is persuasive, and that's probably the hardest set of apps to change. As long as we are sure programs aren't dropping arbitrarily large files into it (I'm looking at you, Iceweasel...) and as long as there's *some* section of actual disk somewhere that's 1777.

Also, this is rapidly approaching two sets of choir-preaching, so I'll bow out after this.

Cheers,
Weldon


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120528082652.f9a53baa.weldon@b.rontosaur.us">htt p://lists.debian.org/20120528082652.f9a53baa.weldon@b.rontosaur.us

On Mon, May 28, 2012 at 01:21:43PM +0800, Thomas Goirand wrote:

As you wrote, nothing is infinite. I don't think that /tmp is worse than
/home like other said. Your /home could become full as well.


Your /home could be a network share like NFS and /tmp a local partition,
so you don’t want to use /home for temporary downloads or caches.
Besides that, on multi-user systems /tmp can be used to share files (I’ve
downloaded the current ISO image to /tmp, so you can copy it from there).
This is much better than to open access to your $HOME directory.


And I think, it is clear as well that your disk space will always be much
bigger than your RAM size. It seems very strange to waste RAM for
a ramdisk to free disk space.


I don’t think that there is a sane default as well. A desktop system
which runs several VMs will probably not like to waste RAM for tmpfs.


But since we are talking about defaults, how does d-i partition your hard
disk in the following cases?


a) Notebook
4 GB RAM
250GB disk

b) PC
4 GB RAM
2TB disk

If it creates 4 or 8 GB swap and a single partition for the remaining
disk, tmpfs will never beat disk space.


If the admin decides to partition manually he will know what he does (or
he should ;-). My PC is normally used remote and acts more like a server.
It uses tmpfs, but its size is only 635M, so I already have problems
creating a CD ISO. Since the system has 2 TB disk space, my next
repartitioning will create a separate /tmp with about 10 or 20 GB, much
easier to spare than RAM.


So I don’t see the advantage of using tmpfs as default, but d-i should
offer the option to put /tmp on tmpfs if the admin wishes it.


Shade and sweet water!

Stephan

--
| Stephan Seitz E-Mail: stse@fsing.rootsland.net |
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |

On Mon, May 28, 2012 at 08:26:52AM -0400, Weldon Goree wrote:
> at some point). Much better developers than me seem to have formed
> this opinion too (cf browsers' behavior while it waits for you to tell
> it what to do with an unknown content-type: it's a disk-based pipe to
> whatever program you pick to open it, except now it's a memory-based
> pipe, and I think /tmp on tmpfs is breaking those developers'
> expectations).

As for Iceweasel, there is a bug in Mozilla's database that addresses
exactly this problem. In the overwhelming number of cases of people
downloading large files via their web browser, these files are going to
end up somewhere in their homes, anyway, so the initial downloaded
fragments should be stored there. Although I haven't paid attention to
that bug as of late, I do remember seeing some activity going on there,
and I think the Mozilla developers have been finally convinced to adopt
a different strategy.

> I'd be more comfortable with tmpfs if it could be quota'd with
> standard quota tools.

If this part goes to your home, it's automatically quota'ed.

> > Having /var/run on a tmpfs may be a good idea, though.
> Gah! I want *somewhere* I can park stuff on disk. Why are people so
> against that?

Nobody is against that, only that you insist on using /tmp for it, which
is imho not a good assumption to make.

> we going to do? Right now on my Squeeze laptop I have /lib/init/rw,
> /dev/shm, and /tmp. Do we really need more things that look like
> on-disk directories but aren't? (Then again I'm still grumpy about
> sysfs.) Though actually /var/run makes more sense than /tmp, since
> it's pretty much just for pids and sockets.

Without doing much (that I can remember) to my box, I see this on
Testing:

$ mount|grep tmpfs
udev on /dev type devtmpfs (rw,relatime,size=4018332k,nr_inodes=205757,mode=7 55)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=804880k,mode=755)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,size=307200k)
tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,relatime,size=1609760k)
$

Enjoy!

> dropping arbitrarily large files into it (I'm looking at you,
> Iceweasel...) and as long as there's *some* section of actual disk
> somewhere that's 1777.

As I said, there was /usr/tmp, but I think it was shot down. But I
suggest /srv/tmp or something like that.



Kind regards,
--Toni++


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120530002030.GA32472@spruce.wiehl.oeko.net">http ://lists.debian.org/20120530002030.GA32472@spruce.wiehl.oeko.net

Le samedi 26 mai 2012 Ã* 23:02 +0200, Carlos Alberto Lopez Perez a
écrit :
> With "tmpfs on /tmp" you are breaking many applications that assume that
> they have enough space to write on /tmp like the flash player ( see
> Debian bug #666096 ) or cdrecord software ( see #665634 ).

Seriously, this is madness. You can’t expect to have “enough� space on
*any* filesystem.

--
.'`. Josselin Mouette
: :' :
`. `'
`-


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1338372509.3625.219.camel@pi0307572">http://lists.debian.org/1338372509.3625.219.camel@pi0307572