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

» Linux Archive

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


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 06-24-2012, 07:54 PM
Stephan Seitz
 
Default Summary: Moving /tmp to tmpfs makes it useless

On Sat, Jun 23, 2012 at 11:43:03PM +0200, Wouter Verhelst wrote:

On Thu, Jun 21, 2012 at 03:46:16PM +0200, Stephan Seitz wrote:

So most of your Debian systems have several users working at the
same time on the same system? Okay, then you have a different user
base.

"webserver".


Sorry, I ignored servers. I don’t think that anyone will install a server
with a default installation because you have more special cases (separate
database partition, separate mailbox partition, etc.).



I still think that the SSD problem is not a valid concern as long as
we don’t have solutions for /var and log daemons. There is more
traffic in /var than in /tmp.

Yes, /var produces changes to storage, too, but that doesn't mean we
shouldn't optimize /tmp because we can't optimize /var. That makes no
sense.


But if you move the /tmp access away (see below), then you don’t need
tmpfs at all.



I'm not saying we should "optimize for SSDs". I'm just saying that
storing on tmpfs is beneficial for SSDs.


See below.

[/ramtmp not a good idea]

Well, why?

Because it would end up being a directory that nearly nobody would use
directly. Those who want to use a ramdisk will just remove that
directory (or make it a symlink) and mount /tmp on tmpfs instead, and
those who don't want to use it will probably just ignore it.


I don’t think so. Having a disk based /tmp that gets cleaned after
reboots and having a ramdisk /ramtmp will give you the choice which
directory you want to use for a special application. Your video encoder
example could certainly use /ramtmp, even if you have to patch the
encoder in Debian to do so. The temporary video files of the web browser
can stay in /tmp, as well as big powerpoint temporary files of
libreoffice.


And I don’t think that most user only want one solution.


Also, if deciding on a reasonable default for /tmp is difficult, think
about deciding on a reasonable default for individual packages. That's
going to be even harder.


Sometimes maybe. But you will certainly get some hundred of megabytes of
tmpfs space. So if you know that your temporary file will be smaller, you
can use /ramtmp.
Besides we can look for other places to use tmpfs. What about
/var/lib/amavis/tmp? The initscript could create a tmpfs.



Meanwhile, you've got a non-FHS directory on your system that is of no
immediate use.


Your later suggested /store as a user /tmp replacement is a non-FHS
directory as well.



/tmp has always been about 10-20GB big, because I expect users to
store big temporary images in /tmp. I won’t get this with tmpfs and
I would have to train the users to change their behaviour.

I believe this is part of our disagreement: I don't think system-wide
directories are meant for users to use directly. In other words, I don't
think users should put large downloads in /tmp; instead, they should put


Now this thread is the first time someone mentions that /tmp should not
be used by users but is only for system services. I don’t know of any
documentation to support this claim. On the contrary all documentation
about Unix/Linux I know say that /tmp is for all temporary files.


But let’s say, /tmp is only for system services. Temporary user files
belong to $HOME/tmp (which would be a special case in Debian only). So
besides from teaching all users to not use /tmp, we need a cleaning job
for $HOME/tmp and have to patch all software (browser, libreoffice,
libpam-tmp, etc) to use the new tmp.
But then most of your examples for tmpfs will be void because no user
will use it. Your video encoder is a user application, so the temporary
statistic file will go to $HOME/tmp, not to /tmp.


And if you say that noone will use a combination of /tmp and /ramtmp, why
do you think that someone will suddenly use a combination of /tmp (tmpfs)
and $HOME/tmp?


So I still think that my /ramtmp additional to /tmp are for now the best
of both worlds without the risk of breaking applications and user
expectations.


Stephan

--
| Stephan Seitz E-Mail: stse@fsing.rootsland.net |
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |
 
Old 06-25-2012, 12:11 AM
Wouter Verhelst
 
Default Summary: Moving /tmp to tmpfs makes it useless

On Sun, Jun 24, 2012 at 09:54:22PM +0200, Stephan Seitz wrote:
> On Sat, Jun 23, 2012 at 11:43:03PM +0200, Wouter Verhelst wrote:
> >Meanwhile, you've got a non-FHS directory on your system that is of no
> >immediate use.
>
> Your later suggested /store as a user /tmp replacement is a non-FHS
> directory as well.

No, you misunderstand.

As a local sysadmin, I've installed systems with a large scratch space
for users to use under a non-FHS directory. The FHS explicitly allows
that.

But I never said Debian should do the same.

> >>/tmp has always been about 10-20GB big, because I expect users to
> >>store big temporary images in /tmp. I won’t get this with tmpfs and
> >>I would have to train the users to change their behaviour.
> >I believe this is part of our disagreement: I don't think system-wide
> >directories are meant for users to use directly. In other words, I don't
> >think users should put large downloads in /tmp; instead, they should put
>
> Now this thread is the first time someone mentions that /tmp should
> not be used by users but is only for system services. I don’t know
> of any documentation to support this claim.

Neither do I :-)

I *personally* think /tmp should not be used for user data. It's not the
best place for that, for various reasons (impact on the system, lack of
privacy, possible namespace collisions, ...).

But I'm not going to say that people should not use it for that. It's
perfectly fine if you want to do that, it's just not a very good idea.

IMO.

[...]
--
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120625001100.GC31494@grep.be">http://lists.debian.org/20120625001100.GC31494@grep.be
 
Old 06-25-2012, 09:43 AM
Goswin von Brederlow
 
Default Summary: Moving /tmp to tmpfs makes it useless

Wouter Verhelst <wouter@debian.org> writes:

> On Sun, Jun 24, 2012 at 09:54:22PM +0200, Stephan Seitz wrote:
>> On Sat, Jun 23, 2012 at 11:43:03PM +0200, Wouter Verhelst wrote:
>> >Meanwhile, you've got a non-FHS directory on your system that is of no
>> >immediate use.
>>
>> Your later suggested /store as a user /tmp replacement is a non-FHS
>> directory as well.
>
> No, you misunderstand.
>
> As a local sysadmin, I've installed systems with a large scratch space
> for users to use under a non-FHS directory. The FHS explicitly allows
> that.

We have /scratch for that. Unlike /tmp the /scratch is not going to be
cleaned on reboot. So it is more like /var/tmp.

> But I never said Debian should do the same.
>
MfG
Goswin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/87y5nb20bx.fsf@frosties.localnet
 
Old 06-25-2012, 10:09 AM
Goswin von Brederlow
 
Default Summary: Moving /tmp to tmpfs makes it useless

Henrique de Moraes Holschuh <hmh@debian.org> writes:

> On Sun, 24 Jun 2012, Goswin von Brederlow wrote:
>> Henrique de Moraes Holschuh <hmh@debian.org> writes:
>> > I've read that some SSDs really *dislike* the way Linux does TRIM
>> > batching (or doesn't ), so yes, it may well be that on most SSDs
>> > regular fstrim will do much better.
>>
>> I'm assuming this is due to fragmentation. With TRIM you get lots of
>> small free chunks. With fstrim you get huge batches.
>
> AFAIK, it is related to trim requests not being of the same type as
> write/read requests (so you have to drain the queue of all in-flight
> commands or something), some SSDs being allergic to large batched trim
> requests while others are allergic to unbatched small trim requests,
> bershitty implementation of said command in SSDs (high latency,
> synchronous), etc. On top of whatever performance issues the Linux support
> for TRIM at the storage stack and filesystems might have.
>
> It may well have no fix. fstrim is not performance sensitive (people will
> run it when they have the time to wait for it to complete), so it doesn't
> matter if the SSD is very bad at TRIM and goes out for lunch for several
> seconds per trim request...

Ahh, that makes more sense. I thought you ment normal read/write
(without interleaved TRIM) would become slower.

>> But if the disk doesn't defrag then won't it just be a matter of time
>> for it to get slow with fstrim too?
>
> Any SSD worth its price has both the reserved flash and the background
> garbage collection systems required to defrag itself if left idle for long
> enough. But regular TRIMming lets it do a much better job.

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/87hatz1z5c.fsf@frosties.localnet
 

Thread Tools




All times are GMT. The time now is 11:30 AM.

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