Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #257358 > unrolled thread
| Started by | Default User <hunguponcontent@gmail.com> |
|---|---|
| First post | 2023-04-18 17:00 +0200 |
| Last post | 2023-04-19 22:40 +0200 |
| Articles | 20 on this page of 81 — 19 participants |
Back to article view | Back to linux.debian.user
/etc/fstab question (problem)? Default User <hunguponcontent@gmail.com> - 2023-04-18 17:00 +0200
Re: /etc/fstab question (problem)? Charles Curley <charlescurley@charlescurley.com> - 2023-04-18 17:40 +0200
Re: /etc/fstab question (problem)? Max Nikulin <manikulin@gmail.com> - 2023-04-18 19:00 +0200
Re: /etc/fstab question (problem)? <tomas@tuxteam.de> - 2023-04-18 21:10 +0200
Re: /etc/fstab question (problem)? Tom Furie <tom@furie.org.uk> - 2023-04-18 23:20 +0200
Re: /etc/fstab question (problem)? <tomas@tuxteam.de> - 2023-04-19 06:40 +0200
tmp on tmpfs Max Nikulin <manikulin@gmail.com> - 2023-04-19 08:20 +0200
Re: tmp on tmpfs <tomas@tuxteam.de> - 2023-04-19 08:40 +0200
Re: tmp on tmpfs Nicolas George <george@nsup.org> - 2023-04-19 09:00 +0200
Re: tmp on tmpfs tomas@tuxteam.de - 2023-04-19 10:00 +0200
Re: tmp on tmpfs Celejar <celejar@gmail.com> - 2023-04-24 18:20 +0200
Re: tmp on tmpfs <tomas@tuxteam.de> - 2023-04-24 19:10 +0200
Re: tmp on tmpfs Celejar <celejar@gmail.com> - 2023-04-24 19:40 +0200
Re: tmp on tmpfs Celejar <celejar@gmail.com> - 2023-04-24 18:20 +0200
Re: tmp on tmpfs Max Nikulin <manikulin@gmail.com> - 2023-04-19 13:10 +0200
Re: tmp on tmpfs <tomas@tuxteam.de> - 2023-04-19 20:10 +0200
Re: tmp on tmpfs songbird <songbird@anthive.com> - 2023-04-20 15:00 +0200
Re: tmp on tmpfs Vincent Lefevre <vincent@vinc17.net> - 2023-04-20 16:20 +0200
Re: tmp on tmpfs <tomas@tuxteam.de> - 2023-04-20 16:30 +0200
Re: tmp on tmpfs Vincent Lefevre <vincent@vinc17.net> - 2023-04-20 17:20 +0200
Re: tmp on tmpfs Jeffrey Walton <noloader@gmail.com> - 2023-04-20 16:30 +0200
Re: tmp on tmpfs <tomas@tuxteam.de> - 2023-04-20 16:40 +0200
Re: /etc/fstab question (problem)? songbird <songbird@anthive.com> - 2023-04-18 18:00 +0200
Re: /etc/fstab question (problem)? David Christensen <dpchrist@holgerdanske.com> - 2023-04-18 22:10 +0200
Re: /etc/fstab question (problem)? Default User <hunguponcontent@gmail.com> - 2023-04-18 23:50 +0200
Re: /etc/fstab question (problem)? Greg Wooledge <greg@wooledge.org> - 2023-04-19 00:00 +0200
Re: /etc/fstab question (problem)? David Christensen <dpchrist@holgerdanske.com> - 2023-04-19 02:00 +0200
Re: /etc/fstab question (problem)? Default User <hunguponcontent@gmail.com> - 2023-04-19 03:20 +0200
Re: /etc/fstab question (problem)? Charles Curley <charlescurley@charlescurley.com> - 2023-04-19 04:50 +0200
Re: /etc/fstab question (problem)? David Christensen <dpchrist@holgerdanske.com> - 2023-04-19 05:00 +0200
Re: /etc/fstab question (problem)? David Wright <deblis@lionunicorn.co.uk> - 2023-04-19 05:10 +0200
Re: /etc/fstab question (problem)? Stefan Monnier <monnier@iro.umontreal.ca> - 2023-04-19 05:20 +0200
Re: /etc/fstab question (problem)? David Christensen <dpchrist@holgerdanske.com> - 2023-04-19 11:20 +0200
Re: /etc/fstab question (problem)? Max Nikulin <manikulin@gmail.com> - 2023-04-19 13:10 +0200
Re: /etc/fstab question (problem)? Default User <hunguponcontent@gmail.com> - 2023-04-19 22:10 +0200
Re: /etc/fstab question (problem)? David Wright <deblis@lionunicorn.co.uk> - 2023-04-19 22:40 +0200
Re: /etc/fstab question (problem)? Default User <hunguponcontent@gmail.com> - 2023-04-19 23:00 +0200
Re: /etc/fstab question (problem)? Default User <hunguponcontent@gmail.com> - 2023-04-19 23:10 +0200
Re: /etc/fstab question (problem)? davidson <davidson@freevolt.org> - 2023-04-20 01:50 +0200
Re: /etc/fstab question (problem)? Default User <hunguponcontent@gmail.com> - 2023-04-20 03:50 +0200
Re: /etc/fstab question (problem)? songbird <songbird@anthive.com> - 2023-04-20 15:10 +0200
Re: /etc/fstab question (problem)? rhkramer@gmail.com - 2023-04-21 11:10 +0200
Re: /etc/fstab question (problem)? Greg Wooledge <greg@wooledge.org> - 2023-04-21 13:20 +0200
gitification (was Re: /etc/fstab question (problem)? songbird <songbird@anthive.com> - 2023-04-20 15:00 +0200
Re: gitification (was Re: /etc/fstab question (problem)? Stefan Monnier <monnier@iro.umontreal.ca> - 2023-04-20 15:40 +0200
Re: gitification (was Re: /etc/fstab question (problem)? songbird <songbird@anthive.com> - 2023-04-20 20:40 +0200
Re: gitification (was Re: /etc/fstab question (problem)? Stefan Monnier <monnier@iro.umontreal.ca> - 2023-04-20 22:10 +0200
Re: gitification (was Re: /etc/fstab question (problem)? songbird <songbird@anthive.com> - 2023-04-21 00:50 +0200
Re: gitification (was Re: /etc/fstab question (problem)? Jeremy Ardley <jeremy@ardley.org> - 2023-04-21 01:10 +0200
Re: gitification (was Re: /etc/fstab question (problem)? songbird <songbird@anthive.com> - 2023-04-21 19:50 +0200
Re: gitification (was Re: /etc/fstab question (problem)? Jeremy Ardley <jeremy@ardley.org> - 2023-04-20 15:40 +0200
Re: gitification (was Re: /etc/fstab question (problem)? Max Nikulin <manikulin@gmail.com> - 2023-04-20 17:30 +0200
Re: gitification (was Re: /etc/fstab question (problem)? songbird <songbird@anthive.com> - 2023-04-20 20:30 +0200
Re: gitification (was Re: /etc/fstab question (problem)? Max Nikulin <manikulin@gmail.com> - 2023-04-22 08:40 +0200
Re: gitification (was Re: /etc/fstab question (problem)? David Christensen <dpchrist@holgerdanske.com> - 2023-04-20 22:50 +0200
Re: gitification (was Re: /etc/fstab question (problem)? songbird <songbird@anthive.com> - 2023-04-21 00:50 +0200
Re: gitification (was Re: /etc/fstab question (problem)? David Christensen <dpchrist@holgerdanske.com> - 2023-04-21 04:40 +0200
Re: /etc/fstab question (problem)? Dan Ritter <dsr@randomstring.org> - 2023-04-19 22:40 +0200
Re: /etc/fstab question (problem)? David Christensen <dpchrist@holgerdanske.com> - 2023-04-19 23:10 +0200
Re: /etc/fstab question (problem)? Default User <hunguponcontent@gmail.com> - 2023-04-19 23:30 +0200
Re: /etc/fstab question (problem)? David Christensen <dpchrist@holgerdanske.com> - 2023-04-20 00:10 +0200
Re: /etc/fstab question (problem)? David Christensen <dpchrist@holgerdanske.com> - 2023-04-20 00:20 +0200
[SOLVED] Re: /etc/fstab question (problem)? Default User <hunguponcontent@gmail.com> - 2023-04-20 02:30 +0200
Re: [SOLVED] Re: /etc/fstab question (problem)? David Christensen <dpchrist@holgerdanske.com> - 2023-04-20 03:00 +0200
Re: /etc/fstab question (problem)? Max Nikulin <manikulin@gmail.com> - 2023-04-21 17:20 +0200
Re: /etc/fstab question (problem)? David Christensen <dpchrist@holgerdanske.com> - 2023-04-22 00:50 +0200
Re: /etc/fstab question (problem)? David Wright <deblis@lionunicorn.co.uk> - 2023-04-22 17:30 +0200
Re: /etc/fstab question (problem)? David Christensen <dpchrist@holgerdanske.com> - 2023-04-23 04:00 +0200
Re: /etc/fstab question (problem)? David Wright <deblis@lionunicorn.co.uk> - 2023-04-23 06:20 +0200
Re: /etc/fstab question (problem)? David Christensen <dpchrist@holgerdanske.com> - 2023-04-23 10:20 +0200
Re: /etc/fstab question (problem)? Celejar <celejar@gmail.com> - 2023-04-24 18:30 +0200
Re: /etc/fstab question (problem)? David Wright <deblis@lionunicorn.co.uk> - 2023-04-25 15:00 +0200
old memory sticks (was Re: /etc/fstab question (problem)? songbird <songbird@anthive.com> - 2023-04-23 17:20 +0200
[SOLVED]: old memory sticks songbird <songbird@anthive.com> - 2023-04-24 03:50 +0200
Re: /etc/fstab question (problem)? songbird <songbird@anthive.com> - 2023-04-20 15:10 +0200
Re: /etc/fstab question (problem)? Max Nikulin <manikulin@gmail.com> - 2023-04-20 17:20 +0200
Re: /etc/fstab question (problem)? David Wright <deblis@lionunicorn.co.uk> - 2023-04-21 06:30 +0200
Re: /etc/fstab question (problem)? <tomas@tuxteam.de> - 2023-04-21 06:50 +0200
Re: /etc/fstab question (problem)? Default User <hunguponcontent@gmail.com> - 2023-04-20 16:30 +0200
Re: /etc/fstab question (problem)? David Wright <deblis@lionunicorn.co.uk> - 2023-04-19 22:40 +0200
Re: /etc/fstab question (problem)? Default User <hunguponcontent@gmail.com> - 2023-04-19 22:40 +0200
Page 1 of 5 [1] 2 3 4 5 Next page →
| From | Default User <hunguponcontent@gmail.com> |
|---|---|
| Date | 2023-04-18 17:00 +0200 |
| Subject | /etc/fstab question (problem)? |
| Message-ID | <GlUYh-2So8-5@gated-at.bofh.it> |
Hey, I have a strange situation! I just realized that my /tmp partition is not being mounted at startup. Instead, I think the filesystem may be allocating space in another partition (maybe /root?) for tmp stuff. I would like to return to the prior setup, where the /tmp partition is mounted at startup, and is used for the tmp stuff. Can I do so without trashing my system, and having to reinstall from scratch. Note: I have current system bakups using Timeshift, and current data (/home/[user]) backups using Borgbackup. And I can image the ssd with Clonezilla, or even dd, if I have to. But I would prefer not to go through the hassle of doing so, if it is not really needed. I am running Debian 11 Stable (Bullseye). My computer has a single internal 256 Gb ssd. I am using Gnome Version 3.38.5 as my desktop environment. uname -a: Linux [host name] 6.0.0-0.deb11.6-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.0.12-1~bpo11+1 (2022-12-19) x86_64 GNU/Linux mount: sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) udev on /dev type devtmpfs (rw,nosuid,relatime,size=3907040k,nr_inodes=976760,mode=755,inode64) devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=788500k,mode=755,inode64) /dev/nvme0n1p2 on / type ext4 (rw,relatime,errors=remount-ro) securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,inode64) tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k,inode64) cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot) pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime) efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime) bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700) systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=29,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_i no=786) hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M) mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime) debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime) tracefs on /sys/kernel/tracing type tracefs (rw,nosuid,nodev,noexec,relatime) configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime) fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime) /dev/nvme0n1p3 on /var type ext4 (rw,relatime) /dev/nvme0n1p6 on /home type ext4 (rw,relatime) /dev/nvme0n1p1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortna me=mixed,utf8,errors=remount-ro) tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=788496k,nr_inodes=197124,mode=700,uid=10 00,gid=1000,inode64) gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000) portal on /run/user/1000/doc type fuse.portal (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000) Current /etc/fstab: # <file system> <mount point> <type> <options> <dump> <pass> UUID=4fdd4399-6267-404a-a292- cdc7761df3c9 / ext4 errors=remount-ro 0 1 UUID=26EE-0EF5 /boot/efi vfat umask=0077 0 1 UUID=00f0c2db-0490-4354-b949- f9af11a7f001 /home ext4 defaults 0 2 UUID=8bfeee23-9c09-45b7-a73e- bd2ff43e207c /var ext4 defaults 0 2 UUID=e2a56ec3-99d4-4b40-9aa4- 24975143cdc7 none swap sw 0 0 Original /etc/fstab: # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # systemd generates mount units based on this file, see systemd.mount(5). # Please run 'systemctl daemon-reload' after making changes here. # # <file system> <mount point> <type> <options> <dump> <pass> # / was on /dev/nvme0n1p2 during installation UUID=4fdd4399-6267-404a-a292-cdc7761df3c9 / ext4 errors=remount-ro 0 1 # /boot/efi was on /dev/nvme0n1p1 during installation UUID=26EE-0EF5 /boot/efi vfat umask=0077 0 1 # /home was on /dev/nvme0n1p6 during installation UUID=00f0c2db-0490-4354-b949-f9af11a7f001 /home ext4 defaults 0 2 # /tmp was on /dev/nvme0n1p5 during installation UUID=6a105a72-f5d5-441b-b926-1e405151ee84 /tmp ext4 defaults 0 2 # /var was on /dev/nvme0n1p3 during installation UUID=8bfeee23-9c09-45b7-a73e-bd2ff43e207c /var ext4 defaults 0 2 # swap was on /dev/nvme0n1p4 during installation UUID=e2a56ec3-99d4-4b40-9aa4-24975143cdc7 none swap sw 0 0 ls -lahFi /etc/fstab: 522243 -rw-r--r-- 1 root root 368 Apr 3 17:01 /etc/fstab ls -lahFi /etc/fstab.original: 522547 -rw-r--r-- 1 root root 1.3K Mar 11 12:02 /etc/fstab.original lsblk: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT nvme0n1 259:0 0 238.5G 0 disk ├─nvme0n1p1 259:1 0 512M 0 part /boot/efi ├─nvme0n1p2 259:2 0 23.3G 0 part / ├─nvme0n1p3 259:3 0 9.3G 0 part /var ├─nvme0n1p4 259:4 0 977M 0 part [SWAP] ├─nvme0n1p5 259:5 0 1.9G 0 part └─nvme0n1p6 259:6 0 202.6G 0 part /home blkid: /dev/nvme0n1p1: UUID="26EE-0EF5" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="c0b4b1bb-bdf3-4066-b75a-f3cf56186e27" /dev/nvme0n1p2: UUID="4fdd4399-6267-404a-a292-cdc7761df3c9" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="706ab20c-ea65-4c25-a632- b7858550f966" /dev/nvme0n1p3: UUID="8bfeee23-9c09-45b7-a73e-bd2ff43e207c" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="0831f4bf-98fc-4189-a3cb- fc2781e580fb" /dev/nvme0n1p4: UUID="e2a56ec3-99d4-4b40-9aa4-24975143cdc7" TYPE="swap" PARTUUID="b32e1385-6518-4d1d-9181-66d31929c7ab" /dev/nvme0n1p5: UUID="6a105a72-f5d5-441b-b926-1e405151ee84" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="834502f5-08b3-42ad-a322- cf86732f8155" /dev/nvme0n1p6: UUID="00f0c2db-0490-4354-b949-f9af11a7f001" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="40721dda-02ba-49a1-abfc- b624fc739d9f" What to do? And if further information is needed, please let me know, and I will try to get it for you. Thanks!
[toc] | [next] | [standalone]
| From | Charles Curley <charlescurley@charlescurley.com> |
|---|---|
| Date | 2023-04-18 17:40 +0200 |
| Message-ID | <GlVAZ-2SQy-13@gated-at.bofh.it> |
| In reply to | #257358 |
On Tue, 18 Apr 2023 10:59:19 -0400 Default User <hunguponcontent@gmail.com> wrote: > What to do? I suspect that what you need to do is: 1) Preserve the current contents of /tmp, 2) Adjust fstab to include the /tmp partition, 3) Mount the /tmp partition 4) Restore the contents of /tmp You should probably do all of this in single user mode so you don't have other processes changing things while you're doing this. In multi-user mode, a process might have a tmp file open, which could also cause problems. All of this assumes that the backup from step 1 will fit onto the /tmp partition. Otherwise you may have to do some manual trimming. 1) Use tar or equivalent to preserve the current contents of /tmp. Then delete the contents of /tmp. Your Timeshift backups might be recent enough; check that they include everything currently in /tmp. 2) Copy the lines for /tmp from fstab.original to fstab. Ensure that the UUIDs are correct, and that you are specifying the partition you want. Check to see if you are missing any other partitions while you are at it. 3) Mount the /tmp partition. You will likely find that there are old files in the partition. You can probably delete them, but the more paranoid types will preserve them first. 4) Restore the contents of /tmp from the backup you made in step 1. Good luck! -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
[toc] | [prev] | [next] | [standalone]
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2023-04-18 19:00 +0200 |
| Message-ID | <GlWQp-2Txe-3@gated-at.bofh.it> |
| In reply to | #257360 |
On 18/04/2023 22:37, Charles Curley wrote: > 1) Preserve the current contents of /tmp, > 2) Adjust fstab to include the /tmp partition, > 3) Mount the /tmp partition > 4) Restore the contents of /tmp Some issues may arise due to files (regular ones, already deleted, sockets, fifos) opened by running services. /tmp is specific in the sense that no files are assumed to survive after reboot. I think, it is better to add the entry for tmp to /etc/fstab and to reboot. As a final step / may be bind mounted to some other directory to remove remaining files (to avoid wasting of disk space) or to move them to new location if you do something special, so it is necessary to keep some files in /tmp.
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2023-04-18 21:10 +0200 |
| Message-ID | <GlYSd-2V2L-1@gated-at.bofh.it> |
| In reply to | #257360 |
[Multipart message — attachments visible in raw view] — view raw
On Tue, Apr 18, 2023 at 09:37:51AM -0600, Charles Curley wrote: > On Tue, 18 Apr 2023 10:59:19 -0400 > Default User <hunguponcontent@gmail.com> wrote: > > > What to do? > > I suspect that what you need to do is: > > 1) Preserve the current contents of /tmp, > > 2) Adjust fstab to include the /tmp partition, > > 3) Mount the /tmp partition > > 4) Restore the contents of /tmp Since Debian erases /tmp at each boot anyway: wouldn't it be much easier to set up an entry in fstab along the lines of tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0 (assuming you want a tmpfs there, replace by suitable partition, options, etc)... and wait for the next reboot to pick it up? No need to preserve anything, then. Cheers -- t
[toc] | [prev] | [next] | [standalone]
| From | Tom Furie <tom@furie.org.uk> |
|---|---|
| Date | 2023-04-18 23:20 +0200 |
| Message-ID | <Gm0U1-2Wha-3@gated-at.bofh.it> |
| In reply to | #257374 |
[Multipart message — attachments visible in raw view] — view raw
On Tue, Apr 18, 2023 at 09:00:00PM +0200, tomas@tuxteam.de wrote: > Since Debian erases /tmp at each boot anyway: wouldn't it be > much easier to set up an entry in fstab along the lines of > > tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0 > > (assuming you want a tmpfs there, replace by suitable partition, > options, etc)... and wait for the next reboot to pick it up? That gives a memory backed /tmp, which, depending on resources/requirements may be more or less suitable, for some definition of "suitable". Cheers, Tom -- We are now enjoying total mutual interaction in an imaginary hot tub ...
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2023-04-19 06:40 +0200 |
| Message-ID | <Gm7LP-30oi-1@gated-at.bofh.it> |
| In reply to | #257377 |
[Multipart message — attachments visible in raw view] — view raw
On Tue, Apr 18, 2023 at 10:15:30PM +0100, Tom Furie wrote: > On Tue, Apr 18, 2023 at 09:00:00PM +0200, tomas@tuxteam.de wrote: > > Since Debian erases /tmp at each boot anyway: wouldn't it be > > much easier to set up an entry in fstab along the lines of > > > > tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0 > > > > (assuming you want a tmpfs there, replace by suitable partition, > > options, etc)... and wait for the next reboot to pick it up? > > That gives a memory backed /tmp, which, depending on resources/requirements > may be more or less suitable, for some definition of "suitable". That's what I meant above with "assuming you want a tmpfs..." Cheers -- t
[toc] | [prev] | [next] | [standalone]
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2023-04-19 08:20 +0200 |
| Subject | tmp on tmpfs |
| Message-ID | <Gm9kB-31ri-1@gated-at.bofh.it> |
| In reply to | #257387 |
On 19/04/2023 11:30, tomas@tuxteam.de wrote: > > That's what I meant above with "assuming you want a tmpfs..." Some arguments for consideration may be found in Summary: Moving /tmp to tmpfs makes it useless https://lists.debian.org/debian-devel/2012/06/msg00311.html That is linked from https://wiki.debian.org/SSDOptimization/#Reduction_of_SSD_write_frequency_via_RAMDISK Or another link: https://lwn.net/Articles/499410/ Jake Edge. Temporary files: RAM or disk? May 31, 2012
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2023-04-19 08:40 +0200 |
| Subject | Re: tmp on tmpfs |
| Message-ID | <Gm9DX-31x1-1@gated-at.bofh.it> |
| In reply to | #257388 |
[Multipart message — attachments visible in raw view] — view raw
On Wed, Apr 19, 2023 at 01:15:01PM +0700, Max Nikulin wrote: > On 19/04/2023 11:30, tomas@tuxteam.de wrote: > > > > That's what I meant above with "assuming you want a tmpfs..." > > Some arguments for consideration may be found in > > Summary: Moving /tmp to tmpfs makes it useless > https://lists.debian.org/debian-devel/2012/06/msg00311.html > > That is linked from https://wiki.debian.org/SSDOptimization/#Reduction_of_SSD_write_frequency_via_RAMDISK What I didn't like from the post is that it doesn't clearly state the downsides. Too much handwaving and repetition that "there are downsides" (well, duh), that "some applications rely on... " (what?). Then he goes on to explain alternatives. There is one downside to /tmp on tmpfs: it eats RAM. You gotta have some of it (currently I've 9G free on / and 16G RAM). That's the only one I can read between the lines in the above linked post. Do you see any other? The upsides aren't that spectacular either. If you've enough RAM, file system caching is so good that tmpfs will only be marginally faster: The write path to the disk will be a bit clearer. There will be a bit less CPU usage if your /tmp would be otherwise on a LUKS partition (mine would). With a modern (2010s!) laptop not much to write home about. Of course, I wouldn't propose to set it as a default for a distro. Cheers -- t
[toc] | [prev] | [next] | [standalone]
| From | Nicolas George <george@nsup.org> |
|---|---|
| Date | 2023-04-19 09:00 +0200 |
| Subject | Re: tmp on tmpfs |
| Message-ID | <Gm9Xj-31Dl-5@gated-at.bofh.it> |
| In reply to | #257389 |
tomas@tuxteam.de (12023-04-19): > What I didn't like from the post is that it doesn't clearly > state the downsides. Too much handwaving and repetition that > "there are downsides" (well, duh), that "some applications > rely on... " (what?). Then he goes on to explain alternatives. “If I can't write gigabytes files, it's completely and utterly useless” is what I managed to read. I am not that surprised to find this level of argumentation in a text that announces its unbalanced conclusion in the title. Like all those “foobar considered harmful” essays: they usually blame a caricature of the other side, they argue against the worst possible version of the idea and thus miss the points of their proponents. I have only a limited sympathy for the self-styled rational “community”, but their principle of “steelmaning” the other side argument before trying to reply is a good one. > The upsides aren't that spectacular either. If you've enough > RAM, file system caching is so good that tmpfs will only be > marginally faster: The write path to the disk will be a bit > clearer. There will be a bit less CPU usage if your /tmp would > be otherwise on a LUKS partition (mine would). Another minor difference that can be a minor upside or downside depending on the use case: with a tmpfs, the files disappear when the computer is turned off, with a real filesystem they disappear when it is turned on. (I do not know if Debian has provisions to format a /tmp partition with an ephemeral encryption key on boot, like it has for the swap.) Regards, -- Nicolas George
[toc] | [prev] | [next] | [standalone]
| From | tomas@tuxteam.de |
|---|---|
| Date | 2023-04-19 10:00 +0200 |
| Subject | Re: tmp on tmpfs |
| Message-ID | <GmaTn-32bf-1@gated-at.bofh.it> |
| In reply to | #257390 |
[Multipart message — attachments visible in raw view] — view raw
On Wed, Apr 19, 2023 at 08:55:25AM +0200, Nicolas George wrote: > tomas@tuxteam.de (12023-04-19): > > What I didn't like from the post [...] > I am not that surprised to find this level of argumentation in a text > that announces its unbalanced conclusion in the title [...] I wouldn't be so harsh, but yes, one gets the impression that the author wants to reach that conclusion. I'd agree with them on not chosing that option by default, though. [...] > Another minor difference that can be a minor upside or downside > depending on the use case: with a tmpfs, the files disappear when the > computer is turned off, with a real filesystem they disappear when it is > turned on. Definitely. If you care about minimising data leak opportunities, keeping /tmp in an encrypted partition seems mandatory. > (I do not know if Debian has provisions to format a /tmp partition with > an ephemeral encryption key on boot, like it has for the swap.) This would be a nice thing, yes (but we know that /tmp is, by default, on the root partition). One case where tmpfs for /tmp makes a ton of sense is when you want to have most things read only (or read mostly), because your devices die from too much writes (the Raspi/SD pattern, for example -- note that I wrote SD, not SSD: no monster thread on that, please ;-) Cheers -- t
[toc] | [prev] | [next] | [standalone]
| From | Celejar <celejar@gmail.com> |
|---|---|
| Date | 2023-04-24 18:20 +0200 |
| Subject | Re: tmp on tmpfs |
| Message-ID | <Go750-4dUU-5@gated-at.bofh.it> |
| In reply to | #257391 |
On Wed, 19 Apr 2023 09:52:23 +0200 tomas@tuxteam.de wrote: ... > One case where tmpfs for /tmp makes a ton of sense is when you want > to have most things read only (or read mostly), because your devices > die from too much writes (the Raspi/SD pattern, for example -- note > that I wrote SD, not SSD: no monster thread on that, please ;-) To be fair to the post [0] mentioned earlier, while the subject line was provocative, the post itself explicitly acknowledges that tmpfs for /tmp does make sense in some cases, although you may disagree that they're as "rare" as it claims :) "Mounting /tmp to tmpfs may be a good thing in some rare cases, but it's a bad default. It breaks a lot of things and, which is more important, brings nothing good." [0] https://lists.debian.org/debian-devel/2012/06/msg00311.html -- Celejar
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2023-04-24 19:10 +0200 |
| Subject | Re: tmp on tmpfs |
| Message-ID | <Go7Rn-4eq8-9@gated-at.bofh.it> |
| In reply to | #257535 |
[Multipart message — attachments visible in raw view] — view raw
On Mon, Apr 24, 2023 at 12:16:36PM -0400, Celejar wrote: > On Wed, 19 Apr 2023 09:52:23 +0200 > tomas@tuxteam.de wrote: [...] > "Mounting /tmp to tmpfs may be a good thing in some rare cases, but it's > a bad default. It breaks a lot of things and, which is more important, > brings nothing good." "A lot of things" means here: it can run out of space. That's it. Any other downsides? Cheers -- t
[toc] | [prev] | [next] | [standalone]
| From | Celejar <celejar@gmail.com> |
|---|---|
| Date | 2023-04-24 19:40 +0200 |
| Subject | Re: tmp on tmpfs |
| Message-ID | <Go8kp-4ezF-3@gated-at.bofh.it> |
| In reply to | #257541 |
On Mon, 24 Apr 2023 19:02:30 +0200 <tomas@tuxteam.de> wrote: > On Mon, Apr 24, 2023 at 12:16:36PM -0400, Celejar wrote: > > On Wed, 19 Apr 2023 09:52:23 +0200 > > tomas@tuxteam.de wrote: > > [...] > > > "Mounting /tmp to tmpfs may be a good thing in some rare cases, but it's > > a bad default. It breaks a lot of things and, which is more important, > > brings nothing good." > > "A lot of things" means here: it can run out of space. That's it. > > Any other downsides? No. What the author means is that lots of different applications and use cases can break badly with /tmp on tmpfs - see the '"/tmp on tmpfs is bad" quotes' section of the post: https://lists.debian.org/debian-devel/2012/06/msg00311.html (BTW, I really think that you should avoid snipping the link to the post that we're discussing from your replies.) -- Celejar
[toc] | [prev] | [next] | [standalone]
| From | Celejar <celejar@gmail.com> |
|---|---|
| Date | 2023-04-24 18:20 +0200 |
| Subject | Re: tmp on tmpfs |
| Message-ID | <Go750-4dUU-1@gated-at.bofh.it> |
| In reply to | #257390 |
On Wed, 19 Apr 2023 08:55:25 +0200 Nicolas George <george@nsup.org> wrote: ... > (I do not know if Debian has provisions to format a /tmp partition with > an ephemeral encryption key on boot, like it has for the swap.) It apparently does not, and apparently other distributions do not as well. Here's a post on the CentOS Wiki describing how to do it, but it involves a (small) unofficial, homegrown script: https://wiki.centos.org/HowTos/EncryptTmpSwapHome I wonder why this is not a standard option provided by distributions? -- Celejar
[toc] | [prev] | [next] | [standalone]
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2023-04-19 13:10 +0200 |
| Subject | Re: tmp on tmpfs |
| Message-ID | <GmdRf-347G-5@gated-at.bofh.it> |
| In reply to | #257389 |
On 19/04/2023 13:34, tomas@tuxteam.de wrote: > On Wed, Apr 19, 2023 at 01:15:01PM +0700, Max Nikulin wrote: >> Summary: Moving /tmp to tmpfs makes it useless >> https://lists.debian.org/debian-devel/2012/06/msg00311.html >> >> That is linked from https://wiki.debian.org/SSDOptimization/#Reduction_of_SSD_write_frequency_via_RAMDISK > > What I didn't like from the post is that it doesn't clearly > state the downsides. Particular user may run applications requiring more space in /tmp than is configured by default for RAM disk. Examples are image manipulation, processing scientific data. The thread contains links to earlier discussions. I admit that I have more free RAM + buffers than free space on / as well, but it is a conscious choice. That is a link that I had. I do not have another one with a better balanced opinion. My point that the suggestion may lead beginners to trouble, so they should be warned. Notice that debian wiki recommends tmp.mount systemd unit instead of /etc/fstab line. Unsure if provides more flexibility or other advantages. P.S. Arbitrary time may be invested in optimization attempts. There are interesting features like swap in RAM (compressed memory pages). Some people get better performance for tasks like compiling chrome. Some can not achieve it.
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2023-04-19 20:10 +0200 |
| Subject | Re: tmp on tmpfs |
| Message-ID | <GmkpH-37Xs-3@gated-at.bofh.it> |
| In reply to | #257396 |
[Multipart message — attachments visible in raw view] — view raw
On Wed, Apr 19, 2023 at 06:00:53PM +0700, Max Nikulin wrote: > On 19/04/2023 13:34, tomas@tuxteam.de wrote: > > On Wed, Apr 19, 2023 at 01:15:01PM +0700, Max Nikulin wrote: > > > Summary: Moving /tmp to tmpfs makes it useless > > > https://lists.debian.org/debian-devel/2012/06/msg00311.html > > > > > > That is linked from https://wiki.debian.org/SSDOptimization/#Reduction_of_SSD_write_frequency_via_RAMDISK > > > > What I didn't like from the post is that it doesn't clearly > > state the downsides. > > Particular user may run applications requiring more space in /tmp than is > configured by default for RAM disk. Examples are image manipulation, > processing scientific data. The thread contains links to earlier > discussions. I admit that I have more free RAM + buffers than free space on > / as well, but it is a conscious choice. Definitely -- but this will happen to you whatever device you have backing your /tmp. Arguably, you'll be better off if /tmp has an own device than when sharing one with /. > That is a link that I had. I do not have another one with a better balanced > opinion. My point that the suggestion may lead beginners to trouble, so they > should be warned. I don't mind opinions being unbalanced. They usually are (I know mine are). What miffed me was that they went over many paragraphs telling that it is bad whithout stating clearly /why/ they think it's bad. I had to pick up between the lines that they possibly mean you might run out of space. Well... yes? > Notice that debian wiki recommends tmp.mount systemd unit instead of > /etc/fstab line. Unsure if provides more flexibility or other advantages. No idea. No systemd over here. > P.S. Arbitrary time may be invested in optimization attempts. There are > interesting features like swap in RAM (compressed memory pages). Some people > get better performance for tasks like compiling chrome. Some can not achieve > it. Definitely,but we nerds gotta nerd :) Cheers -- t
[toc] | [prev] | [next] | [standalone]
| From | songbird <songbird@anthive.com> |
|---|---|
| Date | 2023-04-20 15:00 +0200 |
| Subject | Re: tmp on tmpfs |
| Message-ID | <GmC3f-3it0-1@gated-at.bofh.it> |
| In reply to | #257399 |
<tomas@tuxteam.de> wrote: ... > Definitely,but we nerds gotta nerd :) haha! :) songbird (nerd lives matta!
[toc] | [prev] | [next] | [standalone]
| From | Vincent Lefevre <vincent@vinc17.net> |
|---|---|
| Date | 2023-04-20 16:20 +0200 |
| Subject | Re: tmp on tmpfs |
| Message-ID | <GmDiF-3jmI-1@gated-at.bofh.it> |
| In reply to | #257389 |
On 2023-04-19 08:34:50 +0200, tomas@tuxteam.de wrote: > There is one downside to /tmp on tmpfs: it eats RAM. You gotta > have some of it (currently I've 9G free on / and 16G RAM). True, and when I used tmpfs in the past (in 2012), I got many failures due to lack of space (because of limited RAM). > That's the only one I can read between the lines in the above > linked post. Do you see any other? > > The upsides aren't that spectacular either. If you've enough > RAM, file system caching is so good that tmpfs will only be > marginally faster: The write path to the disk will be a bit > clearer. There will be a bit less CPU usage if your /tmp would > be otherwise on a LUKS partition (mine would). "marginally faster" is incorrect, but this probably depends on how fast the disk is. For the MPFR svn-to-git conversion with reposurgeon 2 years ago, I had to use /dev/shm (tmpfs) because it was awfully slow on /tmp (but the SSD disk was rather slow: the new one I got several months later was about 50 times as fast, IIRC). -- Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2023-04-20 16:30 +0200 |
| Subject | Re: tmp on tmpfs |
| Message-ID | <GmDsl-3jpR-1@gated-at.bofh.it> |
| In reply to | #257434 |
[Multipart message — attachments visible in raw view] — view raw
On Thu, Apr 20, 2023 at 04:13:48PM +0200, Vincent Lefevre wrote: [...] > "marginally faster" is incorrect, but this probably depends on > how fast the disk is. For the MPFR svn-to-git conversion with > reposurgeon 2 years ago, I had to use /dev/shm (tmpfs) because > it was awfully slow on /tmp (but the SSD disk was rather slow: > the new one I got several months later was about 50 times as > fast, IIRC). Hm. Interesting. I'd expected the buffer cache to paper over the difference (provided you have enough RAM for that, but since we are comparing that to putting things in tmpfs, by definition, you have :) Cheers -- t
[toc] | [prev] | [next] | [standalone]
| From | Vincent Lefevre <vincent@vinc17.net> |
|---|---|
| Date | 2023-04-20 17:20 +0200 |
| Subject | Re: tmp on tmpfs |
| Message-ID | <GmEeK-3jV5-3@gated-at.bofh.it> |
| In reply to | #257435 |
On 2023-04-20 16:19:41 +0200, tomas@tuxteam.de wrote: > On Thu, Apr 20, 2023 at 04:13:48PM +0200, Vincent Lefevre wrote: > > [...] > > > "marginally faster" is incorrect, but this probably depends on > > how fast the disk is. For the MPFR svn-to-git conversion with > > reposurgeon 2 years ago, I had to use /dev/shm (tmpfs) because > > it was awfully slow on /tmp (but the SSD disk was rather slow: > > the new one I got several months later was about 50 times as > > fast, IIRC). > > Hm. Interesting. I'd expected the buffer cache to paper over the > difference (provided you have enough RAM for that, but since we > are comparing that to putting things in tmpfs, by definition, you > have :) I think that the issue is that even though there is a buffer cache, data are written to disk, even when this is not needed for really temporary data. These write operations make the system slow when it tries to read other data from the disk. -- Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
[toc] | [prev] | [next] | [standalone]
Page 1 of 5 [1] 2 3 4 5 Next page →
Back to top | Article view | linux.debian.user
csiph-web