4:45 p.m.
What files are basically safe to remove because they are caches and
such? There is the invisible file .cache. And the /var/cache. The files
in /tmp are these safe to delete? Are there any other files you can
delete? For example if you were using rsync, what file would you not
want to backup, because they are just caches?
B
5:20 p.m.
On 12/28/22 14:45, Bill Cunningham wrote:
What files are basically safe to remove because they are caches and
such? There is the invisible file .cache. And the /var/cache. The files
in /tmp are these safe to delete? Are there any other files you can
delete? For example if you were using rsync, what file would you not
want to backup, because they are just caches?
Just because they are a cache doesn't mean they are necessarily safe to
delete while running. Most applications take care of managing their
cache files. Technically, you can delete stuff in /var/cache, but don't
at least don't delete the top-level directories. e.g. /var/cache/dnf
Of course, if you delete cached files, that usually means that they will
have to be downloaded again when you want to use them.
Don't delete files in /tmp unless you know it's safe to do so. There
are important files in there and you might find things not working
properly if you delete them. /tmp is by default tmpfs, so anything in
there won't persist over a reboot. Also, there is a process that cleans
old files, so unless you've put something big in there yourself and need
the RAM back, you don't need to do anything.
For backup purposes, you can certainly skip the various cache
directories. /var/cache for the system and ~/.cache for the users. I
think most applications use that now, but there might be some
application that stores cache files somewhere else.
5:34 p.m.
On Wed, 28 Dec 2022 15:20:57 -0800
Samuel Sieb wrote:
Just because they are a cache doesn't mean they are necessarily
safe to
delete while running. Most applications take care of managing their
cache files.
I used to try and deal with avoiding backups of "unimportant" stuff
until I discovered that various directories in my dovecot mail directory
had names like "cache" and "temp", but if not restored from backup it
was a lot of work to get mail functioning correctly after restoring.
I finally got it through my head that disk space is pretty darn cheap
and I might as well backup virtually everything. I still skip a few
things that seem gigantic where I can't imagine any reason to back them up
like swap files.
6:55 p.m.
On 12/28/2022 6:34 PM, Tom Horsley wrote:
On Wed, 28 Dec 2022 15:20:57 -0800
Samuel Sieb wrote:
> Just because they are a cache doesn't mean they are necessarily safe to
> delete while running. Most applications take care of managing their
> cache files.
I used to try and deal with avoiding backups of "unimportant" stuff
until I discovered that various directories in my dovecot mail directory
had names like "cache" and "temp", but if not restored from backup
it
was a lot of work to get mail functioning correctly after restoring.
I finally got it through my head that disk space is pretty darn cheap
and I might as well backup virtually everything. I still skip a few
things that seem gigantic where I can't imagine any reason to back them up
like swap files.
I didn't want to get stuff all cluttered and confused. If I backed up
all cache data and restored, which I do quite a bit, I would have so
many backups of unimportant data. Sometimes too, to me, a fresh start is
warranted.
B
11:42 a.m.
On Wed, 28 Dec 2022 17:45:25 -0500
Bill Cunningham <bill.cu1234(a)gmail.com> wrote:
What files are basically safe to remove because they are caches and
such? There is the invisible file .cache. And the /var/cache. The
files in /tmp are these safe to delete? Are there any other files you
can delete? For example if you were using rsync, what file would you
not want to backup, because they are just caches?
I saw yesterday in devel that there are over 23,000 packages in Fedora.
No one is going to know the intricacies of all those packages. It is
on you to perform trial and error to determine what is necessary or
not for the packages you have. I compile a custom kernel tuned to my
hardware. No one can tell me what I can leave out or not, except me. I
use trial and error, and trim it until something breaks.
That said, because I compile packages (and some programs) locally, I
don't bother backing up the .ccache directory in my home directory. I
also do my backups from another version of Fedora with the version
being backed up not booted, so that there are no temporary files. Like
Tom, I ignore space except for obvious wastes like the ~/.ccache
directory and ~/rpmbuild. If you are desperate, you could
ignore all the files under /var/log. They will be recreated as the
system runs (I think), but a restore will have no information about the
system's previous state.
11:49 a.m.
PS
If you want to know the biggest space hogs, run
du -S -BM / | sort -g | less
or something like it that suits your desires.
12:17 p.m.
On Thu, 29 Dec 2022 10:49:54 -0700
stan <upaitag(a)zoho.com> wrote:
I'm getting ridiculous now, but technically you should be able to keep
the minimal install media around, and have a script that installs all
the packages you currently have installed from the Fedora (and
RPMFusion) repositiories. Under that scenario, you only need to back
up the home directory with all your custom configuration changes. And
any data on the system that isn't replaceable from the repositories.
But, you could keep that custom data on a separate partition, backed up
separately, so that it doesn't have to be re-installed when you
re-install the system. Just linked again in fstab. I guess that would
probably work for home, as well (I don't do that, so I don't know).
The drawback is that this will be slow. All the downloading and dnf
validation. And unless you have a lot of memory, it would probably
have to be done in steps. A tradeoff of length of time to recover vs
space to store an actual backup.
12:29 p.m.
On 12/29/2022 11:17 AM, stan via users wrote:
But, you could keep that custom data on a separate partition, backed
up
separately, so that it doesn't have to be re-installed when you
re-install the system. Just linked again in fstab. I guess that would
probably work for home, as well (I don't do that, so I don't know).
It works fine. I know, because I've been doing exactly that for many
years. /home is on one partition, various directories I've kept around
for historic reasons on another, and the rest goes to the new system.
Of course, I back up what I want to keep and use a custom partitioning
scheme, but that's no bother for me.
4:28 a.m.
On 29/12/2022 18:49, stan via users wrote:
PS
If you want to know the biggest space hogs, run
du -S -BM / | sort -g | less
or something like it that suits your desires.
Yes, I do this so often that I have an alias in my .bashrc
dus="du --max-depth=1 -h |sort -h"
it shows the all the subdir sorted and in an easy to read way.
G
10:15 a.m.
On Fri, 30 Dec 2022 11:28:16 +0100
GianPiero Puccioni <gianpiero.puccioni(a)isc.cnr.it> wrote:
On 29/12/2022 18:49, stan via users wrote:
> PS
> If you want to know the biggest space hogs, run
> du -S -BM / | sort -g | less
> or something like it that suits your desires.
>
Yes, I do this so often that I have an alias in my .bashrc
dus="du --max-depth=1 -h |sort -h"
it shows the all the subdir sorted and in an easy to read way.
Now it's an alias on my system too. :-)
10:24 a.m.
stan via users composed on 2022-12-30 09:15 (UTC-0700):
On Fri, 30 Dec 2022 11:28:16 +0100 GianPiero Puccioni wrote:
> Yes, I do this so often that I have an alias in my .bashrc
> dus="du --max-depth=1 -h |sort -h"
> it shows the all the subdir sorted and in an easy to read way.
Now it's an alias on my system too. :-)
I find ncdu more convenient.
--
Evolution as taught in public schools is, like religion,
based on faith, not based on science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata
11:57 a.m.
Bashrc is a file I know of but I am not familiar with and have never
edited. I usually use 'rm -rf /temp/*' and have been warned against it. I
haven't seen any problems I know of happening because of this.
On Fri, Dec 30, 2022, 11:25 AM Felix Miata <mrmazda(a)earthlink.net> wrote:
stan via users composed on 2022-12-30 09:15 (UTC-0700):
> On Fri, 30 Dec 2022 11:28:16 +0100 GianPiero Puccioni wrote:
>> Yes, I do this so often that I have an alias in my .bashrc
>> dus="du --max-depth=1 -h |sort -h"
>> it shows the all the subdir sorted and in an easy to read way.
> Now it's an alias on my system too. :-)
I find ncdu more convenient.
--
Evolution as taught in public schools is, like religion,
based on faith, not based on science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
12:11 p.m.
On Fri, 2022-12-30 at 12:57 -0500, Bill C wrote:
I usually use 'rm -rf /temp/*' and have been warned against
it. I
haven't seen any problems I know of happening because of this.
Owing to how file unlinking works in UNIX/Linux systems, if a process
has a temporary file open when you delete it, it won't be removed until
the process terminates. However it's unwise to rely on this when a
temporary file might be closed and re-opened, including by a different
process. That could lead to unpredictable behaviour because of race
conditions.
poc
12:14 p.m.
I see. Of course I meant/tmp/*
On Fri, Dec 30, 2022, 1:11 PM Patrick O'Callaghan <pocallaghan(a)gmail.com>
wrote:
On Fri, 2022-12-30 at 12:57 -0500, Bill C wrote:
> I usually use 'rm -rf /temp/*' and have been warned against it. I
> haven't seen any problems I know of happening because of this.
Owing to how file unlinking works in UNIX/Linux systems, if a process
has a temporary file open when you delete it, it won't be removed until
the process terminates. However it's unwise to rely on this when a
temporary file might be closed and re-opened, including by a different
process. That could lead to unpredictable behaviour because of race
conditions.
poc
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
3:16 p.m.
On Dec 30, 2022, at 13:14, Bill C <bill.cu1234(a)gmail.com> wrote:
I see. Of course I meant/tmp/*
Files in /tmp are automatically removed by systemd-tmpfiles on Fedora based on a schedule
defined in /usr/lib/tmpfiles.d/tmp.conf
(https://github.com/systemd/systemd/blob/main/tmpfiles.d/tmp.conf)
So, files older than 10 days are removed. No need to do this by hand. (Pre-systemd this
was handled by tmpwatch)
Also, many systemd services with PrivateTmp will have namespaces mounted in /tmp that
aren’t removable, which will generally cause issues with your command.
--
Jonathan Billings
3:34 p.m.
On 12/30/2022 4:16 PM, Jonathan Billings wrote:
On Dec 30, 2022, at 13:14, Bill C <bill.cu1234(a)gmail.com>
wrote:
>
> I see. Of course I meant/tmp/*
Files in /tmp are automatically removed by systemd-tmpfiles on Fedora
based on a schedule defined in /usr/lib/tmpfiles.d/tmp.conf
(https://github.com/systemd/systemd/blob/main/tmpfiles.d/tmp.conf)
So, files older than 10 days are removed. No need to do this by hand.
(Pre-systemd this was handled by tmpwatch)
Also, many systemd services with PrivateTmp will have namespaces
mounted in /tmp that aren’t removable, which will generally cause
issues with your command.
--
Jonathan Billings
So would it be safe to set this to 1 day?
5:45 p.m.
On Dec 30, 2022, at 16:34, Bill Cunningham <bill.cu1234(a)gmail.com> wrote:
So would it be safe to set this to 1 day?
Copy the file to /etc/tmpfiles.d/ before changing it.
I am slightly concerned about whether it is a good idea to change to 1 day. Please be
careful.
--
Jonathan Billings
12:16 p.m.
I have seen these files mount up. In the tmp directory. Now are these
erased at reboot and automatically cleaned. If so, there's definitely no
need to delete them, just not copy to a backup or archive.
On Fri, Dec 30, 2022, 1:11 PM Patrick O'Callaghan <pocallaghan(a)gmail.com>
wrote:
On Fri, 2022-12-30 at 12:57 -0500, Bill C wrote:
> I usually use 'rm -rf /temp/*' and have been warned against it. I
> haven't seen any problems I know of happening because of this.
Owing to how file unlinking works in UNIX/Linux systems, if a process
has a temporary file open when you delete it, it won't be removed until
the process terminates. However it's unwise to rely on this when a
temporary file might be closed and re-opened, including by a different
process. That could lead to unpredictable behaviour because of race
conditions.
poc
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
12:23 p.m.
On Fri, 2022-12-30 at 13:16 -0500, Bill C wrote:
I have seen these files mount up. In the tmp directory. Now are
these
erased at reboot and automatically cleaned. If so, there's definitely
no need to delete them, just not copy to a backup or archive.
O
Of course. However I understood from your earlier message that you
might be deleting these files manually at some random time, which would
not be a good idea even if it mostly works.
poc
12:35 p.m.
On Fri, 30 Dec 2022 11:24:42 -0500
Felix Miata <mrmazda(a)earthlink.net> wrote:
stan via users composed on 2022-12-30 09:15 (UTC-0700):
> On Fri, 30 Dec 2022 11:28:16 +0100 GianPiero Puccioni wrote:
>> Yes, I do this so often that I have an alias in my .bashrc
>> dus="du --max-depth=1 -h |sort -h"
>> it shows the all the subdir sorted and in an easy to read way.
> Now it's an alias on my system too. :-)
I find ncdu more convenient.
Thanks, another great option for this task.
480
days inactive
482
days old
19 comments
10 participants
participants (10)
-
Bill C -
Bill Cunningham
-
Felix Miata -
GianPiero Puccioni -
Joe Zeff -
Jonathan Billings -
Patrick O'Callaghan -
Samuel Sieb -
stan -
Tom Horsley