Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: Using TMPFS for /tmp and /var/run?
468 views
Skip to first unread message
Warren Block
Apr 1, 2012, 10:15:04 PM4/1/12
to
On Mon, 2 Apr 2012, deept...@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...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"
> 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...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"
Gleb Kurtsou
Apr 2, 2012, 6:31:19 AM4/2/12
to
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:
> >
> > size Specifies 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
>
> 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:
> >
> > size Specifies 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
>
grarpamp
Apr 2, 2012, 5:41:52 AM4/2/12
to
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
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
David Wolfskill
Apr 2, 2012, 6:59:33 AM4/2/12
to
On Mon, Apr 02, 2012 at 01:31:19PM +0300, Gleb Kurtsou wrote:
> ...
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.
> ...
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.
> ...
> > > 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"
> > > (~4G) & PAGE_SIZE (4K, in my case).
>
> size_t is 64-bit on 64-bit archs.
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.
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
> ...
> > 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.
David Wolfskill
Apr 2, 2012, 9:26:59 AM4/2/12
to
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
> ....
> (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 ro...@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 /tmp tmpfs rw,size=2147483648 0 0
worked same as before the patch; "df -h /tmp" reported a size of 2.0G.
* Changing the above to read:
tmpfs /tmp tmpfs rw,size=2g 0 0
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 /tmp tmpfs rw,size=8g 0 0
(still) yields:
g1-227(10.0-C)[3] df -h /tmp
Filesystem Size Used 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. :-)
jb
Apr 2, 2012, 11:46:34 AM4/2/12
to
jb <jb.1234abcd <at> gmail.com> writes:
> ...
Chuck Burns bre...@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
> ...
Chuck Burns bre...@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
Chris Rees
Apr 2, 2012, 11:52:19 AM4/2/12
to
Chris
Chuck Burns
Apr 2, 2012, 6:06:11 PM4/2/12
to
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.
>
> This is a known issue with ZFS. Is that your case?
>
> Chris
and jb, thanks, I could've sworn I'd hit "Reply to list" - thanks for
forwarding it for me.
Chuck
Doug Barton
Apr 2, 2012, 6:22:41 PM4/2/12
to
-----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"
>>> 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.
>> 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-----
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"
>> <ohar...@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
>>>
>>> I was wondering if there are some objections using TMPFS for
>>> 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-
>>> My question is whether there are objections using TMPFS for
>>> bot /tmp/ and /var/run/ at this stage on FreeBSD
>>> 10.0-CURRENT/amd64?
>
>> 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-----
David Wolfskill
Apr 3, 2012, 1:01:54 PM4/3/12
to
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:
> ...
> 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
> ...
FreeBSD g1-227.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #0 233772M: Mon Apr 2 05:42:48 PDT 2012 ro...@g1-227.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386
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 ro...@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.
jb
Apr 3, 2012, 1:29:31 PM4/3/12
to
> 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
> 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
John Baldwin
Apr 3, 2012, 9:42:06 AM4/3/12
to
On Monday, April 02, 2012 5:03:26 pm Gleb Kurtsou wrote:
> On (02/04/2012 06:26), David Wolfskill wrote:
> 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
> > > ...
> > > 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:
> >
> >
> > 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
ro...@g1-227.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386
> >
233772M: Mon Apr 2 05:42:48 PDT 2012
ro...@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 /tmp tmpfs rw,size=2147483648 0 0
> >
> > worked same as before the patch; "df -h /tmp" reported a size of 2.0G.
> >
> > * Changing the above to read:
> >
> > tmpfs /tmp tmpfs rw,size=2g 0 0
> >
> > 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 /tmp tmpfs rw,size=8g 0 0
> >
> > (still) yields:
> >
> > g1-227(10.0-C)[3] df -h /tmp
> > Filesystem Size Used 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.
Hmm, is UINT64_MAX really the right type? Should it be something like OFF_MAX
> >
> > * Resulting sources build with no issues.
> >
> > * Prior specification I had in /etc/fstab:
> >
> > tmpfs /tmp tmpfs rw,size=2147483648 0 0
> >
> > worked same as before the patch; "df -h /tmp" reported a size of 2.0G.
> >
> > * Changing the above to read:
> >
> > tmpfs /tmp tmpfs rw,size=2g 0 0
> >
> > 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 /tmp tmpfs rw,size=8g 0 0
> >
> > (still) yields:
> >
> > g1-227(10.0-C)[3] df -h /tmp
> > Filesystem Size Used 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.
instead?
--
John Baldwin
David Wolfskill
Apr 4, 2012, 9:38:58 AM4/4/12
to
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.
> ...
> 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 ro...@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
Filesystem Size Used Avail Capacity iused ifree %iused Mounted on
tmpfs 23G 12k 23G 0% 17 2.1G 0% /tmp
g1-227(10.0-C)[2] grep tmpfs /etc/fstab
# tmpfs /tmp tmpfs rw,size=2147483648 0 0
tmpfs /tmp tmpfs 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
Filesystem Size Used Avail Capacity iused ifree %iused Mounted on
tmpfs 23G 8.0G 15G 35% 18 2.1G 0% /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 (38999968 bytes/sec)
g1-227(10.0-C)[7] df -hi /tmp
Filesystem Size Used Avail Capacity iused ifree %iused Mounted on
tmpfs 23G 16G 7.0G 70% 19 2.1G 0% /tmp
g1-227(10.0-C)[8] exit
Script done on Wed Apr 4 06:33:12 2012
g1-227(10.0-C)[5]
Gleb Kurtsou
Apr 5, 2012, 3:43:04 AM4/5/12
to
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
> 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):
>
previous patch. I've combined both patches. Could you try it.
Thanks,
Gleb.
David Wolfskill
Apr 5, 2012, 7:20:14 AM4/5/12
to
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
> > 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.
cd /sys && svn diff
0 new messages