[opensuse] tmp full, crash
Hello, coming to house after two hours out, I found my 13.2 computer with kde session crashed. I could open a root terminal (full text mode), didn't find any problem, at least 35% free space anywhere (and often much more). reboot, same. No X. most operation gives "no space left on device". after several reboots without enhancement, I went to /tmp, did rm -R *... and all ice ok now. what I don't understand is why was all use space only 65%?? nothing said what can't be written. Only special thing I had was a very long upload to my online server, 30Gb total (already 2 days and approx the same to end), copy/paste with dolphin. No problem server side. thanks jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/09/2015 11:35 AM, jdd wrote:
what I don't understand is why was all use space only 65%?? nothing said what can't be written.
maybe there are 35% of the blocks free, but already all inode entries used? See columns Inodes..IUsed..IFree..IUsed: $ df -h --out . Filesystem Type Inodes IUsed IFree IUse% Size Used Avail Use% File Mounted on /dev/sda1 ext4 1.3M 227K 1.1M 18% 20G 7.1G 12G 39% . / Furthermore, file systems may support some "reserved blocks" limit, above which only root can use the rest. For the 'ext[234]' family, you'd check this with 'tune2fs -l'. Have a nice day, Berny -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 09/02/2015 12:07, Bernhard Voelker a écrit :
$ df -h --out .
this gave all zeros, so I noted the /tmp is on btrfs (13.2 default). so # btrfs fi df / Data, single: total=38.24GiB, used=17.91GiB System, single: total=4.00MiB, used=16.00KiB Metadata, single: total=1.76GiB, used=1.31GiB GlobalReserve, single: total=432.00MiB, used=80.00KiB # btrfs fi usage / Overall: Device size: 40.00GiB Device allocated: 40.00GiB Device unallocated: 0.00B Used: 19.22GiB Free (estimated): 20.33GiB (min: 20.33GiB) Data ratio: 1.00 Metadata ratio: 1.00 Global reserve: 432.00MiB (used: 320.00KiB) Data,single: Size:38.24GiB, Used:17.91GiB /dev/sdb1 38.24GiB Metadata,single: Size:1.76GiB, Used:1.31GiB /dev/sdb1 1.76GiB System,single: Size:4.00MiB, Used:16.00KiB /dev/sdb1 4.00MiB Unallocated: /dev/sdb1 0.00B but of course after /tmp was cleaned I'm a bit short of undertanding :-( thanks jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/02/15 12:00, jdd wrote:
Le 09/02/2015 12:07, Bernhard Voelker a écrit :
$ df -h --out .
this gave all zeros, so I noted the /tmp is on btrfs (13.2 default).
so
# btrfs fi df / Data, single: total=38.24GiB, used=17.91GiB System, single: total=4.00MiB, used=16.00KiB Metadata, single: total=1.76GiB, used=1.31GiB GlobalReserve, single: total=432.00MiB, used=80.00KiB
# btrfs fi usage / Overall: Device size: 40.00GiB Device allocated: 40.00GiB Device unallocated: 0.00B Used: 19.22GiB Free (estimated): 20.33GiB (min: 20.33GiB) Data ratio: 1.00 Metadata ratio: 1.00 Global reserve: 432.00MiB (used: 320.00KiB)
Data,single: Size:38.24GiB, Used:17.91GiB /dev/sdb1 38.24GiB
Metadata,single: Size:1.76GiB, Used:1.31GiB /dev/sdb1 1.76GiB
System,single: Size:4.00MiB, Used:16.00KiB /dev/sdb1 4.00MiB
Unallocated: /dev/sdb1 0.00B
but of course after /tmp was cleaned
I'm a bit short of undertanding :-(
thanks jdd
Take a look at Yast2 > Miscellaneous > Snapper. I suspect snapper is creating btrfs snapshots of your / every time you patch/update anything. This seems to the default behaviour of the openSUSE btrfs. Once you've tamed this behaviour, btrfs is quite well behaved. I've been using it for about 6 months here. Bob - -- Bob Williams System: Linux 3.16.7-7-desktop Distro: openSUSE 13.2 (x86_64) with KDE Development Platform: 4.14.3 Uptime: 06:00am up 7:55, 3 users, load average: 0.16, 0.05, 0.06 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlTY3k8ACgkQ0Sr7eZJrmU5ydQCeKOWzdgwP46cy+kT9dkydy9xh 4pYAoI8+eFj8upmvUkSZfMw9RGaH0zpX =CqTR -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/9/2015 8:20 AM, Bob Williams wrote:
On 09/02/15 12:00, jdd wrote:
Le 09/02/2015 12:07, Bernhard Voelker a écrit :
$ df -h --out .
this gave all zeros, so I noted the /tmp is on btrfs (13.2 default).
so
# btrfs fi df / Data, single: total=38.24GiB, used=17.91GiB System, single: total=4.00MiB, used=16.00KiB Metadata, single: total=1.76GiB, used=1.31GiB GlobalReserve, single: total=432.00MiB, used=80.00KiB
# btrfs fi usage / Overall: Device size: 40.00GiB Device allocated: 40.00GiB Device unallocated: 0.00B Used: 19.22GiB Free (estimated): 20.33GiB (min: 20.33GiB) Data ratio: 1.00 Metadata ratio: 1.00 Global reserve: 432.00MiB (used: 320.00KiB)
Data,single: Size:38.24GiB, Used:17.91GiB /dev/sdb1 38.24GiB
Metadata,single: Size:1.76GiB, Used:1.31GiB /dev/sdb1 1.76GiB
System,single: Size:4.00MiB, Used:16.00KiB /dev/sdb1 4.00MiB
Unallocated: /dev/sdb1 0.00B
but of course after /tmp was cleaned
I'm a bit short of undertanding :-(
thanks jdd
Take a look at Yast2 > Miscellaneous > Snapper. I suspect snapper is creating btrfs snapshots of your / every time you patch/update anything. This seems to the default behaviour of the openSUSE btrfs. Once you've tamed this behaviour, btrfs is quite well behaved. I've been using it for about 6 months here.
Bob --
Yes, I've had to reduce the frequency of snapper as well. Much as I hate to repartition I was thinking of doing so to get tmp out of Btrfs, because Everytime I burn a CD/DVD huge tmp files are created. It got so bad that I moved K3Bs temp working directory to my a subdirectory in my home directory which solved that problem for now. But JDD is on to something here, and that is tat with Btrfs you are never sure how much room you have, and the normal disk reporting tools have to be read very carefully. They should probably be rewritten to take Btrfs into account. Meanwhile perhaps someone can explain how I can set snapper not to snapshot tmp at all. - -- _____________________________________ - ---This space for rent--- -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlTZFmcACgkQv7M3G5+2DLIkUgCgik7JYENSI/1mVG+vejuF9Ktj ticAnj4Iv8RCfnZSpcLGG+9kN4nk15r8 =OYTZ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/02/15 20:19, John Andersen wrote:
Meanwhile perhaps someone can explain how I can set snapper not to snapshot tmp at all.
No I can't. But what I did was to adjust some settings in /etc/snapper/configs/root to reduce the number of snapshots taken, and delete old ones more often. This is my root config file: - ---code--- # subvolume to snapshot SUBVOLUME="/" # filesystem type FSTYPE="btrfs" # users and groups allowed to work with config ALLOW_USERS="" ALLOW_GROUPS="" # sync users and groups from ALLOW_USERS and ALLOW_GROUPS to .snapshots # directory SYNC_ACL="no" # start comparing pre- and post-snapshot in background after creating # post-snapshot BACKGROUND_COMPARISON="yes" # run daily number cleanup NUMBER_CLEANUP="yes" # limit for number cleanup NUMBER_MIN_AGE="1800" NUMBER_LIMIT="10" NUMBER_LIMIT_IMPORTANT="10" # create hourly snapshots TIMELINE_CREATE="no" # cleanup hourly snapshots after some time TIMELINE_CLEANUP="yes" # limits for timeline cleanup TIMELINE_MIN_AGE="1800" TIMELINE_LIMIT_HOURLY="10" TIMELINE_LIMIT_DAILY="10" TIMELINE_LIMIT_MONTHLY="10" TIMELINE_LIMIT_YEARLY="10" # cleanup empty pre-post-pairs EMPTY_PRE_POST_CLEANUP="yes" # limits for empty pre-post-pair cleanup EMPTY_PRE_POST_MIN_AGE="1800" - ---/code--- I haven't really delved any deeper than that, but with this setup the system has run OK for 6 months without overflowing any system folders, such as /tmp. Bob - -- Bob Williams System: Linux 3.16.7-7-desktop Distro: openSUSE 13.2 (x86_64) with KDE Development Platform: 4.14.3 Uptime: 06:00am up 7:55, 3 users, load average: 0.16, 0.05, 0.06 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlTZGroACgkQ0Sr7eZJrmU5yjwCfT8DpEBtCkZ0w1pKpwMWT4GMS d5oAmwW1+NZjSRJ3It+BThNyncB+GN51 =J3Y6 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 09/02/2015 21:38, Bob Williams a écrit :
No I can't. But what I did was to adjust some settings in /etc/snapper/configs/root to reduce the number of snapshots taken, and delete old ones more often.
may be a good idea. just now, I did "snapper delete-config" and "snapper create-config /" then reboot change what is différent from defaults:
This is my root config file:
- ---code---
NUMBER_LIMIT="10"
was 50
# create hourly snapshots TIMELINE_CREATE="no"
was yes and we will see what happen. anyway I never used this snapshot system. by the way I still do not know if my problem have anything to do with all this :-( anyway, I will be pretty quiet for 3 weeks, in 12 hours I fly to LA. See you at scale in sunday 22 :-) thanks jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, 9 Feb 2015 21:19, John Andersen
On 2/9/2015 8:20 AM, Bob Williams wrote:
On 09/02/15 12:00, jdd wrote:
Le 09/02/2015 12:07, Bernhard Voelker a écrit : [snip] Yes, I've had to reduce the frequency of snapper as well.
Much as I hate to repartition I was thinking of doing so to get tmp out of Btrfs, because Everytime I burn a CD/DVD huge tmp files are created. It got so bad that I moved K3Bs temp working directory to my a subdirectory in my home directory which solved that problem for now.
But JDD is on to something here, and that is tat with Btrfs you are never sure how much room you have, and the normal disk reporting tools have to be read very carefully. They should probably be rewritten to take Btrfs into account.
Meanwhile perhaps someone can explain how I can set snapper not to snapshot tmp at all.
create a file "/etc/snapper/filters/tmp.txt" with the content: [code] /tmp/* /tmp/.??* /var/tmp/* /var/tmp/.??* [/code] In short: specify the files / directories to exclude. Just "/tmp" does not work somehow (maybe b/c subvolume?). The why and how is somewhere in the snapper docu, bust I can not remember where anymore. Sorry. - Yamaban.
On 02/09/2015 03:52 PM, Yamaban wrote:
The why and how is somewhere in the snapper docu, bust I can not remember where anymore. Sorry.
Ah, thank you. Now I know what to google for I can find it :-) -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, 9 Feb 2015 22:11, Anton Aylward
On 02/09/2015 03:52 PM, Yamaban wrote:
The why and how is somewhere in the snapper docu, bust I can not remember where anymore. Sorry.
Ah, thank you. Now I know what to google for I can find it :-)
https://www.google.com/search?q=linux+snapper+filter https://forums.opensuse.org/showthread.php/476706-Snapper-possible-to-exclud... http://snapper.io/manpages/snapper.html (search for "Filters") - Yamaban. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/09/2015 12:52 PM, Yamaban wrote:
create a file "/etc/snapper/filters/tmp.txt" with the content: [code] /tmp/* /tmp/.??* /var/tmp/* /var/tmp/.??* [/code]
I'll give that a try. -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/09/2015 03:19 PM, John Andersen wrote:
Meanwhile perhaps someone can explain how I can set snapper not to snapshot tmp at all.
As I said. Having /tmp on a separate file system allows for a number of "security" advantages. I've already mentioned having tyat mounted nosuid,noexec, and how a runaway process that fills /tmp still leaves the rest of the system usable. Having a separate /home as well will let the user log in; we're back to the crazy idea of everything being the one BtrFS which I see as high risk. Yes, the optimization available with BtrFS is wonderful. So is the idea of having your system snapshotted, even /home, so that changes, for whatever reason, can be reversed. But do a proper risk analysis/needs analysis rather than just blue sky this. I can see changes to syustem config, rolling back an instalation of a new library to the old one, things like that, but at some point the 'everyting and the kitchen sink' gets to be too much. Yes, if snapper could easily exclude certain directories, specifying them in the config, some of these objections could be ignored. But I see nothing in any of the documents and man pages indicating this capability. Perhaps snapper doesn't need to be as complex as, say, rsync, but an exclusion list would be valuable. And I think /tmp should be a default in such a list. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 09/02/2015 21:19, John Andersen a écrit :
Meanwhile perhaps someone can explain how I can set snapper not to snapshot tmp at all.
don't know if it is related to /tmp at all. May be I just reclaimed some space and it sufficed to make it work, because now I'm stuck again and I can't do anything with this 13.2 install (I write now with the old 13.1 I revived :-( in 24h I quit for a three weeks holidays, not sure it will work before :-( thanks jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2/9/2015 1:52 PM, jdd wrote:
Le 09/02/2015 21:19, John Andersen a écrit :
Meanwhile perhaps someone can explain how I can set snapper not to snapshot tmp at all.
don't know if it is related to /tmp at all. May be I just reclaimed some space and it sufficed to make it work, because now I'm stuck again and I can't do anything with this 13.2 install (I write now with the old 13.1 I revived :-(
in 24h I quit for a three weeks holidays, not sure it will work before :-(
thanks jdd
maybe man snapper then check out cleanup option? -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/09/2015 05:35 AM, jdd wrote:
reboot, same. No X. most operation gives "no space left on device". after several reboots without enhancement, I went to /tmp, did rm -R *... and all ice ok now.
One reason to put /tmp of a separate partition/fs. The value of this from a number of aspects has been discussed many times in many forums dating back to long before Linux existed, probably before SUN existed. While there are advantages to having a single, global BtrFS that encompasses everything, it only applies if you can consolidate many aspects of the FS, ultimately make use of some functions that are possibly not available yet. I make use of ReiserFS and I like the idea of a well balanced B-Tree FS that avoids issues like i-node consumption. I like LVM & Reiser because I no longer have the issues I had back in, for example, the SCO UNIX days of trying to figure out the best allocation of disk space. Now I can grow and shrink and even overflow onto another spindle. But I don't think the ext4FS counts simply because I still have to, at mkfs time, decide on the balance between data and i-nodes just like I did in the days of Ken's V7 and the V7FS. I'm not saying tht ext4FS is a bad file system; it has features that ReiserFS lacks and if those are what you need then go that route. But I don't and I' happy with ReiserFS. I'd love to be happy with BtrFS. I have it working for me for the RootFS, but I have /home and /var and /tmp and /srv separate. For security reasons I also have /tmp mounted nosuid,noexec. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (6)
-
Anton Aylward -
Bernhard Voelker -
Bob Williams -
jdd -
John Andersen -
Yamaban