Re: Using TMPFS for /tmp and /var/run?
On Fri, 30 Mar 2012, Chris Rees wrote: On 30 Mar 2012 14:26, sth...@nethelp.no wrote: However, if you always want to use tmpfs instead of stable storage, please do not. Some people expect /tmp to be persistent. This is why /etc/defaults/rc.conf has clear_tmp_enable=NO. Changing this would break the POLA. This is a mistake. The default should be clear_tmp_enable=YES if only to uncover those broken configurations that expect /tmp to be persistent. If you want to break POLA and make a lot of people angry, sure. Otherwise no. I would very much like an example of where /tmp is expected to persist. Chris Yes, I'm a month behind on my mailing list reading and this conversation is probably over, but I do have a personal example. In my periodic.conf, I have: daily_clean_tmps_enable=YES daily_clean_tmps_days=30 I tend to have many distractions and work on many projects at the same time. I don't always know when I'm finished. Sometimes I just lose interest. I often don't remember to clean up after myself. These settings in periodic.conf allow me to set up temporary workspaces in /tmp. If I keep working on a project, my files remain. If I forget about it for a month, periodic will clean up my mess. If someday the default behavior were changed to make /tmp a memory-mounted filesystem or to clean it out on every reboot, I think I could set daily_clean_tmps_dirs to another directory and move my sandbox someplace else. I would very much appreciate some warning, but this would not be a problem for me. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Using TMPFS for /tmp and /var/run?
On 28 Apr 2012 19:04, Luke Dean lu...@pobox.com wrote: On Fri, 30 Mar 2012, Chris Rees wrote: On 30 Mar 2012 14:26, sth...@nethelp.no wrote: However, if you always want to use tmpfs instead of stable storage, please do not. Some people expect /tmp to be persistent. This is why /etc/defaults/rc.conf has clear_tmp_enable=NO. Changing this would break the POLA. This is a mistake. The default should be clear_tmp_enable=YES if only to uncover those broken configurations that expect /tmp to be persistent. If you want to break POLA and make a lot of people angry, sure. Otherwise no. I would very much like an example of where /tmp is expected to persist. Chris Yes, I'm a month behind on my mailing list reading and this conversation is probably over, but I do have a personal example. In my periodic.conf, I have: daily_clean_tmps_enable=YES daily_clean_tmps_days=30 I tend to have many distractions and work on many projects at the same time. I don't always know when I'm finished. Sometimes I just lose interest. I often don't remember to clean up after myself. These settings in periodic.conf allow me to set up temporary workspaces in /tmp. If I keep working on a project, my files remain. If I forget about it for a month, periodic will clean up my mess. If someday the default behavior were changed to make /tmp a memory-mounted filesystem or to clean it out on every reboot, I think I could set daily_clean_tmps_dirs to another directory and move my sandbox someplace else. I would very much appreciate some warning, but this would not be a problem for me. You should use /var/tmp for that, or another custom directory if you want your files safe. Chris ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Using TMPFS for /tmp and /var/run?
On (04/04/2012 06:38), David Wolfskill wrote:
On Wed, Apr 04, 2012 at 12:50:35PM +0300, Gleb Kurtsou wrote:
...
tmpfs-32bit-size_max.patch.txt should fix the problem. I don't have i386
installations to test it myself.
Do you run PAE kernel? Could you try filling up /tmp at least to 10g.
...
After updating source to r233868, applying the patch, then updating,
here are the results of my testing so far (not using PAE).
Summary: as before, I believe that the patch didn't hurt anything, but
it also doesn't restrict the usable size of /tmp to the specified size
(from /etc/fstab):
I've checked on i386 and patch worked as expected, but it required
previous patch. I've combined both patches. Could you try it.
Thanks,
Gleb.
Script started on Wed Apr 4 06:23:25 2012
g1-227(10.0-C)[1] _do
uid=0(root) gid=0(wheel) groups=0(wheel),5(operator)
/dev/ada0s2a on / (ufs, local, soft-updates)
devfs on /dev (devfs, local, multilabel)
tmpfs on /tmp (tmpfs, local)
/dev/ada0s2d on /usr (ufs, local, soft-updates)
/dev/ada0s4e on /var (ufs, local, soft-updates)
/dev/ada0s4g on /common (ufs, local, soft-updates)
fdescfs on /dev/fd (fdescfs)
FreeBSD g1-227.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #2 233868M:
Wed Apr 4 06:02:25 PDT 2012
r...@g1-227.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386
Wed Apr 4 06:23:27 PDT 2012
Removing old libraries
Please be sure no application still uses those libraries, else you
can not start such an application. Consult UPDATING for more
information regarding how to cope with the removal/revision bump
of a specific library.
Old libraries removed
Wed Apr 4 06:23:28 PDT 2012
g1-227(10.0-C)[2] exit
Script done on Wed Apr 4 06:23:29 2012
Script started on Wed Apr 4 06:23:35 2012
g1-227(10.0-C)[1] df -hi /tmp
FilesystemSizeUsed Avail Capacity iused ifree %iused Mounted on
tmpfs 23G 12k 23G 0% 17 2.1G0% /tmp
g1-227(10.0-C)[2] grep tmpfs /etc/fstab
# tmpfs /tmptmpfs rw,size=2147483648 0
0
tmpfs /tmptmpfs rw,size=8g 0 0
g1-227(10.0-C)[3] ls -lhT /bkp/tmp/test
-rw-r--r-- 1 david wheel 8.0G Mar 25 10:42:49 2012 /bkp/tmp/test
g1-227(10.0-C)[4] dd bs=1m if=!$ of=/tmp/test
dd bs=1m if=/bkp/tmp/test of=/tmp/test
8192+0 records in
8192+0 records out
8589934592 bytes transferred in 186.178099 secs (46138266 bytes/sec)
g1-227(10.0-C)[5] df -hi /tmp
FilesystemSizeUsed Avail Capacity iused ifree %iused Mounted on
tmpfs 23G8.0G 15G35% 18 2.1G0% /tmp
g1-227(10.0-C)[6] dd bs=1m if=/bkp/tmp/test of=/tmp/test1
8192+0 records in
8192+0 records out
8589934592 bytes transferred in 220.254916 secs (3868 bytes/sec)
g1-227(10.0-C)[7] df -hi /tmp
FilesystemSizeUsed Avail Capacity iused ifree %iused Mounted on
tmpfs 23G 16G7.0G70% 19 2.1G0% /tmp
g1-227(10.0-C)[8] exit
Script done on Wed Apr 4 06:33:12 2012
g1-227(10.0-C)[5]
Peace,
david
--
David H. Wolfskillda...@catwhisker.org
Depriving a girl or boy of an opportunity for education is evil.
See http://www.catwhisker.org/~david/publickey.gpg for my public key.
diff --git a/sys/fs/tmpfs/tmpfs.h b/sys/fs/tmpfs/tmpfs.h
index efa7c6d..3fc72ab 100644
--- a/sys/fs/tmpfs/tmpfs.h
+++ b/sys/fs/tmpfs/tmpfs.h
@@ -337,11 +337,10 @@ struct tmpfs_mount {
* system, set during mount time. This variable must never be
* used directly as it may be bigger than the current amount of
* free memory; in the extreme case, it will hold the SIZE_MAX
-* value. Instead, use the TMPFS_PAGES_MAX macro. */
+* value. */
size_t tm_pages_max;
- /* Number of pages in use by the file system. Cannot be bigger
-* than the value returned by TMPFS_PAGES_MAX in any case. */
+ /* Number of pages in use by the file system. */
size_t tm_pages_used;
/* Pointer to the node representing the root directory of this
@@ -486,58 +485,32 @@ int tmpfs_truncate(struct vnode *, off_t);
* Memory management stuff.
*/
-/* Amount of memory pages to reserve for the system (e.g., to not use by
+/*
+ * Amount of memory pages to reserve for the system (e.g., to not use by
* tmpfs).
- * XXX: Should this be tunable through sysctl, for instance? */
-#define TMPFS_PAGES_RESERVED (4 * 1024 * 1024 / PAGE_SIZE)
+ */
+#define TMPFS_PAGES_MINRESERVED(4 * 1024 * 1024 / PAGE_SIZE)
/*
- * Returns information about the number of available memory pages,
- * including physical and virtual ones.
- *
- * Remember to remove TMPFS_PAGES_RESERVED from the returned value to avoid
- * excessive memory usage.
- *
+ * Number of reserved swap pages should not be lower than
+ * swap_pager_almost_full high water mark.
*/
Re: Using TMPFS for /tmp and /var/run?
On Thu, Apr 05, 2012 at 10:43:04AM +0300, Gleb Kurtsou wrote:
...
Summary: as before, I believe that the patch didn't hurt anything, but
it also doesn't restrict the usable size of /tmp to the specified size
(from /etc/fstab):
I've checked on i386 and patch worked as expected, but it required
previous patch. I've combined both patches. Could you try it.
To be very clear, I've attached the output from
cd /sys svn diff
Peace,
david
--
David H. Wolfskill da...@catwhisker.org
Depriving a girl or boy of an opportunity for education is evil.
See http://www.catwhisker.org/~david/publickey.gpg for my public key.
Index: fs/tmpfs/tmpfs.h
===
--- fs/tmpfs/tmpfs.h(revision 233868)
+++ fs/tmpfs/tmpfs.h(working copy)
@@ -337,11 +337,10 @@
* system, set during mount time. This variable must never be
* used directly as it may be bigger than the current amount of
* free memory; in the extreme case, it will hold the SIZE_MAX
-* value. Instead, use the TMPFS_PAGES_MAX macro. */
+* value. */
size_t tm_pages_max;
- /* Number of pages in use by the file system. Cannot be bigger
-* than the value returned by TMPFS_PAGES_MAX in any case. */
+ /* Number of pages in use by the file system. */
size_t tm_pages_used;
/* Pointer to the node representing the root directory of this
@@ -486,58 +485,32 @@
* Memory management stuff.
*/
-/* Amount of memory pages to reserve for the system (e.g., to not use by
+/*
+ * Amount of memory pages to reserve for the system (e.g., to not use by
* tmpfs).
- * XXX: Should this be tunable through sysctl, for instance? */
-#define TMPFS_PAGES_RESERVED (4 * 1024 * 1024 / PAGE_SIZE)
+ */
+#define TMPFS_PAGES_MINRESERVED(4 * 1024 * 1024 / PAGE_SIZE)
/*
- * Returns information about the number of available memory pages,
- * including physical and virtual ones.
- *
- * Remember to remove TMPFS_PAGES_RESERVED from the returned value to avoid
- * excessive memory usage.
- *
+ * Number of reserved swap pages should not be lower than
+ * swap_pager_almost_full high water mark.
*/
-static __inline size_t
-tmpfs_mem_info(void)
-{
+#define TMPFS_SWAP_MINRESERVED 1024
- return (swap_pager_avail + cnt.v_free_count + cnt.v_cache_count);
-}
+size_t tmpfs_mem_avail(void);
-/* Returns the maximum size allowed for a tmpfs file system. This macro
- * must be used instead of directly retrieving the value from tm_pages_max.
- * The reason is that the size of a tmpfs file system is dynamic: it lets
- * the user store files as long as there is enough free memory (including
- * physical memory and swap space). Therefore, the amount of memory to be
- * used is either the limit imposed by the user during mount time or the
- * amount of available memory, whichever is lower. To avoid consuming all
- * the memory for a given mount point, the system will always reserve a
- * minimum of TMPFS_PAGES_RESERVED pages, which is also taken into account
- * by this macro (see above). */
static __inline size_t
-TMPFS_PAGES_MAX(struct tmpfs_mount *tmp)
+tmpfs_pages_used(struct tmpfs_mount *tmp)
{
- size_t freepages;
+ const size_t node_size = sizeof(struct tmpfs_node) +
+ sizeof(struct tmpfs_dirent);
+ size_t meta_pages;
- freepages = tmpfs_mem_info();
- freepages -= freepages TMPFS_PAGES_RESERVED ?
- freepages : TMPFS_PAGES_RESERVED;
-
- return MIN(tmp-tm_pages_max, freepages + tmp-tm_pages_used);
+ meta_pages = howmany((uintmax_t)tmp-tm_nodes_inuse * node_size,
+ PAGE_SIZE);
+ return (meta_pages + tmp-tm_pages_used);
}
-/* Returns the available space for the given file system. */
-#define TMPFS_META_PAGES(tmp) (howmany((tmp)-tm_nodes_inuse * (sizeof(struct
tmpfs_node) \
- + sizeof(struct tmpfs_dirent)), PAGE_SIZE))
-#define TMPFS_FILE_PAGES(tmp) ((tmp)-tm_pages_used)
-
-#define TMPFS_PAGES_AVAIL(tmp) (TMPFS_PAGES_MAX(tmp) \
- TMPFS_META_PAGES(tmp)+TMPFS_FILE_PAGES(tmp)? \
- TMPFS_PAGES_MAX(tmp) - TMPFS_META_PAGES(tmp) \
- - TMPFS_FILE_PAGES(tmp):0)
-
#endif
/* - */
Index: fs/tmpfs/tmpfs_subr.c
===
--- fs/tmpfs/tmpfs_subr.c (revision 233868)
+++ fs/tmpfs/tmpfs_subr.c (working copy)
@@ -59,6 +59,76 @@
SYSCTL_NODE(_vfs, OID_AUTO, tmpfs, CTLFLAG_RW, 0, tmpfs file system);
+static long tmpfs_swap_reserved = TMPFS_SWAP_MINRESERVED * 2;
+
+static long tmpfs_pages_reserved = TMPFS_PAGES_MINRESERVED;
+
+static int
+sysctl_mem_reserved(SYSCTL_HANDLER_ARGS)
+{
+ int error;
+ long pages, bytes, reserved;
+
+
Re: Using TMPFS for /tmp and /var/run?
On Wed, Apr 04, 2012 at 12:50:35PM +0300, Gleb Kurtsou wrote: ... tmpfs-32bit-size_max.patch.txt should fix the problem. I don't have i386 installations to test it myself. Do you run PAE kernel? Could you try filling up /tmp at least to 10g. ... After updating source to r233868, applying the patch, then updating, here are the results of my testing so far (not using PAE). Summary: as before, I believe that the patch didn't hurt anything, but it also doesn't restrict the usable size of /tmp to the specified size (from /etc/fstab): Script started on Wed Apr 4 06:23:25 2012 g1-227(10.0-C)[1] _do uid=0(root) gid=0(wheel) groups=0(wheel),5(operator) /dev/ada0s2a on / (ufs, local, soft-updates) devfs on /dev (devfs, local, multilabel) tmpfs on /tmp (tmpfs, local) /dev/ada0s2d on /usr (ufs, local, soft-updates) /dev/ada0s4e on /var (ufs, local, soft-updates) /dev/ada0s4g on /common (ufs, local, soft-updates) fdescfs on /dev/fd (fdescfs) FreeBSD g1-227.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #2 233868M: Wed Apr 4 06:02:25 PDT 2012 r...@g1-227.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 Wed Apr 4 06:23:27 PDT 2012 Removing old libraries Please be sure no application still uses those libraries, else you can not start such an application. Consult UPDATING for more information regarding how to cope with the removal/revision bump of a specific library. Old libraries removed Wed Apr 4 06:23:28 PDT 2012 g1-227(10.0-C)[2] exit Script done on Wed Apr 4 06:23:29 2012 Script started on Wed Apr 4 06:23:35 2012 g1-227(10.0-C)[1] df -hi /tmp FilesystemSizeUsed Avail Capacity iused ifree %iused Mounted on tmpfs 23G 12k 23G 0% 17 2.1G0% /tmp g1-227(10.0-C)[2] grep tmpfs /etc/fstab # tmpfs /tmptmpfs rw,size=2147483648 0 0 tmpfs /tmptmpfs rw,size=8g 0 0 g1-227(10.0-C)[3] ls -lhT /bkp/tmp/test -rw-r--r-- 1 david wheel 8.0G Mar 25 10:42:49 2012 /bkp/tmp/test g1-227(10.0-C)[4] dd bs=1m if=!$ of=/tmp/test dd bs=1m if=/bkp/tmp/test of=/tmp/test 8192+0 records in 8192+0 records out 8589934592 bytes transferred in 186.178099 secs (46138266 bytes/sec) g1-227(10.0-C)[5] df -hi /tmp FilesystemSizeUsed Avail Capacity iused ifree %iused Mounted on tmpfs 23G8.0G 15G35% 18 2.1G0% /tmp g1-227(10.0-C)[6] dd bs=1m if=/bkp/tmp/test of=/tmp/test1 8192+0 records in 8192+0 records out 8589934592 bytes transferred in 220.254916 secs (3868 bytes/sec) g1-227(10.0-C)[7] df -hi /tmp FilesystemSizeUsed Avail Capacity iused ifree %iused Mounted on tmpfs 23G 16G7.0G70% 19 2.1G0% /tmp g1-227(10.0-C)[8] exit Script done on Wed Apr 4 06:33:12 2012 g1-227(10.0-C)[5] Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpUsQa4laxTF.pgp Description: PGP signature
Re: Using TMPFS for /tmp and /var/run?
On Mon, Apr 02, 2012 at 01:31:19PM +0300, Gleb Kurtsou wrote: ... You could try the patch attached. It adds support for size option suffixes (like 1g) and introduces swap limit (part of the older patch, not sure if it's any use). Patch is against 10-CURRENT. Older version: https://github.com/glk/freebsd-head/commit/3bd8f7d ... After building: FreeBSD g1-227.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #0 233772M: Mon Apr 2 05:42:48 PDT 2012 r...@g1-227.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 with the referenced patch, I ran with it for the bulk of my daily activities on the laptop yesterday, then (this morning), I performed a source upgrade to: FreeBSD g1-227.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #1 233835M: Tue Apr 3 07:07:39 PDT 2012 r...@g1-227.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 and nothing peculiar or unexpected happened at all. :-} As far as I can tell, the patch does no harm, and enables tmpfs size specifications to be more readily made and understood. Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpAiRgZuH2kX.pgp Description: PGP signature
Re: Using TMPFS for /tmp and /var/run?
jb jb.1234abcd at gmail.com writes: ... There are memory management subsystem considerations against utilizing tmpfs (memory + swap) for /tmp: ... - Out-of-Memory (OOM) killer Due to it, on heavy loaded systems processes dying on memory pressure. - Pterodactyl The next MM subsystem feature. An urban legend ... The final frontier ... jb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Using TMPFS for /tmp and /var/run?
On (29/03/2012 21:49), O. Hartmann wrote:
Am 03/29/12 18:14, schrieb David Wolfskill:
On Thu, Mar 29, 2012 at 04:18:06PM +0200, O. Hartmann wrote:
I was wondering if there are some objections using TMPFS for /tmp and
/var/run.
...
My question is whether there are objections using TMPFS for bot /tmp/
and /var/run/ at this stage on FreeBSD 10.0-CURRENT/amd64?
I have no experience using tmpfs for /var/run, but I have been using it
for /tmp for some time (mostly in i386, though).
While I use it quite successfully on machines with a small number of
folks actively busy -- e.g., my desktop; my laptop; my home machines), I
encountered some issues when I tried to do so on machines that were
intended for significantly heavier use. Specifically:
* Compared to an md-resident /tmp, a tmpfs-resident /tmp has much less
flexibility for specifying the size. Per mdconfig(8), the former
uses:
-s size
Size of the memory disk. Size is the number of 512 byte
sectors
unless suffixed with a b, k, m, g, or t which denotes byte,
kilo-
byte, megabyte, gigabyte and terabyte respectively. Options -a
and -t swap are implied if not specified.
while the latter uses:
sizeSpecifies the total file system size in bytes. If zero (the
default) or a value larger than SIZE_MAX - PAGE_SIZE is given,
the available amount of memory (including main memory and swap
space) will be used.
In this configuration, I would have preferred to have specified
about 10GB for /tmp. I wouldn't mind if it spilled to swap space,
but I certaianly didn't want it using 10GB of RAM -- especially since
the machines only had 6GB RAM.
Nor did I especially want *all* of the swap space used for /tmp. I
would have allocated (say) 20GB for swap. I wouldn't mind if half of
that were used for /tmp -- but a reason I allocate so much swap is
that I've seen what happens when a machine runs out of swap, and it
wasn't pretty.
In any case, effective maximum usable size for tmpfs involves SIZE_MAX
(~4G) PAGE_SIZE (4K, in my case).
size_t is 64-bit on 64-bit archs.
* Even when I went ahead and created a tmpfs for /tmp, I'd get ENOSPC
whenever I tried to allocate anything on it -- until I dropped the
size specification to 2G (2**32). Well, 2GB for /tmp just wasn't at
all likely to be useful for my purposes in this case.
Are you using ZFS alongside tmpfs? It should be fixed in 9-STABLE.
So I continue to use tmpfs for /tmp for machines with fewer folks
logging in, but I'm a bit less enthusiastic about its use unless the
workload and other requirements are fairly carefully considered
beforehand.
Peace,
david
It seems there is only one switch which determines the size of the tmpfs
in question (size) and there is no convenient way to say what amount of
RAM is being used before using the swap space. I'd like to have at least
a knob determining the limit of RAM being used.
There is no way to force tmpfs to use given amount of RAM only. It's VM
subsystem that decides what pages to swap. Although some tweaking for VM
to prefer swapping tmpfs pages prior to process pages would be nice.
You could try the patch attached. It adds support for size option suffixes
(like 1g) and introduces swap limit (part of the older patch, not sure
if it's any use).
Patch is against 10-CURRENT.
Older version: https://github.com/glk/freebsd-head/commit/3bd8f7d
Thanks,
Gleb.
On the other hand - my view of those things is really naiv. I think
having tmpfs isn't even a benefit in terms of security, it should also
offer a speedy access to files kept in memory, doesn't it?
Linux is using TMPFS filesystems a lot for these purposes. How do they
overcome restrictions of the size or not flloding RAM and/or swap?
Regards,
Oliver
diff --git a/sys/fs/tmpfs/tmpfs.h b/sys/fs/tmpfs/tmpfs.h
index efa7c6d..3fc72ab 100644
--- a/sys/fs/tmpfs/tmpfs.h
+++ b/sys/fs/tmpfs/tmpfs.h
@@ -337,11 +337,10 @@ struct tmpfs_mount {
* system, set during mount time. This variable must never be
* used directly as it may be bigger than the current amount of
* free memory; in the extreme case, it will hold the SIZE_MAX
-* value. Instead, use the TMPFS_PAGES_MAX macro. */
+* value. */
size_t tm_pages_max;
- /* Number of pages in use by the file system. Cannot be bigger
-* than the value returned by TMPFS_PAGES_MAX in any case. */
+ /* Number of pages in use by the file system. */
size_t tm_pages_used;
/* Pointer to the node representing the root directory of this
@@ -486,58 +485,32 @@ int tmpfs_truncate(struct vnode *, off_t);
* Memory management stuff.
*/
-/* Amount of memory pages to reserve for
Re: Using TMPFS for /tmp and /var/run?
I commonly use mfs for /var and /tmp. Sometimes even symlinking /var/tmp - /tmp to save ram. Mostly because I want nothing leftover in them on boot, and it's fast. rc/mtree/etc takes care of populating them. /, /boot, /usr and /usr/local are read-only. [nssswitch host.conf still needs fixed to deal with that] User and daemon writeables are on other mountpoints. Thus I don't have any persistent needs in mfs. No swap either. And cron is wiped out too. No real problems. There used to be some msgs emitted about rc populating it or rc being misordered using it. Those seem fixed. mfs is a lot more stable than it used to be. In fact, the crashes were what held me back till recently. Seems now I can hammer on it with dd, fsx and iozone and it won't die. Performance is fine whether under disk UFS+soft_updates or mfs. The options below are fine for creating either. I don't care about defaults... so long as both disk and ram options exist, I'm happy. All depends on how you use it. I like nice clean separation. Some (strange) people put everything in /. Oh well. I'd rather see the legacy /sys and /compat symlinks removed. rc_debug=YES rc_info=YES syslogd_flags=-sC root_rw_mount=NO tmpmfs_flags=-SM tmpsize=64m varmfs_flags=-SM varsize=128m ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Using TMPFS for /tmp and /var/run?
On Mon, Apr 02, 2012 at 01:31:19PM +0300, Gleb Kurtsou wrote: ... In any case, effective maximum usable size for tmpfs involves SIZE_MAX (~4G) PAGE_SIZE (4K, in my case). size_t is 64-bit on 64-bit archs. OK. Still, the requirement that the size specification be in bytes is awkward (in my experience) -- and I was using i386. * Even when I went ahead and created a tmpfs for /tmp, I'd get ENOSPC whenever I tried to allocate anything on it -- until I dropped the size specification to 2G (2**32). Well, 2GB for /tmp just wasn't at all likely to be useful for my purposes in this case. Are you using ZFS alongside tmpfs? It should be fixed in 9-STABLE. I have not tried ZFS yet. I don't expect to do so unless I switch to amd64. ... It seems there is only one switch which determines the size of the tmpfs in question (size) and there is no convenient way to say what amount of RAM is being used before using the swap space. I'd like to have at least a knob determining the limit of RAM being used. There is no way to force tmpfs to use given amount of RAM only. It's VM subsystem that decides what pages to swap. Although some tweaking for VM to prefer swapping tmpfs pages prior to process pages would be nice. You could try the patch attached. It adds support for size option suffixes (like 1g) and introduces swap limit (part of the older patch, not sure if it's any use). Patch is against 10-CURRENT. Older version: https://github.com/glk/freebsd-head/commit/3bd8f7d ... I'll plan to try this on a currrently-underutilized slice on my laptop, then -- thanks! :-) Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgp4RE09VWuHd.pgp Description: PGP signature
Re: Using TMPFS for /tmp and /var/run?
On Mon, Apr 02, 2012 at 01:31:19PM +0300, Gleb Kurtsou wrote: ... You could try the patch attached. It adds support for size option suffixes (like 1g) and introduces swap limit (part of the older patch, not sure if it's any use). Patch is against 10-CURRENT. Older version: https://github.com/glk/freebsd-head/commit/3bd8f7d OK; here's a summary of what I found so far, now running: FreeBSD g1-227.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #0 233772M: Mon Apr 2 05:42:48 PDT 2012 r...@g1-227.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 * First, the patch applied cleanly (via patch -p1). * Resulting sources build with no issues. * Prior specification I had in /etc/fstab: tmpfs/tmptmpfsrw,size=2147483648 00 worked same as before the patch; df -h /tmp reported a size of 2.0G. * Changing the above to read: tmpfs/tmptmpfsrw,size=2g 00 also provided the same result, so the unit-specification code looks as if it's working as expected. * I have 20G specified for swap, and 4G RAM (and, as above, I'm running i386). Changing the above tmpfs line in /etc/fstab to tmpfs/tmptmpfsrw,size=8g 00 (still) yields: g1-227(10.0-C)[3] df -h /tmp FilesystemSizeUsed Avail Capacity Mounted on tmpfs 23G 12k 23G 0%/tmp g1-227(10.0-C)[4] (Yes, I'm using a whopping total of 12kB while running X. I know of *very* few folks who use the window manager I prefer. :-}) I'll try exercising it a bit during the day at work report anything noteworthy. But so far, I see no evidence of regression, and there is some measure of usability improvement (IMO). So it's looking encouraging. :-) Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpCxjDuDVwUA.pgp Description: PGP signature
Re: Using TMPFS for /tmp and /var/run?
jb jb.1234abcd at gmail.com writes: ... Chuck Burns brea...@gmail.com 1:01 AM (16 hours ago) My experiences with using tmpfs as /tmp -- It works fine. until it doesn't. I've had mountpoints run out of space, checked df and the mountpoint had been reduced to something like 2 MiB TOTAL, with nothing free.. on a machine with 8GiB RAM.. however, rebooting restores the mount to around 2GiB.. but then after some heavy usage, the mountpoint once again starts shrinking in size. I've noticed this behavior in multiple versions of FreeBSD, and switched to using md instead, with no more issues. I'm not willing to use tmpfs until it's proven to be more stable than it was when I was using it. --- Chuck, plz check your posting to the list (I received it, which I reposted here). jb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Using TMPFS for /tmp and /var/run?
On 2 Apr 2012 16:47, jb jb.1234a...@gmail.com wrote: jb jb.1234abcd at gmail.com writes: ... Chuck Burns brea...@gmail.com 1:01 AM (16 hours ago) My experiences with using tmpfs as /tmp -- It works fine. until it doesn't. I've had mountpoints run out of space, checked df and the mountpoint had been reduced to something like 2 MiB TOTAL, with nothing free.. on a machine with 8GiB RAM.. however, rebooting restores the mount to around 2GiB.. but then after some heavy usage, the mountpoint once again starts shrinking in size. I've noticed this behavior in multiple versions of FreeBSD, and switched to using md instead, with no more issues. I'm not willing to use tmpfs until it's proven to be more stable than it was when I was using it. --- Chuck, plz check your posting to the list (I received it, which I reposted here). jb This is a known issue with ZFS. Is that your case? Chris ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Using TMPFS for /tmp and /var/run?
On (02/04/2012 06:26), David Wolfskill wrote:
On Mon, Apr 02, 2012 at 01:31:19PM +0300, Gleb Kurtsou wrote:
...
You could try the patch attached. It adds support for size option suffixes
(like 1g) and introduces swap limit (part of the older patch, not sure
if it's any use).
Patch is against 10-CURRENT.
Older version: https://github.com/glk/freebsd-head/commit/3bd8f7d
OK; here's a summary of what I found so far, now running:
FreeBSD g1-227.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #0 233772M:
Mon Apr 2 05:42:48 PDT 2012
r...@g1-227.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386
* First, the patch applied cleanly (via patch -p1).
* Resulting sources build with no issues.
* Prior specification I had in /etc/fstab:
tmpfs/tmptmpfsrw,size=214748364800
worked same as before the patch; df -h /tmp reported a size of 2.0G.
* Changing the above to read:
tmpfs/tmptmpfsrw,size=2g00
also provided the same result, so the unit-specification code looks
as if it's working as expected.
* I have 20G specified for swap, and 4G RAM (and, as above, I'm running
i386). Changing the above tmpfs line in /etc/fstab to
tmpfs/tmptmpfsrw,size=8g00
(still) yields:
g1-227(10.0-C)[3] df -h /tmp
FilesystemSizeUsed Avail Capacity Mounted on
tmpfs 23G 12k 23G 0%/tmp
g1-227(10.0-C)[4]
tmpfs-32bit-size_max.patch.txt should fix the problem. I don't have i386
installations to test it myself.
Do you run PAE kernel? Could you try filling up /tmp at least to 10g.
(Yes, I'm using a whopping total of 12kB while running X. I know of
*very* few folks who use the window manager I prefer. :-})
I'll try exercising it a bit during the day at work report anything
noteworthy. But so far, I see no evidence of regression, and there is
some measure of usability improvement (IMO). So it's looking
encouraging. :-)
Peace,
david
--
David H. Wolfskillda...@catwhisker.org
Depriving a girl or boy of an opportunity for education is evil.
See http://www.catwhisker.org/~david/publickey.gpg for my public key.
commit 44f68235e23ab4bababeafe07d31e07feabb84ba
Author: Gleb Kurtsou gleb.kurt...@gmail.com
Date: Tue Apr 3 00:02:33 2012 +0300
tmpfs: Support file system sizes up to 4GB*PAGE_SIZE on 32 bit archs
diff --git a/sys/fs/tmpfs/tmpfs_vfsops.c b/sys/fs/tmpfs/tmpfs_vfsops.c
index 29f2ca4..6b3ecc0 100644
--- a/sys/fs/tmpfs/tmpfs_vfsops.c
+++ b/sys/fs/tmpfs/tmpfs_vfsops.c
@@ -233,17 +233,13 @@ tmpfs_mount(struct mount *mp)
* allowed to use, based on the maximum size the user passed in
* the mount structure. A value of zero is treated as if the
* maximum available space was requested. */
- if (size_max PAGE_SIZE || size_max SIZE_MAX - PAGE_SIZE)
+ if (size_max PAGE_SIZE || size_max UINT64_MAX - PAGE_SIZE ||
+ (SIZE_MAX UINT64_MAX size_max / PAGE_SIZE = SIZE_MAX))
pages = SIZE_MAX;
else
pages = howmany(size_max, PAGE_SIZE);
MPASS(pages 0);
- if (pages SIZE_MAX / PAGE_SIZE)
- size_max = pages * PAGE_SIZE;
- else
- size_max = SIZE_MAX;
-
if (nodes_max = 3) {
if (pages INT_MAX / nodes_per_page)
nodes_max = pages * nodes_per_page;
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Using TMPFS for /tmp and /var/run?
On 4/2/2012 10:52 AM, Chris Rees wrote: This is a known issue with ZFS. Is that your case? Chris Yes. Interesting that it happens only with ZFS. and jb, thanks, I could've sworn I'd hit Reply to list - thanks for forwarding it for me. Chuck ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Using TMPFS for /tmp and /var/run?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/29/2012 13:52, Xin Li wrote: On 03/29/12 09:41, Chris Rees wrote: On 29 Mar 2012 16:49, O. Hartmann ohart...@mail.zedat.fu-berlin.de wrote: I was wondering if there are some objections using TMPFS for /tmp and /var/run. I figured out some problems with some rc.d scripts when using TMPFS for /var/run, samba and OpenLDAP do store some informations like PID in a subfolder of their own in /var/run, but the rc.d scripts are not checking properly the existence of the appropritae folder (unlike dbus and hald, they check properly!). I already submitted two PRs, but for SAMBA, my hack is trivial and obviously to clumsy, so it should be check properly. My question is whether there are objections using TMPFS for bot /tmp/ and /var/run/ at this stage on FreeBSD 10.0-CURRENT/amd64? Any rc script that complains about an empty /var/run is buggy- it should be assumed that it will be emptied on boot. Agreed. We may want a generic way of registering custom mtrees (or something) that creates the hierarchy on boot, by the way. Currently this has to be done by individual rc.d scripts if they need a separate directory. I think there is some confusion here, so hopefully I can help clear it up. For BASE rc.d scripts, definitions for needed subdirectories and their permissions for /var/run are located in /etc/mtree/BSD.var.dist, which is called by /etc/rc.d/var at boot time. Anything IN THE BASE that complains about a missing directory in /var/run needs to be fixed, and should be reported. For PORTS rc.d scripts, they are expected to create (or check for the existence of) the needed directories/permissions *in the script* (not at port/package install time, this is why). Any variations on that theme should also be reported. In short, there is nothing in rc.d (ports or base) that should fail if you start with an empty /var/run. If it does, it's a bug. Meanwhile, as much as I find it personally distasteful, I can't imagine us changing the default for clear_tmp_enable at this point. hth, Doug - -- This .signature sanitized for your protection -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBCAAGBQJPeiaxAAoJEFzGhvEaGryEefQH/14QUKTun4njDF6YHHPlBcqz 1Ky97Dlu3cka9rNee8y7aJWSK61mg/OjacjgViKrrA6isOg/wsaJ6qK9XCk1Npb/ ZKEvszPvdHcdy+XA78HS/UTa1Pqxx+H6UPiF2s0f80LkP468UthfszXXhw8jJbSh dWG9OluprWd/21iHco5S/V+i0zgcEHHkdWAT+N5+w4Cw8cUiVk+hV90YpUK9PnO4 bzfvqppP9tCdnt9J/q8bUwNy4iK3orfSMRZ5SFFpKqeUTI4fbY3CuZHsEXf1AXQI LhVlRoCa35exFv5k9ivJ3IJMorNsLSulXluCrULn38yvtlRSazWWFCcVha18mbs= =cPrk -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Using TMPFS for /tmp and /var/run?
On Sat, Mar 31, 2012 at 02:57:38AM +0200, deeptec...@gmail.com wrote: C. P. Ghost wrote: Not clearing /tmp on reboot has been the norm for way too long and it is too late to change now. We either evolve or be in a stalemate forever. It's not just POLA, it also involves deleting data of unaware users, and that should be avoided. Mounting on a directory (/tmp) does *not* clear that directory, so automatic data loss will not occur. Adrian Chadd wrote: One of those reasons people stick/stuck with BSD is that we don't go and change this stuff so quickly. Yes, it would be a total of ~20 years before we finally decided to switch to using TMPFS for /tmp. Changes that potentially break the POLA can be categorized; a change has a combination of the following properties: (1) the change fixes a bug (ie., the change is about something that should have been different in the first place, eg., the change fixes the misspelling of a command name) (2) the change can be prepared for (ie., enough time is given for the user base to slowly switch the new method of doing things) (3) the change is evolutional (ie., the change is based on a decision to yield a net benefit (not necessarily a benefit in all cases)) (4) the change has priorly been given room (ie., is expectable as defined by standards and the documentation) The TMPFS-for-/tmp change obviously falls into (4), and surely into (3). With the support of UPDATING entries, release notifications, and perhaps announcements, the change also falls into (2). Furthermore, using TMPFS for /tmp is analogous to adding assert()s to code. Noone is really breaking the POLA that much. The TMPFS-for-/var/run should not even bother anyone. Other than catching software that mistakenly assumes /tmp and/or /var/run is persistent, what are the CLEAR advantages for changing the default? Has consideration been paid to low-memory systems? I think this discussion is fast becoming a bikeshed and distracting people from real work on improving FreeBSD. Without clear advantages from a switch to tmpfs(5) or md(4) non-persistent storage the default should stay the same, especially on release branches. If people want that behaviour, the switches are already there and while I may have missed it, I don't believe there hasn't yet been suitable justification for making the change. Gary ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Using TMPFS for /tmp and /var/run?
Am Sun, 1 Apr 2012 09:40:25 -0400 schrieb Gary Palmer gpal...@freebsd.org: Other than catching software that mistakenly assumes /tmp and/or /var/run is persistent, what are the CLEAR advantages for changing the default? It's my understanding it improves performance in cases where lots of files are created and deleted in /tmp (and/or /var/tmp - sometimes software hard-codes these locations...). Out of my head, things like spamassassin and amavis/clamav come to mind. Maybe the pkg-message of these packages should be adjusted so that this is mentioned? OTOH, on new installs, a TMPFS could be used automatically if memory = 4GB. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Using TMPFS for /tmp and /var/run?
Rainer Duffner rainer at ultra-secure.de writes: Am Sun, 1 Apr 2012 09:40:25 -0400 schrieb Gary Palmer gpalmer at freebsd.org: Other than catching software that mistakenly assumes /tmp and/or /var/run is persistent, what are the CLEAR advantages for changing the default? It's my understanding it improves performance in cases where lots of files are created and deleted in /tmp (and/or /var/tmp - sometimes software hard-codes these locations...). ... OTOH, on new installs, a TMPFS could be used automatically if memory = 4GB. ... There are memory management subsystem considerations against utilizing tmpfs (memory + swap) for /tmp: - only part of the program needs to be in the memory for execution Delayed and hidden demand for memory. - demand paging Bring a page from swap into memory only when it is needed. Delayed and hidden demand for memory. - Copy-on-Write Initial sharing of memory by processes. Delayed and hidden demand for memory. - thrashing Excessive in/out swap utilization. Very high page-fault rate - low CPU utilization - OS thinks it can schedule more tasks - another process added for execution - memory overcommit Physical memory overcommit resulting in paging; swap space pre-reservation Due to it, on heavy loaded systems processes dying on memory pressure. - Out-of-Memory (OOM) killer Due to it, on heavy loaded systems processes dying on memory pressure. There is a potential for overlapping and multiplying effects from the above and possibly other factors. If somebody wants it, despite all dangers to efficiency and stability of their system, let them make that choice. After all, what real pros are known for is that they know why and how to customize their systems for a task. To offer it as a default setup is not called for, regardless of memory plus swap sizes. jb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Using TMPFS for /tmp and /var/run?
Adrian Chadd wrote: On 30 March 2012 17:57,deeptec...@gmail.com wrote: C. P. Ghost wrote: Not clearing /tmp on reboot has been the norm for way too long and it is too late to change now. We either evolve or be in a stalemate forever. No, you do it in a sensible, controlled fashion. Does anyone see a conflict between the last 2 statements? Gary Palmer wrote: Other than catching software that mistakenly assumes /tmp and/or /var/run is persistent, what are the CLEAR advantages for changing the default? Gearing towards more common systems in the modern world. Has consideration been paid to low-memory systems? I personally wouldn't use TMPFS, because I have a rather low amount of RAM (512MiB). ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Using TMPFS for /tmp and /var/run?
On Mon, 2 Apr 2012, deeptec...@gmail.com wrote: I personally wouldn't use TMPFS, because I have a rather low amount of RAM (512MiB). Depends on what you keep there. I've been trying it lately. For an X desktop running xfce, /tmp is only 332K. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Using TMPFS for /tmp and /var/run?
Am 29.03.2012 22:52, schrieb Eric van Gyzen: Respectfully, no. The default is to store /tmp in UFS, either in its own partition (with Auto Defaults) or in / (if no partition was created for it), and to refrain from clearing it at boot. Thus, although /tmp is not guaranteed to persist in theory, it is rather persistent in practice. My only point is: carefully consider the change in behavior of the default installation before breaking the POLA. How about using /var/tmp for the a little longer lived temporary stuff? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Using TMPFS for /tmp and /var/run?
Am 30.03.2012 21:36, schrieb Adrian Chadd: Let me tell you a story. Someone decided that ext4 could have a decent speed up if it implemented the posix standard for not flushing files on close(). After all, if you needed it to be guaranteed to be written to disk, you would call a flush routine first, before you called close(). So they did this. Then people testing out ext4 discovered that upon crash, their kde/gnome profiles were corrupted. Why? Because KDE/Gnome authors hadn't ever called flush before close(), and they weren't the only ones. They didn't read the standard, they only used the system and fixed bugs whenever their system behaved against their expectations. They didn't notice that the system was being different from the standard. Guess what ext4 did? :) ext4 sprouted an option (auto_da_alloc, when used with the proper data journalling option data=ordered) to support buggy software. Note that ext4 isn't pioneering the fsync() required semantics here, there are other precedents of 0-blocks in files after crash in Linux file systems, such as XFS. I'm oblivious to the current ext4 defaults WRT these semantics (and I haven't looked at vanilla kernels for a while anyways---distros might have changed default settings). ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Using TMPFS for /tmp and /var/run?
On 31/03/2012 03:05, Benjamin Kaduk wrote: P.S. I am somewhat unconvinced by this: http://wiki.debian.org/ReleaseGoals/RunDirectory Those who do not understand /var are condemned to reinvent it? -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey signature.asc Description: OpenPGP digital signature
Re: Using TMPFS for /tmp and /var/run?
On Mar 30, 2012 6:22 AM, Eric van Gyzen e...@vangyzen.net wrote: However, if you always want to use tmpfs instead of stable storage, please do not. Some people expect /tmp to be persistent. This is why /etc/defaults/rc.conf has clear_tmp_enable=NO. Changing this would break the POLA. This is a mistake. The default should be clear_tmp_enable=YES if only to uncover those broken configurations that expect /tmp to be persistent. I was going to say At least on -CURRENT but in reality it should be the default on -RELEASE too when it's clearly a bug to expect /tmp to be persistent. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Using TMPFS for /tmp and /var/run?
However, if you always want to use tmpfs instead of stable storage, please do not. Some people expect /tmp to be persistent. This is why /etc/defaults/rc.conf has clear_tmp_enable=NO. Changing this would break the POLA. This is a mistake. The default should be clear_tmp_enable=YES if only to uncover those broken configurations that expect /tmp to be persistent. If you want to break POLA and make a lot of people angry, sure. Otherwise no. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Using TMPFS for /tmp and /var/run?
On 30 Mar 2012 14:26, sth...@nethelp.no wrote: However, if you always want to use tmpfs instead of stable storage, please do not. Some people expect /tmp to be persistent. This is why /etc/defaults/rc.conf has clear_tmp_enable=NO. Changing this would break the POLA. This is a mistake. The default should be clear_tmp_enable=YES if only to uncover those broken configurations that expect /tmp to be persistent. If you want to break POLA and make a lot of people angry, sure. Otherwise no. I would very much like an example of where /tmp is expected to persist. Chris ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Using TMPFS for /tmp and /var/run?
O. Hartmann ohartman at zedat.fu-berlin.de writes: Am 03/29/12 18:14, schrieb David Wolfskill: On Thu, Mar 29, 2012 at 04:18:06PM +0200, O. Hartmann wrote: I was wondering if there are some objections using TMPFS for /tmp and /var/run. ... ... Linux is using TMPFS filesystems a lot for these purposes. How do they overcome restrictions of the size or not flloding RAM and/or swap? ... Read it before you make up your mind (there are real issues to consider): http://fedoraproject.org/wiki/Features/var-run-tmpfs http://fedoraproject.org/wiki/Talk:Features/var-run-tmpfs jb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Using TMPFS for /tmp and /var/run?
/tmp is used by eaccelerator for its cache. It's not required to persist but does prevent the need to regenerate everything after a reboot. Lucas Holt On Mar 30, 2012, at 10:43 AM, Chris Rees utis...@gmail.com wrote: On 30 Mar 2012 14:26, sth...@nethelp.no wrote: However, if you always want to use tmpfs instead of stable storage, please do not. Some people expect /tmp to be persistent. This is why /etc/defaults/rc.conf has clear_tmp_enable=NO. Changing this would break the POLA. This is a mistake. The default should be clear_tmp_enable=YES if only to uncover those broken configurations that expect /tmp to be persistent. If you want to break POLA and make a lot of people angry, sure. Otherwise no. I would very much like an example of where /tmp is expected to persist. Chris ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Using TMPFS for /tmp and /var/run?
The default should be clear_tmp_enable=YES if only to uncover those broken configurations that expect /tmp to be persistent. If you want to break POLA and make a lot of people angry, sure. Otherwise no. I would very much like an example of where /tmp is expected to persist. I don't have any examples of stuff being *dependent* on /tmp being persistent. However, given that it has been persistent with all the FreeBSD installations I have performed since 1995 or so, I would be *highly* surprised if this suddenly changed. POLA. (And these haven't been special installations in any way, just your plain vanilla sysinstall installations with either one / covering the whole disk, or /, /usr and /var on separate partitions.) Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Using TMPFS for /tmp and /var/run?
On Fri, Mar 30, 2012 at 3:18 PM, sth...@nethelp.no wrote: However, if you always want to use tmpfs instead of stable storage, please do not. Some people expect /tmp to be persistent. This is why /etc/defaults/rc.conf has clear_tmp_enable=NO. Changing this would break the POLA. This is a mistake. The default should be clear_tmp_enable=YES if only to uncover those broken configurations that expect /tmp to be persistent. If you want to break POLA and make a lot of people angry, sure. Otherwise no. I couldn't agree more. Not clearing /tmp on reboot has been the norm for way too long and it is too late to change now. It's not just POLA, it also involves deleting data of unaware users, and that should be avoided. Anyone willing to change policy w.r.t. /tmp can do so on their own machines. Nothing is preventing them from doing so. But by changing defaults, one should err on the side of caution and remain conservative, IMHO. -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Using TMPFS for /tmp and /var/run?
On 30 March 2012 17:31, C. P. Ghost cpgh...@cordula.ws wrote: On Fri, Mar 30, 2012 at 3:18 PM, sth...@nethelp.no wrote: However, if you always want to use tmpfs instead of stable storage, please do not. Some people expect /tmp to be persistent. This is why /etc/defaults/rc.conf has clear_tmp_enable=NO. Changing this would break the POLA. This is a mistake. The default should be clear_tmp_enable=YES if only to uncover those broken configurations that expect /tmp to be persistent. If you want to break POLA and make a lot of people angry, sure. Otherwise no. I couldn't agree more. Not clearing /tmp on reboot has been the norm for way too long and it is too late to change now. It's not just POLA, it also involves deleting data of unaware users, and that should be avoided. Anyone willing to change policy w.r.t. /tmp can do so on their own machines. Nothing is preventing them from doing so. But by changing defaults, one should err on the side of caution and remain conservative, IMHO. From man hier: /tmp/ temporary files that are not guaranteed to persist across system reboots This assumption that people often make 'People will be astonished by this'-- I would like to have someone speak up and actually say Yes, I use *temporary* directories for long-term storage rather than the assumption that they are around. Software that assumes this should be fixed, and it won't be until the bug is exposed (I'll look at eaccelerator-- it probably should store its cache in /var/db). Maintaining the status quo because of some hypothetical scenario isn't really productive. Chris ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Using TMPFS for /tmp and /var/run?
On Fri, Mar 30, 2012 at 05:56:06PM +, Chris Rees wrote: On 30 March 2012 17:31, C. P. Ghost cpgh...@cordula.ws wrote: On Fri, Mar 30, 2012 at 3:18 PM, sth...@nethelp.no wrote: However, if you always want to use tmpfs instead of stable storage, please do not. Some people expect /tmp to be persistent. This is why /etc/defaults/rc.conf has clear_tmp_enable=NO. Changing this would break the POLA. This is a mistake. The default should be clear_tmp_enable=YES if only to uncover those broken configurations that expect /tmp to be persistent. If you want to break POLA and make a lot of people angry, sure. Otherwise no. I couldn't agree more. Not clearing /tmp on reboot has been the norm for way too long and it is too late to change now. It's not just POLA, it also involves deleting data of unaware users, and that should be avoided. Anyone willing to change policy w.r.t. /tmp can do so on their own machines. Nothing is preventing them from doing so. But by changing defaults, one should err on the side of caution and remain conservative, IMHO. Well stated. From man hier: /tmp/ temporary files that are not guaranteed to persist across system reboots There is also a difference between not guaranteed to persist and knowingly blowing the files away by explictly clearing /tmp. PS: How many users of FreeBSD know that hier(7) exists? How many new users even know about man pages? -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Using TMPFS for /tmp and /var/run?
On 03/30/12 11:15, Steve Kargl wrote: On Fri, Mar 30, 2012 at 05:56:06PM +, Chris Rees wrote: On 30 March 2012 17:31, C. P. Ghost cpgh...@cordula.ws wrote: On Fri, Mar 30, 2012 at 3:18 PM, sth...@nethelp.no wrote: However, if you always want to use tmpfs instead of stable storage, please do not. Some people expect /tmp to be persistent. This is why /etc/defaults/rc.conf has clear_tmp_enable=NO. Changing this would break the POLA. This is a mistake. The default should be clear_tmp_enable=YES if only to uncover those broken configurations that expect /tmp to be persistent. If you want to break POLA and make a lot of people angry, sure. Otherwise no. I couldn't agree more. Not clearing /tmp on reboot has been the norm for way too long and it is too late to change now. It's not just POLA, it also involves deleting data of unaware users, and that should be avoided. Anyone willing to change policy w.r.t. /tmp can do so on their own machines. Nothing is preventing them from doing so. But by changing defaults, one should err on the side of caution and remain conservative, IMHO. Well stated. From man hier: /tmp/ temporary files that are not guaranteed to persist across system reboots There is also a difference between not guaranteed to persist and knowingly blowing the files away by explictly clearing /tmp. PS: How many users of FreeBSD know that hier(7) exists? How many new users even know about man pages? man hier is a unix standard. a new user will eventually find man pages if they're meant to, just as small turtles will eventually find the sea... In general you may receive some advantages by not blowing away /tmp such as better performance in programs that cache there, but my understanding (think historically in context of hier) is that *users* should not expect the *admin* to not blow away /tmp for space on a multiuser system. It might be there tomorrow, but it might not. Many larger multiuser systems had/have such folders, as many users = many crap files that some admin or script needs to clear to preserve storage for things that actually need to be stored. In some cases, the script would only clear it on Fridays in the middle of night, so temporary files might persist from say 1 week to a few hours...you were warned. Dunno, but tmpfs + unionfs for the ports tree is where it would really be awesome! Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Using TMPFS for /tmp and /var/run?
Let me tell you a story. Someone decided that ext4 could have a decent speed up if it implemented the posix standard for not flushing files on close(). After all, if you needed it to be guaranteed to be written to disk, you would call a flush routine first, before you called close(). So they did this. Then people testing out ext4 discovered that upon crash, their kde/gnome profiles were corrupted. Why? Because KDE/Gnome authors hadn't ever called flush before close(), and they weren't the only ones. They didn't read the standard, they only used the system and fixed bugs whenever their system behaved against their expectations. They didn't notice that the system was being different from the standard. Guess what ext4 did? :) Don't mis-estimate POLA. Adrian On 30 March 2012 10:56, Chris Rees cr...@freebsd.org wrote: On 30 March 2012 17:31, C. P. Ghost cpgh...@cordula.ws wrote: On Fri, Mar 30, 2012 at 3:18 PM, sth...@nethelp.no wrote: However, if you always want to use tmpfs instead of stable storage, please do not. Some people expect /tmp to be persistent. This is why /etc/defaults/rc.conf has clear_tmp_enable=NO. Changing this would break the POLA. This is a mistake. The default should be clear_tmp_enable=YES if only to uncover those broken configurations that expect /tmp to be persistent. If you want to break POLA and make a lot of people angry, sure. Otherwise no. I couldn't agree more. Not clearing /tmp on reboot has been the norm for way too long and it is too late to change now. It's not just POLA, it also involves deleting data of unaware users, and that should be avoided. Anyone willing to change policy w.r.t. /tmp can do so on their own machines. Nothing is preventing them from doing so. But by changing defaults, one should err on the side of caution and remain conservative, IMHO. From man hier: /tmp/ temporary files that are not guaranteed to persist across system reboots This assumption that people often make 'People will be astonished by this'-- I would like to have someone speak up and actually say Yes, I use *temporary* directories for long-term storage rather than the assumption that they are around. Software that assumes this should be fixed, and it won't be until the bug is exposed (I'll look at eaccelerator-- it probably should store its cache in /var/db). Maintaining the status quo because of some hypothetical scenario isn't really productive. Chris ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Using TMPFS for /tmp and /var/run?
On 30 March 2012 19:36, Adrian Chadd adr...@freebsd.org wrote: On 30 March 2012 10:56, Chris Rees cr...@freebsd.org wrote: On 30 March 2012 17:31, C. P. Ghost cpgh...@cordula.ws wrote: On Fri, Mar 30, 2012 at 3:18 PM, sth...@nethelp.no wrote: However, if you always want to use tmpfs instead of stable storage, please do not. Some people expect /tmp to be persistent. This is why /etc/defaults/rc.conf has clear_tmp_enable=NO. Changing this would break the POLA. This is a mistake. The default should be clear_tmp_enable=YES if only to uncover those broken configurations that expect /tmp to be persistent. If you want to break POLA and make a lot of people angry, sure. Otherwise no. I couldn't agree more. Not clearing /tmp on reboot has been the norm for way too long and it is too late to change now. It's not just POLA, it also involves deleting data of unaware users, and that should be avoided. Anyone willing to change policy w.r.t. /tmp can do so on their own machines. Nothing is preventing them from doing so. But by changing defaults, one should err on the side of caution and remain conservative, IMHO. From man hier: /tmp/ temporary files that are not guaranteed to persist across system reboots This assumption that people often make 'People will be astonished by this'-- I would like to have someone speak up and actually say Yes, I use *temporary* directories for long-term storage rather than the assumption that they are around. Software that assumes this should be fixed, and it won't be until the bug is exposed (I'll look at eaccelerator-- it probably should store its cache in /var/db). Maintaining the status quo because of some hypothetical scenario isn't really productive. Let me tell you a story. Someone decided that ext4 could have a decent speed up if it implemented the posix standard for not flushing files on close(). After all, if you needed it to be guaranteed to be written to disk, you would call a flush routine first, before you called close(). So they did this. Then people testing out ext4 discovered that upon crash, their kde/gnome profiles were corrupted. Why? Because KDE/Gnome authors hadn't ever called flush before close(), and they weren't the only ones. They didn't read the standard, they only used the system and fixed bugs whenever their system behaved against their expectations. They didn't notice that the system was being different from the standard. Guess what ext4 did? :) Don't mis-estimate POLA. Well, having thought about what this conversation was *really* about, I may have unintentionally derailed it a little. My original intention was to say to Oliver, please, don't be discouraged from using tmpfs for /tmp, and make sure you send PRs to the upstream of any programs that misbehave as such. Let's not make judgement on people who treat /tmp as persistent quite yet ;) Chris ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Using TMPFS for /tmp and /var/run?
On 30 March 2012 12:42, Chris Rees cr...@freebsd.org wrote: Guess what ext4 did? :) Don't mis-estimate POLA. Well, having thought about what this conversation was *really* about, I may have unintentionally derailed it a little. My original intention was to say to Oliver, please, don't be discouraged from using tmpfs for /tmp, and make sure you send PRs to the upstream of any programs that misbehave as such. Let's not make judgement on people who treat /tmp as persistent quite yet ;) I'm not mis-judging anyone. :-) I'm just pointing out that things are not always quite as obvious as they seem. One of those reasons people stick/stuck with BSD is that we don't go and change this stuff so quickly. Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Using TMPFS for /tmp and /var/run?
C. P. Ghost wrote: Not clearing /tmp on reboot has been the norm for way too long and it is too late to change now. We either evolve or be in a stalemate forever. It's not just POLA, it also involves deleting data of unaware users, and that should be avoided. Mounting on a directory (/tmp) does *not* clear that directory, so automatic data loss will not occur. Adrian Chadd wrote: One of those reasons people stick/stuck with BSD is that we don't go and change this stuff so quickly. Yes, it would be a total of ~20 years before we finally decided to switch to using TMPFS for /tmp. Changes that potentially break the POLA can be categorized; a change has a combination of the following properties: (1) the change fixes a bug (ie., the change is about something that should have been different in the first place, eg., the change fixes the misspelling of a command name) (2) the change can be prepared for (ie., enough time is given for the user base to slowly switch the new method of doing things) (3) the change is evolutional (ie., the change is based on a decision to yield a net benefit (not necessarily a benefit in all cases)) (4) the change has priorly been given room (ie., is expectable as defined by standards and the documentation) The TMPFS-for-/tmp change obviously falls into (4), and surely into (3). With the support of UPDATING entries, release notifications, and perhaps announcements, the change also falls into (2). Furthermore, using TMPFS for /tmp is analogous to adding assert()s to code. Noone is really breaking the POLA that much. The TMPFS-for-/var/run should not even bother anyone. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Using TMPFS for /tmp and /var/run?
On 30 March 2012 17:57, deeptec...@gmail.com wrote: C. P. Ghost wrote: Not clearing /tmp on reboot has been the norm for way too long and it is too late to change now. We either evolve or be in a stalemate forever. No, you do it in a sensible, controlled fashion. You make it really easy for people to turn on tmpfs by default. Some distributions of FreeBSD may pick that up, some may not. You have some people run with it, find out what software breaks and start issuing fixes. You aim to have that particular default deprecated in a major release. You make it really easy for users to switch back. You point out that /tmp was never designed to be persistent across reboots, we're now making sure that's the case. If you feel so inclined, you can add a configuration step in sysinstall/bsdinstall, to let the user choose. The next major release after that, you flip the default to /tmpfs. /var/tmp/ is documented to persist across reboots on a normal system. That require much more discussion. You're changing the default behaviour. Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Using TMPFS for /tmp and /var/run?
On Fri, 30 Mar 2012, Adrian Chadd wrote: On 30 March 2012 17:57, deeptec...@gmail.com wrote: C. P. Ghost wrote: Not clearing /tmp on reboot has been the norm for way too long and it is too late to change now. We either evolve or be in a stalemate forever. No, you do it in a sensible, controlled fashion. You make it really easy for people to turn on tmpfs by default. Some distributions of FreeBSD may pick that up, some may not. You have some people run with it, find out what software breaks and start issuing fixes. You aim to have that particular default deprecated in a major release. You make it really easy for users to switch back. You point out that /tmp was never designed to be persistent across reboots, we're now making sure that's the case. If you feel so inclined, you can add a configuration step in sysinstall/bsdinstall, to let the user choose. The next major release after that, you flip the default to /tmpfs. /var/tmp/ is documented to persist across reboots on a normal system. That require much more discussion. You're changing the default behaviour. /var/tmp != /var/run But you are entirely correct on the sensible, controlled fashion. -Ben P.S. I am somewhat unconvinced by this: http://wiki.debian.org/ReleaseGoals/RunDirectory ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Using TMPFS for /tmp and /var/run?
deeptech71 at gmail.com writes: ... One of those reasons people stick/stuck with BSD is that we don't go and change this stuff so quickly. Yes, it would be a total of ~20 years before we finally decided to switch to using TMPFS for /tmp. ... According to TMPFS(5) BUGS The tmpfs kernel implementation is currently considered as an experimen- tal feature. Some file system mount time options are not well supported. Perhaps there is a reason to not push experimental things on users ? Btw, I hope Quotas is supported by tmpfs. I do not know about you, but I feel differently about /tmp even as part of / fs beeing bombed by mega-size files, and /tmp as /tmpfs (main memory plus swap) getting full or even reaching some preset value and having some priority job or its data or caches being swapped. jb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Using TMPFS for /tmp and /var/run?
On Thu, Mar 29, 2012 at 04:18:06PM +0200, O. Hartmann wrote: I was wondering if there are some objections using TMPFS for /tmp and /var/run. ... My question is whether there are objections using TMPFS for bot /tmp/ and /var/run/ at this stage on FreeBSD 10.0-CURRENT/amd64? I have no experience using tmpfs for /var/run, but I have been using it for /tmp for some time (mostly in i386, though). While I use it quite successfully on machines with a small number of folks actively busy -- e.g., my desktop; my laptop; my home machines), I encountered some issues when I tried to do so on machines that were intended for significantly heavier use. Specifically: * Compared to an md-resident /tmp, a tmpfs-resident /tmp has much less flexibility for specifying the size. Per mdconfig(8), the former uses: -s size Size of the memory disk. Size is the number of 512 byte sectors unless suffixed with a b, k, m, g, or t which denotes byte, kilo- byte, megabyte, gigabyte and terabyte respectively. Options -a and -t swap are implied if not specified. while the latter uses: sizeSpecifies the total file system size in bytes. If zero (the default) or a value larger than SIZE_MAX - PAGE_SIZE is given, the available amount of memory (including main memory and swap space) will be used. In this configuration, I would have preferred to have specified about 10GB for /tmp. I wouldn't mind if it spilled to swap space, but I certaianly didn't want it using 10GB of RAM -- especially since the machines only had 6GB RAM. Nor did I especially want *all* of the swap space used for /tmp. I would have allocated (say) 20GB for swap. I wouldn't mind if half of that were used for /tmp -- but a reason I allocate so much swap is that I've seen what happens when a machine runs out of swap, and it wasn't pretty. In any case, effective maximum usable size for tmpfs involves SIZE_MAX (~4G) PAGE_SIZE (4K, in my case). * Even when I went ahead and created a tmpfs for /tmp, I'd get ENOSPC whenever I tried to allocate anything on it -- until I dropped the size specification to 2G (2**32). Well, 2GB for /tmp just wasn't at all likely to be useful for my purposes in this case. So I continue to use tmpfs for /tmp for machines with fewer folks logging in, but I'm a bit less enthusiastic about its use unless the workload and other requirements are fairly carefully considered beforehand. Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgppDfe0Vfs6f.pgp Description: PGP signature
Re: Using TMPFS for /tmp and /var/run?
On 29 Mar 2012 16:49, O. Hartmann ohart...@mail.zedat.fu-berlin.de wrote: I was wondering if there are some objections using TMPFS for /tmp and /var/run. I figured out some problems with some rc.d scripts when using TMPFS for /var/run, samba and OpenLDAP do store some informations like PID in a subfolder of their own in /var/run, but the rc.d scripts are not checking properly the existence of the appropritae folder (unlike dbus and hald, they check properly!). I already submitted two PRs, but for SAMBA, my hack is trivial and obviously to clumsy, so it should be check properly. My question is whether there are objections using TMPFS for bot /tmp/ and /var/run/ at this stage on FreeBSD 10.0-CURRENT/amd64? Any rc script that complains about an empty /var/run is buggy- it should be assumed that it will be emptied on boot. In short, tmpfs for those two dirs should be fine. Chris ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Using TMPFS for /tmp and /var/run?
Chris Rees utis...@gmail.com wrote:
Any rc script that complains about an empty /var/run is buggy- it should be
assumed that it will be emptied on boot.
Then why are there entries for /var/run/{named,ppp,wpa_supplicant}
in /etc/mtree/BSD.var.dist? Should they be removed?
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Using TMPFS for /tmp and /var/run?
Am 03/29/12 18:14, schrieb David Wolfskill: On Thu, Mar 29, 2012 at 04:18:06PM +0200, O. Hartmann wrote: I was wondering if there are some objections using TMPFS for /tmp and /var/run. ... My question is whether there are objections using TMPFS for bot /tmp/ and /var/run/ at this stage on FreeBSD 10.0-CURRENT/amd64? I have no experience using tmpfs for /var/run, but I have been using it for /tmp for some time (mostly in i386, though). While I use it quite successfully on machines with a small number of folks actively busy -- e.g., my desktop; my laptop; my home machines), I encountered some issues when I tried to do so on machines that were intended for significantly heavier use. Specifically: * Compared to an md-resident /tmp, a tmpfs-resident /tmp has much less flexibility for specifying the size. Per mdconfig(8), the former uses: -s size Size of the memory disk. Size is the number of 512 byte sectors unless suffixed with a b, k, m, g, or t which denotes byte, kilo- byte, megabyte, gigabyte and terabyte respectively. Options -a and -t swap are implied if not specified. while the latter uses: sizeSpecifies the total file system size in bytes. If zero (the default) or a value larger than SIZE_MAX - PAGE_SIZE is given, the available amount of memory (including main memory and swap space) will be used. In this configuration, I would have preferred to have specified about 10GB for /tmp. I wouldn't mind if it spilled to swap space, but I certaianly didn't want it using 10GB of RAM -- especially since the machines only had 6GB RAM. Nor did I especially want *all* of the swap space used for /tmp. I would have allocated (say) 20GB for swap. I wouldn't mind if half of that were used for /tmp -- but a reason I allocate so much swap is that I've seen what happens when a machine runs out of swap, and it wasn't pretty. In any case, effective maximum usable size for tmpfs involves SIZE_MAX (~4G) PAGE_SIZE (4K, in my case). * Even when I went ahead and created a tmpfs for /tmp, I'd get ENOSPC whenever I tried to allocate anything on it -- until I dropped the size specification to 2G (2**32). Well, 2GB for /tmp just wasn't at all likely to be useful for my purposes in this case. So I continue to use tmpfs for /tmp for machines with fewer folks logging in, but I'm a bit less enthusiastic about its use unless the workload and other requirements are fairly carefully considered beforehand. Peace, david It seems there is only one switch which determines the size of the tmpfs in question (size) and there is no convenient way to say what amount of RAM is being used before using the swap space. I'd like to have at least a knob determining the limit of RAM being used. On the other hand - my view of those things is really naiv. I think having tmpfs isn't even a benefit in terms of security, it should also offer a speedy access to files kept in memory, doesn't it? Linux is using TMPFS filesystems a lot for these purposes. How do they overcome restrictions of the size or not flloding RAM and/or swap? Regards, Oliver signature.asc Description: OpenPGP digital signature
Re: Using TMPFS for /tmp and /var/run?
On 03/29/12 09:18, O. Hartmann wrote: I was wondering if there are some objections using TMPFS for /tmp and /var/run. For /tmp, what exactly do you mean? If you want to use tmpfs instead of md/mdmfs when tmpmfs=YES in rc.conf, I have no opinion. However, if you always want to use tmpfs instead of stable storage, please do not. Some people expect /tmp to be persistent. This is why /etc/defaults/rc.conf has clear_tmp_enable=NO. Changing this would break the POLA. Cheers, Eric ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Using TMPFS for /tmp and /var/run?
On Thu, Mar 29, 2012 at 02:50:00PM -0500, Eric van Gyzen wrote: ... However, if you always want to use tmpfs instead of stable storage, please do not. Some people expect /tmp to be persistent. This is why /etc/defaults/rc.conf has clear_tmp_enable=NO. Changing this would break the POLA. ... Errr... I'm not sure why folks might have that misguided expectation; from hier(7): /tmp/ temporary files that are not guaranteed to persist across sys- tem reboots Foplks are welcome to do whatever they wish with their own machines, but the FreeBSD default is as above. And I was using swap-backed /tmp on SunOS back around 1988 :-} Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpQSUcQ0Mxkt.pgp Description: PGP signature
Re: Using TMPFS for /tmp and /var/run?
Am 03/29/12 21:50, schrieb Eric van Gyzen: On 03/29/12 09:18, O. Hartmann wrote: I was wondering if there are some objections using TMPFS for /tmp and /var/run. For /tmp, what exactly do you mean? If you want to use tmpfs instead of md/mdmfs when tmpmfs=YES in rc.conf, I have no opinion. Aren't MDMFS backed filesystems of static size? And haven't they to be created first before they can be used? Using TMPFS seems toi be a more convenient way to me - dynamical (?), using a fstab entry for convenience. However, if you always want to use tmpfs instead of stable storage, please do not. Some people expect /tmp to be persistent. This is why /etc/defaults/rc.conf has clear_tmp_enable=NO. Changing this would break the POLA. Cheers, Eric I have set clear_tmp_enable=YES. I treat /tmp as it is: temporary. No one should change the default setting. Well, SSDs become more and more popular, even for heavy duty servers. Still facing the waer-off problemacy with NAND flash memory, I'd would feel better have the main memory used by the volatile filesystems like /var/run and /tmp which get rewritten quite often. signature.asc Description: OpenPGP digital signature
Re: Using TMPFS for /tmp and /var/run?
On Thu, Mar 29, 2012 at 10:07:01PM +0200, O. Hartmann wrote: ... Aren't MDMFS backed filesystems of static size? And haven't they to be created first before they can be used? Using TMPFS seems toi be a more convenient way to me - dynamical (?), using a fstab entry for convenience. One may create a swap-backed mfs; this is what I used to do for /tmp before I started using tmpfs. (See the tmpmfs line (and related lines) in /etc/defaults/rc.conf.) ... Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpbMAzxZUI37.pgp Description: PGP signature
Re: Using TMPFS for /tmp and /var/run?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 03/29/12 09:59, Vitaly Magerya wrote:
Chris Rees utis...@gmail.com wrote:
Any rc script that complains about an empty /var/run is buggy- it
should be assumed that it will be emptied on boot.
Then why are there entries for /var/run/{named,ppp,wpa_supplicant}
in /etc/mtree/BSD.var.dist? Should they be removed?
No, they are populated by /etc/rc.d/var...
Cheers,
- --
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (FreeBSD)
iQEcBAEBCAAGBQJPdMsBAAoJEG80Jeu8UPuzug4H/joM719VK0TeISLSRusdcdnQ
9k0VnmuBtxUgzh+Wrsb/Ka5jROg39+hVLHKEIszMrZ1Ip85YW4JpnL1cq2OJ+ZKV
dXFt8b8KVPcO0XBMAnvaD8x7J9emrNQU54VMhumAun+IpyGXTvATBCPaPB5zewMJ
DAai5rSXi/jOdjdXmgxydtRsaXdwR4dHlQ/EPmpby9pnxEwqRjQHkl4ZvTYC0yNU
+UCffIqbQsn/Zerwxzg9NnTSjVDKNgN192xhsDJN9hXDAFro1aG2LMSA4iYPxsYH
ge0P6cO21qb7fRDB6KdHB/qUF1zcTt9cw+IsWKmBV3qN+GkDiB7vtKJa7hX/1XE=
=3B8C
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Using TMPFS for /tmp and /var/run?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/29/12 09:41, Chris Rees wrote: On 29 Mar 2012 16:49, O. Hartmann ohart...@mail.zedat.fu-berlin.de wrote: I was wondering if there are some objections using TMPFS for /tmp and /var/run. I figured out some problems with some rc.d scripts when using TMPFS for /var/run, samba and OpenLDAP do store some informations like PID in a subfolder of their own in /var/run, but the rc.d scripts are not checking properly the existence of the appropritae folder (unlike dbus and hald, they check properly!). I already submitted two PRs, but for SAMBA, my hack is trivial and obviously to clumsy, so it should be check properly. My question is whether there are objections using TMPFS for bot /tmp/ and /var/run/ at this stage on FreeBSD 10.0-CURRENT/amd64? Any rc script that complains about an empty /var/run is buggy- it should be assumed that it will be emptied on boot. Agreed. We may want a generic way of registering custom mtrees (or something) that creates the hierarchy on boot, by the way. Currently this has to be done by individual rc.d scripts if they need a separate directory. Cheers, - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJPdMuiAAoJEG80Jeu8UPuzJKsH/js4Fsvb/drjTFGRwmOmSJ5V 7lfVxT6cuFTB1vpCTooR2rVzxZyfqSzeFwc5i8lbhK8+SA13Q46jkCZyHQCgoEqX n2ZIIMgIi+04+IQGrA9742Rkd/7RtvD88xf1wXcgkoY9IImpaYLvjVfcxMqxYMvI 75OHIsmvIbxt/vnmVx26Omh3ZvvHN2QI8n6lUqjqWVm96qEGwdoBuA+m2g5QKem/ 24gLZ0kttmO/zKo8vKRTgR9RiCYeS2IUueLy4PDmMKf8Oiv3/Y9f3c8S8Bw4qVdB cOKqugBtInCu3BnsPrDJpoNUiSb+Cf5aLggbPSocD9A1iToChDmyRF5eC6Tc6Kw= =owJ7 -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Using TMPFS for /tmp and /var/run?
On 03/29/2012 14:58, David Wolfskill wrote: On Thu, Mar 29, 2012 at 02:50:00PM -0500, Eric van Gyzen wrote: ... However, if you always want to use tmpfs instead of stable storage, please do not. Some people expect /tmp to be persistent. This is why /etc/defaults/rc.conf has clear_tmp_enable=NO. Changing this would break the POLA. ... Errr... I'm not sure why folks might have that misguided expectation; Because that's how the default installation has behaved for a long time. I'm not saying this expectation is /wise/; I'm just saying some people have formed that expectation by observing the behavior of the default system, and they would be astonished by this change. from hier(7): /tmp/ temporary files that are not guaranteed to persist across sys- tem reboots Foplks are welcome to do whatever they wish with their own machines, but the FreeBSD default is as above. Respectfully, no. The default is to store /tmp in UFS, either in its own partition (with Auto Defaults) or in / (if no partition was created for it), and to refrain from clearing it at boot. Thus, although /tmp is not guaranteed to persist in theory, it is rather persistent in practice. My only point is: carefully consider the change in behavior of the default installation before breaking the POLA. Eric ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
