(Of course, now that I've done this stunt, I'm rsync'ing the tree onto
my NAS, so I'll have it after the reboot.)
And there you go: doing Linux stunts, so you don't have to.
$ df -h .
Filesystem Size Used Avail Use% Mounted on
tmpfs 126G 542M 126G 1% /dev/shm
What do you think? Is it worth it to try building Linux
on a ramdisk?
6.8.7 is out now, so I thought I'd try it:
$ time -p make -j 32
[...]
real 432.09
user 11085.32
sys 2520.37
That's with a "kitchen sink" build using a .config that
originally came from Linux Mint's "lowlatency" sources.
(To set it up, I unpacked the tar file onto /dev/shm -- much
faster than if I'd tried to rsync the unpacked sources.)
After the build:
$ df -h .
Filesystem Size Used Avail Use% Mounted on
tmpfs 126G 23G 103G 19% /dev/shm
(Of course, now that I've done this stunt, I'm rsync'ing
the tree onto my NAS, so I'll have it after the reboot.)
And there you go: doing Linux stunts, so you don't have to.
vallor <vallor@cultnix.org> wrote at 23:41 this Wednesday (GMT):
$ df -h .
Filesystem Size Used Avail Use% Mounted on
tmpfs 126G 542M 126G 1% /dev/shm
What do you think? Is it worth it to try building Linux
on a ramdisk?
6.8.7 is out now, so I thought I'd try it:
$ time -p make -j 32
[...]
real 432.09
user 11085.32
sys 2520.37
That's with a "kitchen sink" build using a .config that
originally came from Linux Mint's "lowlatency" sources.
(To set it up, I unpacked the tar file onto /dev/shm -- much
faster than if I'd tried to rsync the unpacked sources.)
After the build:
$ df -h .
Filesystem Size Used Avail Use% Mounted on
tmpfs 126G 23G 103G 19% /dev/shm
(Of course, now that I've done this stunt, I'm rsync'ing
the tree onto my NAS, so I'll have it after the reboot.)
And there you go: doing Linux stunts, so you don't have to.
Isn't /tmp usually mounted as a ramdisk?
On Thu, 18 Apr 2024 14:50:03 -0000 (UTC), candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> wrote in <uvrbur$2ae33$1@dont-email.me>:
Isn't /tmp usually mounted as a ramdisk?
Some distros might do that. Linux Mint doesn't, and I don't advise it.
On Thu, 18 Apr 2024 14:50:03 -0000 (UTC), candycanearter07
<candycanearter07@candycanearter07.nomail.afraid> wrote in ><uvrbur$2ae33$1@dont-email.me>:
vallor <vallor@cultnix.org> wrote at 23:41 this Wednesday (GMT):
$ df -h .
Filesystem Size Used Avail Use% Mounted on
tmpfs 126G 542M 126G 1% /dev/shm
What do you think? Is it worth it to try building Linux
on a ramdisk?
6.8.7 is out now, so I thought I'd try it:
$ time -p make -j 32
[...]
real 432.09
user 11085.32
sys 2520.37
That's with a "kitchen sink" build using a .config that
originally came from Linux Mint's "lowlatency" sources.
(To set it up, I unpacked the tar file onto /dev/shm -- much
faster than if I'd tried to rsync the unpacked sources.)
After the build:
$ df -h .
Filesystem Size Used Avail Use% Mounted on
tmpfs 126G 23G 103G 19% /dev/shm
(Of course, now that I've done this stunt, I'm rsync'ing
the tree onto my NAS, so I'll have it after the reboot.)
And there you go: doing Linux stunts, so you don't have to.
Isn't /tmp usually mounted as a ramdisk?
Some distros might do that. Linux Mint doesn't, and I
don't advise it.
vallor <vallor@cultnix.org> wrote at 02:53 this Friday (GMT):
On Thu, 18 Apr 2024 14:50:03 -0000 (UTC), candycanearter07 >><candycanearter07@candycanearter07.nomail.afraid> wrote in >><uvrbur$2ae33$1@dont-email.me>:
vallor <vallor@cultnix.org> wrote at 23:41 this Wednesday (GMT):
$ df -h .
Filesystem Size Used Avail Use% Mounted on tmpfs 126G
542M 126G 1% /dev/shm
What do you think? Is it worth it to try building Linux on a
ramdisk?
6.8.7 is out now, so I thought I'd try it:
$ time -p make -j 32 [...]
real 432.09 user 11085.32 sys 2520.37
That's with a "kitchen sink" build using a .config that originally
came from Linux Mint's "lowlatency" sources.
(To set it up, I unpacked the tar file onto /dev/shm -- much faster
than if I'd tried to rsync the unpacked sources.)
After the build:
$ df -h .
Filesystem Size Used Avail Use% Mounted on tmpfs 126G
23G 103G 19% /dev/shm
(Of course, now that I've done this stunt, I'm rsync'ing the tree
onto my NAS, so I'll have it after the reboot.)
And there you go: doing Linux stunts, so you don't have to.
Isn't /tmp usually mounted as a ramdisk?
Some distros might do that. Linux Mint doesn't, and I don't advise it.
$ findmnt /tmp
TARGET SOURCE FSTYPE OPTIONS /tmp tmpfs tmpfs rw,nosuid,nodev,size=8043524k,nr_inodes=1048576,inode64
Mine does at least.
On Fri, 19 Apr 2024 13:30:02 -0000 (UTC), candycanearter07
<candycanearter07@candycanearter07.nomail.afraid> wrote in ><uvtrkq$312kp$1@dont-email.me>:
vallor <vallor@cultnix.org> wrote at 02:53 this Friday (GMT):
On Thu, 18 Apr 2024 14:50:03 -0000 (UTC), candycanearter07 >>><candycanearter07@candycanearter07.nomail.afraid> wrote in >>><uvrbur$2ae33$1@dont-email.me>:
vallor <vallor@cultnix.org> wrote at 23:41 this Wednesday (GMT):
$ df -h .
Filesystem Size Used Avail Use% Mounted on tmpfs 126G >>>>> 542M 126G 1% /dev/shm
What do you think? Is it worth it to try building Linux on a
ramdisk?
6.8.7 is out now, so I thought I'd try it:
$ time -p make -j 32 [...]
real 432.09 user 11085.32 sys 2520.37
That's with a "kitchen sink" build using a .config that originally
came from Linux Mint's "lowlatency" sources.
(To set it up, I unpacked the tar file onto /dev/shm -- much faster
than if I'd tried to rsync the unpacked sources.)
After the build:
$ df -h .
Filesystem Size Used Avail Use% Mounted on tmpfs 126G >>>>> 23G 103G 19% /dev/shm
(Of course, now that I've done this stunt, I'm rsync'ing the tree
onto my NAS, so I'll have it after the reboot.)
And there you go: doing Linux stunts, so you don't have to.
Isn't /tmp usually mounted as a ramdisk?
Some distros might do that. Linux Mint doesn't, and I don't advise it.
$ findmnt /tmp
TARGET SOURCE FSTYPE OPTIONS /tmp tmpfs tmpfs
rw,nosuid,nodev,size=8043524k,nr_inodes=1048576,inode64
Mine does at least.
Interesting. What distribution are you using?
My concern would be filling it up, but that's probably
just my "old school" thinking from back in the day when
computers had much less memory.
$ findmnt /tmp
TARGET SOURCE FSTYPE OPTIONS /tmp tmpfs tmpfs rw,nosuid,nodev,size=8043524k,nr_inodes=1048576,inode64
Mine does at least.
On Fri, 19 Apr 2024 02:53:05 -0000 (UTC), vallor wrote:
On Thu, 18 Apr 2024 14:50:03 -0000 (UTC), candycanearter07
<candycanearter07@candycanearter07.nomail.afraid> wrote in
<uvrbur$2ae33$1@dont-email.me>:
Isn't /tmp usually mounted as a ramdisk?
Some distros might do that. Linux Mint doesn't, and I don't advise it.
It’s your choice. Stuff in /tmp is not expected to have a long lifetime. /var/tmp is for things you would like to last longer, but still aren’t
that fussed about.
The whole point about temporary files is it’s not the end of the world
if they get deleted.
ssh-agent's socket lives in a subdirectory in /tmp. Really should live
in /run somewhere. Looks like it can be steered by changing the TMPDIR environment variable...
On our companies user-access shell server, each user has their own /tmp
in their own chroot.
On our companies user-access shell server, each user has their own /tmp
in their own chroot.
On Mon, 22 Apr 2024 02:03:57 -0000 (UTC), vallor wrote:
ssh-agent's socket lives in a subdirectory in /tmp. Really should live
in /run somewhere. Looks like it can be steered by changing the TMPDIR
environment variable...
The logical place for per-user stuff would be /run/user/«userid», as per systemd conventions.
On our companies user-access shell server, each user has their own /tmp
in their own chroot.
I once had to set up a file-access server for a client that had to support both old-style insecure FTP and also SFTP (with the ultimate aim, of
course, of transitioning all their customers from the former to the
latter). Setting up a per-user chroot that would work with both was ...
quite a challenge ...
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 307 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 63:29:26 |
| Calls: | 6,915 |
| Files: | 12,379 |
| Messages: | 5,431,547 |