tmpfs was disabled in GENERIC a bit shy of 7 years ago, is it time to kill it?
Skimming sbin/mount_tmpfs and sys/tmpfs, it looks like the vast majority of the
touches were part of wide-encompassing diffs, along with a couple tmpfs panic
fixes from the mailing lists.
My cvs diff-fu is not
Am Thu, Apr 22, 2021 at 11:19:22AM +0200 schrieb Martin Pieuchot:
> uao_shrink() and uao_grow() are only used by TMPFS, ok to place them
> under an #ifdef? This save some bytes on RAMDISKs.
sure, ok patrick@
> Index: uvm/u
uao_shrink() and uao_grow() are only used by TMPFS, ok to place them
under an #ifdef? This save some bytes on RAMDISKs.
Index: uvm/uvm_aobj.c
===
RCS file: /cvs/src/sys/uvm/uvm_aobj.c,v
retrieving revision 1.94
diff -u -p -r1.94
t;
> I know that tmpfs is disabled by default, but it would be nice
> to have this fix in the code base anyway.
>
> Gerhard
>
>
> Index: sys/tmpfs/tmpfs_vnops.c
> ===
> RCS file: /cvs/src/sys/tmpfs/tmp
tmpfs_reclaim() has to make sure that the VFS cache has no more
locks held for the vnode. Else vclean() could panic because v_holdcnt
is non-zero.
I know that tmpfs is disabled by default, but it would be nice
to have this fix in the code base anyway.
Gerhard
Index: sys/tmpfs/tmpfs_vnops.c
It's unlocking parent directory vnode because LOCKPARENT is *not* requested.
Also fix a typo for "explicitly".
Index: sys/tmpfs/tmpfs_vnops.c
===
RCS file: /cvs/src/sys/tmpfs/tmpfs_vnops.c,v
retrieving revision 1.27
di
Recent commit ("Syncronize filesystems to disk when suspending.") has
added int argument to sync() vfsops, but sys/tmpfs missed that change.
https://leaf.dragonflybsd.org/~tkusumi/diff/openbsd/tmpfs-sync-fix-arg.cvs.patch
Index: sys/tmpfs/tmpf
Please move this thread to misc@ if it really needs to be continued.
Hey,
On 12/15/16 16:34, Kent R. Spillner wrote:
So fixing the BUG section of the man page ?
That's not what "maintain" means.
i think by "maintain" he means that you fix the bugs mentioned in the
man page and after that continue to improve the code beyond just fixing
bugs.
Greegings
Leo
On Thu, Dec 15, 2016 at 09:47:53AM -0500, sven falempin wrote:
> > maintain tmpfs
> >
> So fixing the BUG section of the man page ?
That's not what "maintain" means.
On Wed, Dec 14, 2016 at 7:02 PM, Martin Schröder wrote:
> 2016-12-14 17:07 GMT+01:00 sven falempin :
> > i am using this daily, what can i do !?
>
> maintain tmpfs
>
> Best
>Martin
>
>
So fixing t
2016-12-14 17:07 GMT+01:00 sven falempin :
> i am using this daily, what can i do !?
maintain tmpfs
Best
Martin
On 2016/12/14 11:07, sven falempin wrote:
> On Wed, Dec 14, 2016 at 10:51 AM, Stuart Henderson
> wrote:
>
> > On 2016/12/14 10:44, sven falempin wrote:
> > > [130]-[~]
> > > # ktrace mount_tmpfs -s20M tmpfs /foo
> > > mount_tmpfs: tmpfs on /foo: Operat
On Wed, Dec 14, 2016 at 10:51 AM, Stuart Henderson
wrote:
> On 2016/12/14 10:44, sven falempin wrote:
> > [130]-[~]
> > # ktrace mount_tmpfs -s20M tmpfs /foo
> > mount_tmpfs: tmpfs on /foo: Operation not supported
> > [1]-[~]
> > # ls -ld /foo
> > drwxr-xr-
On 2016/12/14 10:44, sven falempin wrote:
> [130]-[~]
> # ktrace mount_tmpfs -s20M tmpfs /foo
> mount_tmpfs: tmpfs on /foo: Operation not supported
> [1]-[~]
> # ls -ld /foo
> drwxr-xr-x 2 root wheel 512 Dec 14 16:26 /foo
revision 1.229
date: 2
[130]-[~]
# ktrace mount_tmpfs -s20M tmpfs /foo
mount_tmpfs: tmpfs on /foo: Operation not supported
[1]-[~]
# ls -ld /foo
drwxr-xr-x 2 root wheel 512 Dec 14 16:26 /foo
trace:
6289 mount_tmpfs CALL lstat(0x7f7d9810,0x7f7d89f0)
6289 mount_tmpfs NAMI "/foo"
6289 mount_
On Mon, Jul 11, 2016 at 04:39:05PM -0400, Ted Unangst wrote:
> Tim Newsham wrote:
> > The tmpfs filesystem allows the mounting user to specify a
> > username, a groupname or a device name for the root node of
> > the filesystem. A user that specifies a value of VNOVAL for
&g
r
> > > to do the same check and return an error.
> >
> > Checking for VNOVAL is kind of bogus. How about we try something
> > more sensible?
>
> those checks are equally useless. UID_MAX is UINT_MAX so the tests don't fire.
>
> the question is what other tmpf
On Mon, 11 Jul 2016 17:06:33 -0400, "Ted Unangst" wrote:
> those checks are equally useless. UID_MAX is UINT_MAX so the tests don't fire
> .
>
> the question is what other tmpfs code blows up when nodes owned by -1 start
> showing up.
Fair enough.
of bogus. How about we try something
> more sensible?
those checks are equally useless. UID_MAX is UINT_MAX so the tests don't fire.
the question is what other tmpfs code blows up when nodes owned by -1 start
showing up.
>
> - todd
>
> Index: tmpfs_subr.c
> ==
Index: tmpfs_subr.c
===
RCS file: /cvs/src/sys/tmpfs/tmpfs_subr.c,v
retrieving revision 1.16
diff -u -p -u -r1.16 tmpfs_subr.c
--- tmpfs_subr.c19 Jun 2016 11:54:33 - 1.16
+++ tmpfs_subr.c11 Jul 2016 20:45:26 -
Tim Newsham wrote:
> The tmpfs filesystem allows the mounting user to specify a
> username, a groupname or a device name for the root node of
> the filesystem. A user that specifies a value of VNOVAL for
> any of these fields will trigger an assert in tmpfs_alloc_node():
>
>
Here's a bug related to tmpfs mounts.
Forwarded Message
Subject:[Bug49] Tmpfs mount with bad args can lead to a panic
Date: Mon, 11 Jul 2016 10:07:33 -1000
From: Tim Newsham
To: dera...@openbsd.org, Jesse Hertz
Hi Theo, here's a low-severity
On Wed, 06 Jul 2016 15:28:33 +0200, Marc Espie wrote:
> Note: it seems strange to have extra checks for VT_CHAR... in tmpfs_mknod
> as well. These should be fs-independent ?...
Do you mean this?
if (vt != VBLK && vt != VCHR && vt != VFIFO) {
vput(dvp);
ret
Todd C. Miller wrote:
> On Wed, 06 Jul 2016 06:53:06 -0600, "Todd C. Miller" wrote:
>
> > Is there any reason to not do the check higher up in domknodat()?
> > A mknod of -1 on ffs results in a device of major 0, minor 0 which
> > is unexpected.
>
> The following should be sufficient and not inte
On Wed, Jul 06, 2016 at 07:18:14AM -0600, Bob Beck wrote:
> ok beck@
>
> On Wednesday, 6 July 2016, Todd C. Miller wrote:
>
> > On Wed, 06 Jul 2016 06:53:06 -0600, "Todd C. Miller" wrote:
> >
> > > Is there any reason to not do the check higher up in domknodat()?
> > > A mknod of -1 on ffs resul
ok beck@
On Wednesday, 6 July 2016, Todd C. Miller wrote:
> On Wed, 06 Jul 2016 06:53:06 -0600, "Todd C. Miller" wrote:
>
> > Is there any reason to not do the check higher up in domknodat()?
> > A mknod of -1 on ffs results in a device of major 0, minor 0 which
> > is unexpected.
>
> The follow
On Wed, 06 Jul 2016 06:53:06 -0600, "Todd C. Miller" wrote:
> Is there any reason to not do the check higher up in domknodat()?
> A mknod of -1 on ffs results in a device of major 0, minor 0 which
> is unexpected.
The following should be sufficient and not interfere with creating
FIFOs or badsect
Is there any reason to not do the check higher up in domknodat()?
A mknod of -1 on ffs results in a device of major 0, minor 0 which
is unexpected.
- todd
E.g., this should be equivalent.
Index: tmpfs_vnops.c
===
RCS file: /build/data/openbsd/cvs/src/sys/tmpfs/tmpfs_vnops.c,v
retrieving revision 1.27
diff -u -p -r1.27 tmpfs_vnops.c
--- tmpfs_vnops.c 19 Jun 2016 11:54:33 -
me.
>
> Index: tmpfs_vnops.c
> ===
> RCS file: /cvs/src/sys/tmpfs/tmpfs_vnops.c,v
> retrieving revision 1.27
> diff -u -p -r1.27 tmpfs_vnops.c
> --- tmpfs_vnops.c 19 Jun 2016 11:54:33 - 1.27
> +++ tmpfs_vnops.c 5 Jul 2016 23:
Tim Newsham wrote:
> Recommendation:
> Validate the device number vap->va_rdev in tmpfs_mknod() and return
> an error if it is VNOVAL (-1).
Sounds about right to me.
Index: tmpfs_vnops.c
===
RCS file: /cvs/s
Hi, While fuzzing the openbsd system call interface we came across a
low severity issue. The details are below in our proof-of-concept that
includes a writeup with recommendations.
Tim & Jesse @ NCC Group
/*
* tmpfs_mknod_panic.c:
*Demonstrate a panic in tmpfs when performing m
PR_WAITOK implies process context, so IPL_NONE is fine.
this is the same as the ufs change, but in tmpfs.
ok?
Index: tmpfs_vfsops.c
===
RCS file: /cvs/src/sys/tmpfs/tmpfs_vfsops.c,v
retrieving revision 1.8
diff -u -p -r1.8
On Sat, Feb 27, 2016 at 05:44:49PM -0500, Michael McConville wrote:
> * There wasn't yet a list of possible errors for tmpfs in mount(2).
>That said, I question the value of maintaining these lists. It's
>almost impossible for them to be comprehensive - for example
* EINVAL is returned in a case where there is insufficient memory.
ENOMEM makes more sense. This one is ok natano@.
* There wasn't yet a list of possible errors for tmpfs in mount(2).
That said, I question the value of maintaining these lists. It's
almost impossible for
(EINVAL);
> > +
> > p = uio->uio_procp;
> >
> > #ifdef DIAGNOSTIC
> > if (uio->uio_rw != UIO_READ && uio->uio_rw != UIO_WRITE)
> > panic("uiomove: mode");
> > if (uio->uio_segflg == UIO_USERSPACE
t;uiomove: mode");
> if (uio->uio_segflg == UIO_USERSPACE && p != curproc)
> panic("uiomove: proc");
> #endif
> while (n > 0 && uio->uio_resid) {
> iov = uio->uio_iov;
I don't think this will fix the unde
Martin Natano wrote:
> Below a diff to convert tmpfs/tmpfs_{subr,vnops}.c. That's an easy one.
> Nearly all the relevant size variables already are a size_t, or a
> smaller unsigned type. In the last hunk tn_size (an off_t) might be
> passed to uiomove(), which is not problematic
Below a diff to convert tmpfs/tmpfs_{subr,vnops}.c. That's an easy one.
Nearly all the relevant size variables already are a size_t, or a
smaller unsigned type. In the last hunk tn_size (an off_t) might be
passed to uiomove(), which is not problematic, because tn_size is
constrained to only
://marc.info/?l=netbsd-source-changes&m=144694603617544&w=2
> >
> > We have very few local changes to tmpfs and we share the
> > KASSERT(de->td_node == NULL), so I think this applies to us.
> >
> > Thoughts? ok?
> >
> >
> > Index: sys/tmpfs/
> That said, using M_ZERO does sound like a safety improvement. However,
> that also looks like a big struct (in the process of getting an actual
> number). Thoughts on the performance impact?
No performance impact at all.
until the next time an uninitialized field occurs in there!
then maybe ka
tmpfs actrually already must diverege from netbsd. we can not just
blithly accept changes from there.. our kernel midlayers are very
different.
tmpfs actually does not work very well right now.
On Fri, Dec 11, 2015 at 2:47 PM, Michael McConville wrote:
> Stefan Sperling wrote:
>> On
On Fri, Dec 11, 2015 at 04:47:16PM -0500, Michael McConville wrote:
> Stefan Sperling wrote:
> > On Fri, Dec 11, 2015 at 04:05:49PM -0500, Michael McConville wrote:
> > > Bob Beck wrote:
> > > > Stability before performance. Tmpfs does not have the former yet.
Stefan Sperling wrote:
> On Fri, Dec 11, 2015 at 04:05:49PM -0500, Michael McConville wrote:
> > Bob Beck wrote:
> > > Stability before performance. Tmpfs does not have the former yet.
> >
> > ok mmcc@ for your PR_ZERO diff, as long as there's a comment added
&
On Fri, Dec 11, 2015 at 04:05:49PM -0500, Michael McConville wrote:
> Bob Beck wrote:
> > Stability before performance. Tmpfs does not have the former yet.
>
> ok mmcc@ for your PR_ZERO diff, as long as there's a comment added about
> the performance impact and the poten
Bob Beck wrote:
> Stability before performance. Tmpfs does not have the former yet.
ok mmcc@ for your PR_ZERO diff, as long as there's a comment added about
the performance impact and the potential to back out in the future.
I think it'd still be worthwhile to add the NULL as
Stability before performance. Tmpfs does not have the former yet.
On Fri, Dec 11, 2015 at 12:59 PM, Michael McConville wrote:
> Bob Beck wrote:
>> On Fri, Dec 11, 2015 at 01:09:30AM -0500, Michael McConville wrote:
>> > Here's the PR:
>> >
>> > https:/
Bob Beck wrote:
> On Fri, Dec 11, 2015 at 01:09:30AM -0500, Michael McConville wrote:
> > Here's the PR:
> >
> > https://gnats.netbsd.org/50381
> >
> > And the commit:
> >
> > https://marc.info/?l=netbsd-source-changes&m=144694603617544&am
On Fri, Dec 11, 2015 at 01:09:30AM -0500, Michael McConville wrote:
> Here's the PR:
>
> https://gnats.netbsd.org/50381
>
> And the commit:
>
> https://marc.info/?l=netbsd-source-changes&m=144694603617544&w=2
>
> We have very few local changes to tmpf
Here's the PR:
https://gnats.netbsd.org/50381
And the commit:
https://marc.info/?l=netbsd-source-changes&m=144694603617544&w=2
We have very few local changes to tmpfs and we share the
KASSERT(de->td_node == NULL), so I think this applies to us.
Thoughts? ok?
Index: sys/tm
twork Engineer
http://www.unix-experience.fr
Le mardi 06 mai 2014 à 08:36 +0100, Stuart Henderson a écrit :
> On 2014/05/06 09:28, Janne Johansson wrote:
> > dd would perhaps not be the end goal for any memory filesystem, but the
> > major point is that when you remove files, tmpfs will
On 2014/05/06 09:28, Janne Johansson wrote:
> dd would perhaps not be the end goal for any memory filesystem, but the
> major point is that when you remove files, tmpfs will (try to) return the
> memory to the OS, where mfs will not.
When used for things like port build directories or
dd would perhaps not be the end goal for any memory filesystem, but the
major point is that when you remove files, tmpfs will (try to) return the
memory to the OS, where mfs will not.
2014-05-06 8:28 GMT+02:00 Loïc Blot :
> Hi @tech
> i've migrated one of our squid server to OpenBS
Hi @tech
i've migrated one of our squid server to OpenBSD 5.5 and i tested tmpfs.
It works like a charm, great work, but i noticed than the mfs is faster
than tmpfs.
My benchs (with dd) are showing that tmpfs is slower than mfs. (/tmp:
tmpfs | /var/squid/cache: mfs), i've done many dd
> I'm not comfortable with introducing more APIs. So
> perhaps we should just punt on the optimization and remove/insert all
> list items. Removing the trap comments that pedro set up...
Since the removal macros poison pointers which should no longer be
dereferenced after the operation, I'm str
> On Wed, Apr 30, 2014 at 03:38:39PM +0200, Mark Kettenis wrote:
> > > Date: Wed, 30 Apr 2014 13:39:20 +0100
> > > From: Stuart Henderson
> > >
> > > Seen when running e2fsprogs regression tests with /tmp on tmpfs
> >
> > I'm not surpr
;> >>
>> >> > Date: Wed, 30 Apr 2014 13:39:20 +0100
>> >> > From: Stuart Henderson
>> >> >
>> >> > Seen when running e2fsprogs regression tests with /tmp on tmpfs
>> >>
>> >> I'm not surprised; tmpfs conta
014 15:55, Mark Kettenis wrote:
>> >> Date: Wed, 30 Apr 2014 15:38:39 +0200 (CEST)
>> >> From: Mark Kettenis
>> >>
>> >> > Date: Wed, 30 Apr 2014 13:39:20 +0100
>> >> > From: Stuart Henderson
>> >> >
>> >>
;> >>
>> >> > Date: Wed, 30 Apr 2014 13:39:20 +0100
>> >> > From: Stuart Henderson
>> >> >
>> >> > Seen when running e2fsprogs regression tests with /tmp on tmpfs
>> >>
>> >> I'm not surprised; tmpfs conta
; >> > From: Stuart Henderson
> >> >
> >> > Seen when running e2fsprogs regression tests with /tmp on tmpfs
> >>
> >> I'm not surprised; tmpfs contains some serious bugs. I recommend not
> >> using it until those are fixed.
On 30 April 2014 15:55, Mark Kettenis wrote:
>> Date: Wed, 30 Apr 2014 15:38:39 +0200 (CEST)
>> From: Mark Kettenis
>>
>> > Date: Wed, 30 Apr 2014 13:39:20 +0100
>> > From: Stuart Henderson
>> >
>> > Seen when running e2fsprogs regression t
> Date: Wed, 30 Apr 2014 15:38:39 +0200 (CEST)
> From: Mark Kettenis
>
> > Date: Wed, 30 Apr 2014 13:39:20 +0100
> > From: Stuart Henderson
> >
> > Seen when running e2fsprogs regression tests with /tmp on tmpfs
>
> I'm not surprised; tmpfs contains
On Wed, Apr 30, 2014 at 03:38:39PM +0200, Mark Kettenis wrote:
> > Date: Wed, 30 Apr 2014 13:39:20 +0100
> > From: Stuart Henderson
> >
> > Seen when running e2fsprogs regression tests with /tmp on tmpfs
>
> I'm not surprised; tmpfs contains some serious bugs
> Date: Wed, 30 Apr 2014 13:39:20 +0100
> From: Stuart Henderson
>
> Seen when running e2fsprogs regression tests with /tmp on tmpfs
I'm not surprised; tmpfs contains some serious bugs. I recommend not
using it until those are fixed.
> Data modified on freelist: word -3518
Seen when running e2fsprogs regression tests with /tmp on tmpfs
...
Data modified on freelist: word -35183628471970 of object 0x80d36c00
size 0x400 previous type free (invalid addr 0xf40858de1f81cbe9)
panic: Data modified on freelist: word 4 of object 0x80d36c00 size
0x400
As noticed by aja, kqueue doesn't work on tmpfs.
Copy more better bits from ufs instead of using generic bits.
Index: tmpfs_vnops.c
===
RCS file: /cvs/src/sys/tmpfs/tmpfs_vnops.c,v
retrieving revision 1.12
diff -u -p -
On Wed, Jun 05, 2013 at 02:55:29PM +0200, Marc Espie wrote:
> Here's the diff I have to -current with just tmpfs
> (activate bits, uvm changes).
>
> pedro, I know some of your stuff is not in there (I dropped the mount_tmpfs
> diff), feel free to give me a full correct u
Here's the diff I have to -current with just tmpfs
(activate bits, uvm changes).
pedro, I know some of your stuff is not in there (I dropped the mount_tmpfs
diff), feel free to give me a full correct updated diff.
Index: lib/libc/sys/mo
just an optimization, or something more ?
diff -urp tmpfs0/tmpfs_specops.c tmpfs/tmpfs_specops.c
--- tmpfs0/tmpfs_specops.c Tue May 14 11:51:12 2013
+++ tmpfs/tmpfs_specops.c Tue May 14 12:21:52 2013
@@ -502,6 +512,7 @@ tmpfs_dir_attach(struct vnode *dvp, tmpfs_dirent_
One more note. We already have a fmt_scaled function in libutil which would
be better than introducing a private dehumanisze_number.
Good point; I will switch to fmt_scaled() in the next iteration of the
diff.
-p.
On Mon, Apr 15, 2013 at 15:27, Pedro Martelletto wrote:
>>http://block.io/tmpfs/tmpfs4.diff
>
> My bad, the correct URL is:
>
> http://block.io/tmp/tmpfs4.diff
>
> -p.
One more note. We already have a fmt_scaled function in libutil which would
be better th
However, both fs indirection structures will need fixing,
as they use C99 field assignments:
you know stuff like:
+struct vops tmpfs_fifovops = {
+ .vop_lookup = tmpfs_fifo_lookup,
+ .vop_create = tmpfs_fifo_create,
and
+struct vops tmpfs_specvops = {
+ .vop_lookup
http://block.io/tmpfs/tmpfs4.diff
My bad, the correct URL is:
http://block.io/tmp/tmpfs4.diff
-p.
for spotting this. The problem was a missing check
when calling cache_enter() from tmpfs_lookup(). I have fixed the glitch
in version 4 of the diff:
http://block.io/tmpfs/tmpfs4.diff
Alternatively, you might want to ammend the source code directly, since
it is a one-line change. In tmpfs_vnops.c, repl
So, it's not working.
After about 5 mn of succesful build, my tmpfs is full
touch /tmp/a
touch: /tmp/a: No space left on device
whereas:
df -khi /tmp
tmpfs 10.5G 600M 9.9G 6% 45728 41386496 0% /tmp
so, something put it into a "no space left" configuration internally ?
My gu
Ted,
> >
> > In tmpfs3.diff there are three uses of INT64_MAX:
> >
> > The first, in tmpfs_mount(), concerns the maximum amount of memory (in
> > bytes) that tmpfs will contemplate. This value is bounded by the numbers
> > in UVM's uvmexp and by the parame
However, both fs indirection structures will need fixing,
as they use C99 field assignments:
you know stuff like:
+struct vops tmpfs_fifovops = {
+ .vop_lookup = tmpfs_fifo_lookup,
+ .vop_create = tmpfs_fifo_create,
and
+struct vops tmpfs_specvops = {
+ .vop_lookup
rst, in tmpfs_mount(), concerns the maximum amount of memory (in
> bytes) that tmpfs will contemplate. This value is bounded by the numbers
> in UVM's uvmexp and by the parameters specified upon mount, if any.
I won't pretend to understand this code all that much, but I'm now ru
I'd like to test this, but I'm not very experienced with building only
part of the userland. How do I tell the build system to install the new
header files?
cd /usr/src; make obj cleandir includes
Please contact me off-list should you need further assistance.
-p.
Speaking of, I see a lot of int64_max sprinkled throughout, which doesn't
seem right for 32 bit platforms.
Hi Ted,
In tmpfs3.diff there are three uses of INT64_MAX:
The first, in tmpfs_mount(), concerns the maximum amount of memory (in
bytes) that tmpfs will contemplate. This value is bo
On Tue, Apr 09, 2013 at 17:26, Pedro Martelletto wrote:
> This diff fixes a couple of 64 vs 32-bit inconsistencies in the original
> diff, as well as a missing call to uvm_vnp_uncache() upon truncation.
> Many thanks to Chris Jackman for testing on sparc64.
Speaking of, I see a lot of int64_max s
On Tue, 9 Apr 2013 17:26:39 +0100
Pedro Martelletto wrote:
> >You will need a new kernel with option TMPFS enabled, fresh include
> >files and mount_tmpfs. tmpfs is a better MFS, it is faster and can
> >free unused memory.
>
> I have put up an updated diff at:
>
&
What kind of numbers are we talking about here? I have an mfs on a box
where I have had to bump the inodes in order to accomodate a huge amount of
small files.
Around 1100k files across all tmpfs mount points. Anything beyond
that limit will get you a ENOSPC error. That is obviously a bug, but
2013/3/27 Pedro Martelletto
> Hi,
>
> I have ported NetBSD's tmpfs to OpenBSD. The port should be functional
> on i386 and amd64. I haven't tested on other architectures. There are
> limitations: update of mount options is not supported and the number of
> nodes in a
I have ported NetBSD's tmpfs to OpenBSD. The port should be functional
on i386 and amd64. I haven't tested on other architectures. There are
limitations: update of mount options is not supported and the number of
nodes in a tmpfs file system is limited by the number of anonymous UVM
Hi,
I have ported NetBSD's tmpfs to OpenBSD. The port should be functional
on i386 and amd64. I haven't tested on other architectures. There are
limitations: update of mount options is not supported and the number of
nodes in a tmpfs file system is limited by the number of anonymous U
87 matches
Mail list logo
