Mailinglist Archive: opensuse-factory (1578 mails)
| < Previous | Next > |
Re: [opensuse-factory] [12.1] massive data loss in /var/tmp/
- From: Ruediger Meier <sweet_f_a@xxxxxx>
- Date: Wed, 23 Nov 2011 18:14:02 +0100
- Message-id: <201111231814.02909.sweet_f_a@gmx.de>
On Wednesday 23 November 2011, Cristian Rodríguez wrote:
The point whether it makes sense to store data on /var/tmp has been
discussed endless already in this thread... Why not deleting /tmp every
nanosecond per default?
I have actively configured all our Desktop machines exactly following
the openSUSE documented way how and when to delete my /tmp every reboot
and every 60 days and deleting /var/tmp after 300 days but not on
reboot.
If something else happens then it's a bug.
Again about /var/tmp use case:
Our users know about our setup and they are politely requested to
use /var/tmp for their data if no backup is needed, if they need speed
(fast local storage) and if they don't need it shared (NFS). This helps
me to safe expense /home and backup storage and safes load on NFS for
the more important data.
My users usually run data mining stuff producing x TB of data to be used
just one time if calculation is finished after some weeks. In case
their data would be deleted at random dates then they could restart
their process to wait another few weeks. But before doing this they
would probably kill me.
And yes, backuping all this data would be more expensive than waiting
again some weeks to reproduce it. Moreover it would not even possible
to backup it in real time. And last but not least backuping this data
would probably useless because some of their processes simply can't be
continued and has to be re-done completely.
This use case perfectly matches to what /var/tmp is supposed to be.
My users are no daemons.
cu,
Rudi
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx
On 23/11/11 12:02, Ruediger Meier wrote:
On Wednesday 23 November 2011, Ludwig Nussel wrote:
That tells systemd to clear files older than 10 resp 30 days in
those directories. systemd does not honor TMP_DIRS_TO_CLEAR.
If this is really the default now then it should have been a major
point on ReleaseNotes.
really ? since when it is a major point that the system actually
deletes temporary files as it should ?
The point whether it makes sense to store data on /var/tmp has been
discussed endless already in this thread... Why not deleting /tmp every
nanosecond per default?
I have actively configured all our Desktop machines exactly following
the openSUSE documented way how and when to delete my /tmp every reboot
and every 60 days and deleting /var/tmp after 300 days but not on
reboot.
If something else happens then it's a bug.
Again about /var/tmp use case:
Our users know about our setup and they are politely requested to
use /var/tmp for their data if no backup is needed, if they need speed
(fast local storage) and if they don't need it shared (NFS). This helps
me to safe expense /home and backup storage and safes load on NFS for
the more important data.
My users usually run data mining stuff producing x TB of data to be used
just one time if calculation is finished after some weeks. In case
their data would be deleted at random dates then they could restart
their process to wait another few weeks. But before doing this they
would probably kill me.
And yes, backuping all this data would be more expensive than waiting
again some weeks to reproduce it. Moreover it would not even possible
to backup it in real time. And last but not least backuping this data
would probably useless because some of their processes simply can't be
continued and has to be re-done completely.
This use case perfectly matches to what /var/tmp is supposed to be.
The good thing is that systemd allows to use a private,unshared /tmp
namespace that daemons can use so this whole story can finally be put
to an end.
My users are no daemons.
cu,
Rudi
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx
| < Previous | Next > |