Re: Thoughts on TMPFS no longer being considered "highly experimental"
Peter Holm wrote: > On Fri, Jun 24, 2011 at 10:57:16PM +0300, Kostik Belousov wrote: > > On Fri, Jun 24, 2011 at 06:20:03PM +0200, Peter Holm wrote: > > > Got a "panic: Not a vnode object" quite fast: > > > > > > http://people.freebsd.org/~pho/stress/log/kostik441.txt > > > > Ah, yes, this is an assertion that was added in the r209702. > > http://people.freebsd.org/~kib/misc/tmpfs.7.patch > > Looks good. The mmap(2) test doesn't panic any more, nor does any of > the other TMPFS tests I have. Is this patch under consideration for inclusion in 9.0? b. ___ 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: Thoughts on TMPFS no longer being considered "highly experimental"
On Fri, 01.07.2011 at 11:33:42 -0400, Sean M. Collins wrote: > On 7/1/11 2:42 AM, Stefan Bethke wrote: > > The box shouldn't wedge in this situation. If tmpfs can create > > a memory starvation situation on the kernel level, it is not > production ready. > > The full message was "swap zone exhausted, increase kern.maxswzone" - I > guess that actual swap wasn't exhausted, but just space for metadata. So > in tmpfs' defense, AMD64 boots with a kern.maxswzone of 32MB like i386, > which only allows ~7 GB of swap to be allocated. > > I'll see if I can get the machine to wedge again, then increase > kern.maxswzone, and repeat. You just cannot use them both, yet. On amd64 with 8GB of RAM and a ZFS volume that is a couple of hundred G (and world-readable) - Run with tmpfs /tmp - Wait overnight for /etc/periodic/weekly/310.locate to kick in - Come back next morning and have 0 bytes free in /tmp Exporting the pool might bring the memory back, but with open files on the pool and of course in /tmp (think Xorg ...) this is impractical. Uli ___ 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: Thoughts on TMPFS no longer being considered "highly experimental"
On 7/1/11 2:42 AM, Stefan Bethke wrote: > The box shouldn't wedge in this situation. If tmpfs can create > a memory starvation situation on the kernel level, it is not production ready. The full message was "swap zone exhausted, increase kern.maxswzone" - I guess that actual swap wasn't exhausted, but just space for metadata. So in tmpfs' defense, AMD64 boots with a kern.maxswzone of 32MB like i386, which only allows ~7 GB of swap to be allocated. I'll see if I can get the machine to wedge again, then increase kern.maxswzone, and repeat. -- Sean Collins Core IT Pro, LLC www.coreitpro.com ___ 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: Thoughts on TMPFS no longer being considered "highly experimental"
Am 01.07.2011 um 07:01 schrieb Sean M. Collins: > Ugh - bonnie++ creates a file that is twice the size of available > memory, and I have 16G of swap available. While ZFS already had most of > the memory wired for ARC. I shouldn't be surprised that the box was > printing "swap zone exhausted" The box shouldn't wedge in this situation. If tmpfs can create a memory starvation situation on the kernel level, it is not production ready. Stefan -- Stefan BethkeFon +49 151 14070811 ___ 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: Thoughts on TMPFS no longer being considered "highly experimental"
Ugh - bonnie++ creates a file that is twice the size of available memory, and I have 16G of swap available. While ZFS already had most of the memory wired for ARC. I shouldn't be surprised that the box was printing "swap zone exhausted" I'm an idiot. Can we replace the warning message with one about dumb operators? ;) -- Sean Collins Core IT Pro, LLC www.coreitpro.com ___ 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: Thoughts on TMPFS no longer being considered "highly experimental"
> Maybe i'm missing something but creating/removing large number of files > in one directory on tmpfs was very slow for me. That was long ago and > ZFS was in so i'll try to retest... I decided to torture test tmpfs with bonnie++ on one of my machines and the machine wedged. I can ping it but that's about it. Originally I was in favor of removing the warning, but now, not so much. -- Sean Collins Core IT Pro, LLC www.coreitpro.com ___ 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: Thoughts on TMPFS no longer being considered "highly experimental"
23.06.2011 19:31, David O'Brien wrote: Does anyone object to this patch? David Wolfskill and I have run TMPFS on a number of machines for two years with no problems. I may have missed something, but I'm not aware of any serious PRs on TMPFS either. Maybe i'm missing something but creating/removing large number of files in one directory on tmpfs was very slow for me. That was long ago and ZFS was in so i'll try to retest... -- Sphinx of black quartz judge my vow. ___ 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: Thoughts on TMPFS no longer being considered "highly experimental"
On Mon, Jun 27, 2011 at 10:42:07AM -0700, David O'Brien wrote: > Hi KIB, > Thanks for the list of issues you know about -- I don't believe we have > PRs covering those. > > > On Thu, Jun 23, 2011 at 11:21:53PM +0300, Kostik Belousov wrote: > > - I believe Peter Holm has more test cases that fails with tmpfs. He > > would have more details. I somewhat remember some panic on execve(2) the > > binary located on tmpfs. > > I've been following the patches you've been passing to Peter Holm as part > of this thread. Seems good progress has been made in fixing some of the > issues. > > > > Removing the warning will not make the issues coming away. > > Quite true, but is there any other subsystem where we know we have bugs > and have put up such a scary warning? > > I've never used ZFS on i386, but I understand it is trivial to panic > with out-of-the-box settings. We don't print a dire warning for ZFS > usage on 32-bit platforms. So I'm not sure we should keep it for TMPFS. > > I cannot tell from your response if you're OK or against removing > the warning. [especially if your patches pass the Peter Holm test > and remove some of the bugs] If anything, the removal of the said warning would reduce the kernel text size. Probably, it should be moved to the man page, which already has similar, but not that strong, wording. pgpP7oIgmHhTr.pgp Description: PGP signature
Re: Thoughts on TMPFS no longer being considered "highly experimental"
On 27 June 2011 17:42, David O'Brien wrote: > Hi KIB, > Thanks for the list of issues you know about -- I don't believe we have > PRs covering those. > > > On Thu, Jun 23, 2011 at 11:21:53PM +0300, Kostik Belousov wrote: >> - I believe Peter Holm has more test cases that fails with tmpfs. He >> would have more details. I somewhat remember some panic on execve(2) the >> binary located on tmpfs. > > I've been following the patches you've been passing to Peter Holm as part > of this thread. Seems good progress has been made in fixing some of the > issues. > > >> Removing the warning will not make the issues coming away. > > Quite true, but is there any other subsystem where we know we have bugs > and have put up such a scary warning? > > I've never used ZFS on i386, but I understand it is trivial to panic > with out-of-the-box settings. We don't print a dire warning for ZFS > usage on 32-bit platforms. So I'm not sure we should keep it for TMPFS. > amd64 with 4G ram is also not the best for heavy-loaded ZFS server. I have to increase kernel memory up to 1.5-2 G to be sure if it works stable and fast. -- Eir Nym > > I cannot tell from your response if you're OK or against removing > the warning. [especially if your patches pass the Peter Holm test > and remove some of the bugs] > > -- > -- David (obr...@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" > ___ 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: Thoughts on TMPFS no longer being considered "highly experimental"
Hi KIB, Thanks for the list of issues you know about -- I don't believe we have PRs covering those. On Thu, Jun 23, 2011 at 11:21:53PM +0300, Kostik Belousov wrote: > - I believe Peter Holm has more test cases that fails with tmpfs. He > would have more details. I somewhat remember some panic on execve(2) the > binary located on tmpfs. I've been following the patches you've been passing to Peter Holm as part of this thread. Seems good progress has been made in fixing some of the issues. > Removing the warning will not make the issues coming away. Quite true, but is there any other subsystem where we know we have bugs and have put up such a scary warning? I've never used ZFS on i386, but I understand it is trivial to panic with out-of-the-box settings. We don't print a dire warning for ZFS usage on 32-bit platforms. So I'm not sure we should keep it for TMPFS. I cannot tell from your response if you're OK or against removing the warning. [especially if your patches pass the Peter Holm test and remove some of the bugs] -- -- David (obr...@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: Thoughts on TMPFS no longer being considered "highly experimental"
On Fri, Jun 24, 2011 at 10:57:16PM +0300, Kostik Belousov wrote: > On Fri, Jun 24, 2011 at 06:20:03PM +0200, Peter Holm wrote: > > Got a "panic: Not a vnode object" quite fast: > > > > http://people.freebsd.org/~pho/stress/log/kostik441.txt > > Ah, yes, this is an assertion that was added in the r209702. > http://people.freebsd.org/~kib/misc/tmpfs.7.patch Looks good. The mmap(2) test doesn't panic any more, nor does any of the other TMPFS tests I have. - Peter ___ 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: Thoughts on TMPFS no longer being considered "highly experimental"
On Fri, Jun 24, 2011 at 06:20:03PM +0200, Peter Holm wrote: > Got a "panic: Not a vnode object" quite fast: > > http://people.freebsd.org/~pho/stress/log/kostik441.txt Ah, yes, this is an assertion that was added in the r209702. http://people.freebsd.org/~kib/misc/tmpfs.7.patch pgpfCkfwvYyso.pgp Description: PGP signature
Re: Thoughts on TMPFS no longer being considered "highly experimental"
On Fri, Jun 24, 2011 at 05:50:43PM +0300, Kostik Belousov wrote:
> On Fri, Jun 24, 2011 at 03:21:05PM +0200, Peter Holm wrote:
> > On Fri, Jun 24, 2011 at 02:06:27PM +0300, Kostik Belousov wrote:
> > > On Fri, Jun 24, 2011 at 12:30:16PM +0200, Peter Holm wrote:
> > > > On Thu, Jun 23, 2011 at 11:21:53PM +0300, Kostik Belousov wrote:
> > > > > On Thu, Jun 23, 2011 at 09:31:09AM -0700, David O'Brien wrote:
> > > > > > Does anyone object to this patch?
> > > > > >
> > > > > > David Wolfskill and I have run TMPFS on a number of machines for two
> > > > > > years with no problems.
> > > > > >
> > > > > > I may have missed something, but I'm not aware of any serious PRs on
> > > > > > TMPFS either.
> > > > > >
> > > > > >
> > > > > > Index: tmpfs_vfsops.c
> > > > > > ===
> > > > > > --- tmpfs_vfsops.c (revision 221113)
> > > > > > +++ tmpfs_vfsops.c (working copy)
> > > > > > @@ -155,9 +155,6 @@ tmpfs_mount(struct mount *mp)
> > > > > > return EOPNOTSUPP;
> > > > > > }
> > > > > >
> > > > > > - printf("WARNING: TMPFS is considered to be a highly
> > > > > > experimental "
> > > > > > - "feature in FreeBSD.\n");
> > > > > > -
> > > > > > vn_lock(mp->mnt_vnodecovered, LK_SHARED | LK_RETRY);
> > > > > > error = VOP_GETATTR(mp->mnt_vnodecovered, &va, mp->mnt_cred);
> > > > > > VOP_UNLOCK(mp->mnt_vnodecovered, 0);
> > > > >
> > > > > The things I am aware of:
> > > > > - there is a races on the lookup. They were papered over in r212305,
> > > > > but the bug was not really fixed, AFAIR.
> > > > >
> > > > > - the tmpfs does double-buffering for the mapped vnodes. This is quite
> > > > > insulting for the memory-backed fs, isn't it ? I have a patch, but it
> > > > > is
> > > > > still under review.
> > > > >
> > > > > - I believe Peter Holm has more test cases that fails with tmpfs. He
> > > > > would have more details. I somewhat remember some panic on execve(2)
> > > > > the
> > > > > binary located on tmpfs.
> > > > >
> > > >
> > > > I ran the TMPFS tests I have and so far I only spotted the mmap(2)
> > > > problem:
> > > >
> > > > http://people.freebsd.org/~pho/stress/log/tmpfs/
> > > It would be indeed good if the issue was the only remaining problem.
> >
> > Well, more testing is needed for sure.
> >
> > > The deadlock in tmpfs6.txt is caused by doing copyin() while having
> > > a page busied. This should be fixed indirectly by the patch to
> > > avoid double-buffering, I uploaded the latest version at
> > > http://people.freebsd.org/~kib/misc/tmpfs.5.patch
> > >
> > > >
> > > > > Removing the warning will not make the issues coming away.
> > > >
> >
> > This doesn't compile:
> >
> > ===> tmpfs (all)
> > cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc
> > -DHAVE_KERNEL_OPTION_HEADERS -include
> > /usr/src/sys/i386/compile/PHO/opt_global.h -I. -I@ -I@/contrib/altq
> > -finline-limit=8000 --param inline-unit-growth=100 --param
> > large-function-growth=1000 -fno-common -g -I/usr/src/sys/i386/compile/PHO
> > -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse
> > -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999
> > -fstack-protector -Wall -Wredundant-decls -Wnested-externs
> > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline
> > -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions
> > -Wmissing-include-dirs -fdiagnostics-show-option -c
> > /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c
> > cc1: warnings being treated as errors
> > /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c: In function
> > 'tmpfs_reg_resize':
> > /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c:911: warning: 'uobj'
> > is used uninitialized in this function
> > *** Error code 1
>
> Yes, the patch has rotten. Please try
> http://people.freebsd.org/~kib/misc/tmpfs.6.patch
Got a "panic: Not a vnode object" quite fast:
http://people.freebsd.org/~pho/stress/log/kostik441.txt
- Peter
___
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: Thoughts on TMPFS no longer being considered "highly experimental"
On Fri, Jun 24, 2011 at 03:21:05PM +0200, Peter Holm wrote:
> On Fri, Jun 24, 2011 at 02:06:27PM +0300, Kostik Belousov wrote:
> > On Fri, Jun 24, 2011 at 12:30:16PM +0200, Peter Holm wrote:
> > > On Thu, Jun 23, 2011 at 11:21:53PM +0300, Kostik Belousov wrote:
> > > > On Thu, Jun 23, 2011 at 09:31:09AM -0700, David O'Brien wrote:
> > > > > Does anyone object to this patch?
> > > > >
> > > > > David Wolfskill and I have run TMPFS on a number of machines for two
> > > > > years with no problems.
> > > > >
> > > > > I may have missed something, but I'm not aware of any serious PRs on
> > > > > TMPFS either.
> > > > >
> > > > >
> > > > > Index: tmpfs_vfsops.c
> > > > > ===
> > > > > --- tmpfs_vfsops.c(revision 221113)
> > > > > +++ tmpfs_vfsops.c(working copy)
> > > > > @@ -155,9 +155,6 @@ tmpfs_mount(struct mount *mp)
> > > > > return EOPNOTSUPP;
> > > > > }
> > > > >
> > > > > - printf("WARNING: TMPFS is considered to be a highly
> > > > > experimental "
> > > > > - "feature in FreeBSD.\n");
> > > > > -
> > > > > vn_lock(mp->mnt_vnodecovered, LK_SHARED | LK_RETRY);
> > > > > error = VOP_GETATTR(mp->mnt_vnodecovered, &va, mp->mnt_cred);
> > > > > VOP_UNLOCK(mp->mnt_vnodecovered, 0);
> > > >
> > > > The things I am aware of:
> > > > - there is a races on the lookup. They were papered over in r212305,
> > > > but the bug was not really fixed, AFAIR.
> > > >
> > > > - the tmpfs does double-buffering for the mapped vnodes. This is quite
> > > > insulting for the memory-backed fs, isn't it ? I have a patch, but it is
> > > > still under review.
> > > >
> > > > - I believe Peter Holm has more test cases that fails with tmpfs. He
> > > > would have more details. I somewhat remember some panic on execve(2) the
> > > > binary located on tmpfs.
> > > >
> > >
> > > I ran the TMPFS tests I have and so far I only spotted the mmap(2)
> > > problem:
> > >
> > > http://people.freebsd.org/~pho/stress/log/tmpfs/
> > It would be indeed good if the issue was the only remaining problem.
>
> Well, more testing is needed for sure.
>
> > The deadlock in tmpfs6.txt is caused by doing copyin() while having
> > a page busied. This should be fixed indirectly by the patch to
> > avoid double-buffering, I uploaded the latest version at
> > http://people.freebsd.org/~kib/misc/tmpfs.5.patch
> >
> > >
> > > > Removing the warning will not make the issues coming away.
> > >
>
> This doesn't compile:
>
> ===> tmpfs (all)
> cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc
> -DHAVE_KERNEL_OPTION_HEADERS -include
> /usr/src/sys/i386/compile/PHO/opt_global.h -I. -I@ -I@/contrib/altq
> -finline-limit=8000 --param inline-unit-growth=100 --param
> large-function-growth=1000 -fno-common -g -I/usr/src/sys/i386/compile/PHO
> -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse
> -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999
> -fstack-protector -Wall -Wredundant-decls -Wnested-externs
> -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline
> -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions
> -Wmissing-include-dirs -fdiagnostics-show-option -c
> /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c
> cc1: warnings being treated as errors
> /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c: In function
> 'tmpfs_reg_resize':
> /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c:911: warning: 'uobj'
> is used uninitialized in this function
> *** Error code 1
Yes, the patch has rotten. Please try
http://people.freebsd.org/~kib/misc/tmpfs.6.patch
pgpBvmO286bc6.pgp
Description: PGP signature
Re: Thoughts on TMPFS no longer being considered "highly experimental"
On Fri, Jun 24, 2011 at 02:06:27PM +0300, Kostik Belousov wrote:
> On Fri, Jun 24, 2011 at 12:30:16PM +0200, Peter Holm wrote:
> > On Thu, Jun 23, 2011 at 11:21:53PM +0300, Kostik Belousov wrote:
> > > On Thu, Jun 23, 2011 at 09:31:09AM -0700, David O'Brien wrote:
> > > > Does anyone object to this patch?
> > > >
> > > > David Wolfskill and I have run TMPFS on a number of machines for two
> > > > years with no problems.
> > > >
> > > > I may have missed something, but I'm not aware of any serious PRs on
> > > > TMPFS either.
> > > >
> > > >
> > > > Index: tmpfs_vfsops.c
> > > > ===
> > > > --- tmpfs_vfsops.c (revision 221113)
> > > > +++ tmpfs_vfsops.c (working copy)
> > > > @@ -155,9 +155,6 @@ tmpfs_mount(struct mount *mp)
> > > > return EOPNOTSUPP;
> > > > }
> > > >
> > > > - printf("WARNING: TMPFS is considered to be a highly
> > > > experimental "
> > > > - "feature in FreeBSD.\n");
> > > > -
> > > > vn_lock(mp->mnt_vnodecovered, LK_SHARED | LK_RETRY);
> > > > error = VOP_GETATTR(mp->mnt_vnodecovered, &va, mp->mnt_cred);
> > > > VOP_UNLOCK(mp->mnt_vnodecovered, 0);
> > >
> > > The things I am aware of:
> > > - there is a races on the lookup. They were papered over in r212305,
> > > but the bug was not really fixed, AFAIR.
> > >
> > > - the tmpfs does double-buffering for the mapped vnodes. This is quite
> > > insulting for the memory-backed fs, isn't it ? I have a patch, but it is
> > > still under review.
> > >
> > > - I believe Peter Holm has more test cases that fails with tmpfs. He
> > > would have more details. I somewhat remember some panic on execve(2) the
> > > binary located on tmpfs.
> > >
> >
> > I ran the TMPFS tests I have and so far I only spotted the mmap(2)
> > problem:
> >
> > http://people.freebsd.org/~pho/stress/log/tmpfs/
> It would be indeed good if the issue was the only remaining problem.
Well, more testing is needed for sure.
> The deadlock in tmpfs6.txt is caused by doing copyin() while having
> a page busied. This should be fixed indirectly by the patch to
> avoid double-buffering, I uploaded the latest version at
> http://people.freebsd.org/~kib/misc/tmpfs.5.patch
>
> >
> > > Removing the warning will not make the issues coming away.
> >
This doesn't compile:
===> tmpfs (all)
cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc
-DHAVE_KERNEL_OPTION_HEADERS -include
/usr/src/sys/i386/compile/PHO/opt_global.h -I. -I@ -I@/contrib/altq
-finline-limit=8000 --param inline-unit-growth=100 --param
large-function-growth=1000 -fno-common -g -I/usr/src/sys/i386/compile/PHO
-mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse
-mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999
-fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline
-Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions
-Wmissing-include-dirs -fdiagnostics-show-option -c
/usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c
cc1: warnings being treated as errors
/usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c: In function
'tmpfs_reg_resize':
/usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c:911: warning: 'uobj' is
used uninitialized in this function
*** Error code 1
886 int
887 tmpfs_reg_resize(struct vnode *vp, off_t newsize)
888 {
889 struct tmpfs_mount *tmp;
890 struct tmpfs_node *node;
891 vm_object_t uobj;
892 vm_page_t m;
893 vm_pindex_t newpages, oldpages;
894 off_t oldsize;
895 size_t zerolen;
896
897 MPASS(vp->v_type == VREG);
898 MPASS(newsize >= 0);
899
900 node = VP_TO_TMPFS_NODE(vp);
901 tmp = VFS_TO_TMPFS(vp->v_mount);
902
903 /*
904 * Convert the old and new sizes to the number of pages needed to
905 * store them. It may happen that we do not need to do anything
906 * because the last allocated page can accommodate the change on
907 * its own.
908 */
909 oldsize = node->tn_size;
910 oldpages = OFF_TO_IDX(oldsize + PAGE_MASK);
911 MPASS(oldpages == uobj->size);
912 newpages = OFF_TO_IDX(newsize + PAGE_MASK);
913 if (newpages > oldpages &&
914 newpages - oldpages > TMPFS_PAGES_AVAIL(tmp))
915 return (ENOSPC);
916
917 TMPFS_LOCK(tmp);
918 tmp->tm_pages_used += (newpages - oldpages);
919 TMPFS_UNLOCK(tmp);
920
921 node->tn_size = newsize;
922 VM_OBJECT_LOCK(uobj);
- Peter
___
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: Thoughts on TMPFS no longer being considered "highly experimental"
On Fri, Jun 24, 2011 at 12:30:16PM +0200, Peter Holm wrote:
> On Thu, Jun 23, 2011 at 11:21:53PM +0300, Kostik Belousov wrote:
> > On Thu, Jun 23, 2011 at 09:31:09AM -0700, David O'Brien wrote:
> > > Does anyone object to this patch?
> > >
> > > David Wolfskill and I have run TMPFS on a number of machines for two
> > > years with no problems.
> > >
> > > I may have missed something, but I'm not aware of any serious PRs on
> > > TMPFS either.
> > >
> > >
> > > Index: tmpfs_vfsops.c
> > > ===
> > > --- tmpfs_vfsops.c(revision 221113)
> > > +++ tmpfs_vfsops.c(working copy)
> > > @@ -155,9 +155,6 @@ tmpfs_mount(struct mount *mp)
> > > return EOPNOTSUPP;
> > > }
> > >
> > > - printf("WARNING: TMPFS is considered to be a highly experimental "
> > > - "feature in FreeBSD.\n");
> > > -
> > > vn_lock(mp->mnt_vnodecovered, LK_SHARED | LK_RETRY);
> > > error = VOP_GETATTR(mp->mnt_vnodecovered, &va, mp->mnt_cred);
> > > VOP_UNLOCK(mp->mnt_vnodecovered, 0);
> >
> > The things I am aware of:
> > - there is a races on the lookup. They were papered over in r212305,
> > but the bug was not really fixed, AFAIR.
> >
> > - the tmpfs does double-buffering for the mapped vnodes. This is quite
> > insulting for the memory-backed fs, isn't it ? I have a patch, but it is
> > still under review.
> >
> > - I believe Peter Holm has more test cases that fails with tmpfs. He
> > would have more details. I somewhat remember some panic on execve(2) the
> > binary located on tmpfs.
> >
>
> I ran the TMPFS tests I have and so far I only spotted the mmap(2)
> problem:
>
> http://people.freebsd.org/~pho/stress/log/tmpfs/
It would be indeed good if the issue was the only remaining problem.
The deadlock in tmpfs6.txt is caused by doing copyin() while having
a page busied. This should be fixed indirectly by the patch to
avoid double-buffering, I uploaded the latest version at
http://people.freebsd.org/~kib/misc/tmpfs.5.patch
>
> > Removing the warning will not make the issues coming away.
>
pgpG7yzLh0Ehi.pgp
Description: PGP signature
Re: Thoughts on TMPFS no longer being considered "highly experimental"
On Thu, Jun 23, 2011 at 11:21:53PM +0300, Kostik Belousov wrote:
> On Thu, Jun 23, 2011 at 09:31:09AM -0700, David O'Brien wrote:
> > Does anyone object to this patch?
> >
> > David Wolfskill and I have run TMPFS on a number of machines for two
> > years with no problems.
> >
> > I may have missed something, but I'm not aware of any serious PRs on
> > TMPFS either.
> >
> >
> > Index: tmpfs_vfsops.c
> > ===
> > --- tmpfs_vfsops.c (revision 221113)
> > +++ tmpfs_vfsops.c (working copy)
> > @@ -155,9 +155,6 @@ tmpfs_mount(struct mount *mp)
> > return EOPNOTSUPP;
> > }
> >
> > - printf("WARNING: TMPFS is considered to be a highly experimental "
> > - "feature in FreeBSD.\n");
> > -
> > vn_lock(mp->mnt_vnodecovered, LK_SHARED | LK_RETRY);
> > error = VOP_GETATTR(mp->mnt_vnodecovered, &va, mp->mnt_cred);
> > VOP_UNLOCK(mp->mnt_vnodecovered, 0);
>
> The things I am aware of:
> - there is a races on the lookup. They were papered over in r212305,
> but the bug was not really fixed, AFAIR.
>
> - the tmpfs does double-buffering for the mapped vnodes. This is quite
> insulting for the memory-backed fs, isn't it ? I have a patch, but it is
> still under review.
>
> - I believe Peter Holm has more test cases that fails with tmpfs. He
> would have more details. I somewhat remember some panic on execve(2) the
> binary located on tmpfs.
>
I ran the TMPFS tests I have and so far I only spotted the mmap(2)
problem:
http://people.freebsd.org/~pho/stress/log/tmpfs/
> Removing the warning will not make the issues coming away.
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (FreeBSD)
>
> iEYEARECAAYFAk4DoGEACgkQC3+MBN1Mb4j9wwCg0V37VuQUw5heAl/Z/iAlO+h0
> SmAAoJf/+BF533SS0hUjGsscsSAqUApX
> =5GKO
> -END PGP SIGNATURE-
--
Peter
___
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: Thoughts on TMPFS no longer being considered "highly experimental"
On (23/06/2011 20:44), Olivier Smedts wrote: > 2011/6/23 Alexander V. Chernikov : > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > Matthew Jacob wrote: > >> > >> I gave up on using it after a brief try earlier this year. I can't > >> remember the details, but it did lock up my amd64 system. > >> > >> On Thu, 23 Jun 2011, David O'Brien wrote: > >> > >>> Does anyone object to this patch? > >>> > >>> David Wolfskill and I have run TMPFS on a number of machines for two > >>> years with no problems. > >>> > >>> I may have missed something, but I'm not aware of any serious PRs on > >>> TMPFS either. > > > > There was some issues with sendfile(2) and mmap(2) causing kernel hangs > > in some cases. vim triggers such hangs for me. However, those problems > > were fixed and MFCed (afair). > > > > I'm using tmpfs on several machines in production without any problems. > > Maybe being _highly_ experimental for nearly 4 years is enough? :) > > I think there are still problems with high wired memory consumers like > ZFS. I've got 0-sized tmpfs with 8GB RAM + ZFS with 4GB ARC + 4GB > swap. There is a patch to make tmpfs memory management more strict (more aggressive), and set default partition size to half of all memory. http://marc.info/?l=freebsd-fs&m=129747362722933&w=2 ___ 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: Thoughts on TMPFS no longer being considered "highly experimental"
On Thu, Jun 23, 2011 at 09:31:09AM -0700, David O'Brien wrote:
> Does anyone object to this patch?
>
> David Wolfskill and I have run TMPFS on a number of machines for two
> years with no problems.
>
> I may have missed something, but I'm not aware of any serious PRs on
> TMPFS either.
>
>
> Index: tmpfs_vfsops.c
> ===
> --- tmpfs_vfsops.c(revision 221113)
> +++ tmpfs_vfsops.c(working copy)
> @@ -155,9 +155,6 @@ tmpfs_mount(struct mount *mp)
> return EOPNOTSUPP;
> }
>
> - printf("WARNING: TMPFS is considered to be a highly experimental "
> - "feature in FreeBSD.\n");
> -
> vn_lock(mp->mnt_vnodecovered, LK_SHARED | LK_RETRY);
> error = VOP_GETATTR(mp->mnt_vnodecovered, &va, mp->mnt_cred);
> VOP_UNLOCK(mp->mnt_vnodecovered, 0);
The things I am aware of:
- there is a races on the lookup. They were papered over in r212305,
but the bug was not really fixed, AFAIR.
- the tmpfs does double-buffering for the mapped vnodes. This is quite
insulting for the memory-backed fs, isn't it ? I have a patch, but it is
still under review.
- I believe Peter Holm has more test cases that fails with tmpfs. He
would have more details. I somewhat remember some panic on execve(2) the
binary located on tmpfs.
Removing the warning will not make the issues coming away.
pgpJs4JMIlpaE.pgp
Description: PGP signature
Re: Thoughts on TMPFS no longer being considered "highly experimental"
I may have missed something, but I'm not aware of any serious PRs on TMPFS either. There was some issues with sendfile(2) and mmap(2) causing kernel hangs in some cases. vim triggers such hangs for me. However, those problems were fixed and MFCed (afair). Can you sway when? ___ 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: Thoughts on TMPFS no longer being considered "highly experimental"
2011/6/23 Alexander V. Chernikov :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Matthew Jacob wrote:
>>
>> I gave up on using it after a brief try earlier this year. I can't
>> remember the details, but it did lock up my amd64 system.
>>
>> On Thu, 23 Jun 2011, David O'Brien wrote:
>>
>>> Does anyone object to this patch?
>>>
>>> David Wolfskill and I have run TMPFS on a number of machines for two
>>> years with no problems.
>>>
>>> I may have missed something, but I'm not aware of any serious PRs on
>>> TMPFS either.
>
> There was some issues with sendfile(2) and mmap(2) causing kernel hangs
> in some cases. vim triggers such hangs for me. However, those problems
> were fixed and MFCed (afair).
>
> I'm using tmpfs on several machines in production without any problems.
> Maybe being _highly_ experimental for nearly 4 years is enough? :)
I think there are still problems with high wired memory consumers like
ZFS. I've got 0-sized tmpfs with 8GB RAM + ZFS with 4GB ARC + 4GB
swap.
>>>
>>>
>>> Index: tmpfs_vfsops.c
>>> ===
>>> --- tmpfs_vfsops.c (revision 221113)
>>> +++ tmpfs_vfsops.c (working copy)
>>> @@ -155,9 +155,6 @@ tmpfs_mount(struct mount *mp)
>>> return EOPNOTSUPP;
>>> }
>>>
>>> - printf("WARNING: TMPFS is considered to be a highly experimental "
>>> - "feature in FreeBSD.\n");
>>> -
>>> vn_lock(mp->mnt_vnodecovered, LK_SHARED | LK_RETRY);
>>> error = VOP_GETATTR(mp->mnt_vnodecovered, &va, mp->mnt_cred);
>>> VOP_UNLOCK(mp->mnt_vnodecovered, 0);
>>>
>>> --
>>> -- David (obr...@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"
>>>
>> ___
>> 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"
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.14 (FreeBSD)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk4Dg1cACgkQwcJ4iSZ1q2m3uACfcUoGrQeAZdAHDm8VnbKInzWI
> gIoAn3SMoNAdABZ39GHS6HSyIHLXGNIt
> =aXnk
> -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"
>
--
Olivier Smedts _
ASCII ribbon campaign ( )
e-mail: oliv...@gid0.org - against HTML email & vCards X
www: http://www.gid0.org - against proprietary attachments / \
"Il y a seulement 10 sortes de gens dans le monde :
ceux qui comprennent le binaire,
et ceux qui ne le comprennent pas."
___
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: Thoughts on TMPFS no longer being considered "highly experimental"
On 23 June 2011 17:31, David O'Brien wrote:
> Does anyone object to this patch?
>
> David Wolfskill and I have run TMPFS on a number of machines for two
> years with no problems.
>
> I may have missed something, but I'm not aware of any serious PRs on
> TMPFS either.
>
>
> Index: tmpfs_vfsops.c
> ===
> --- tmpfs_vfsops.c (revision 221113)
> +++ tmpfs_vfsops.c (working copy)
> @@ -155,9 +155,6 @@ tmpfs_mount(struct mount *mp)
> return EOPNOTSUPP;
> }
>
> - printf("WARNING: TMPFS is considered to be a highly experimental "
> - "feature in FreeBSD.\n");
> -
> vn_lock(mp->mnt_vnodecovered, LK_SHARED | LK_RETRY);
> error = VOP_GETATTR(mp->mnt_vnodecovered, &va, mp->mnt_cred);
> VOP_UNLOCK(mp->mnt_vnodecovered, 0);
>
> --
> -- David (obr...@freebsd.org)
How about noting that no-one's managed to get it to work correctly
with ZFS yet, but fine with UFS?
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: Thoughts on TMPFS no longer being considered "highly experimental"
Hi,
Sounds good to me. The tmpfs(5) man page should be patched also.
--
Craig Rodrigues
rodr...@crodrigues.org
On Thu, Jun 23, 2011 at 9:31 AM, David O'Brien wrote:
> Does anyone object to this patch?
>
> David Wolfskill and I have run TMPFS on a number of machines for two
> years with no problems.
>
> I may have missed something, but I'm not aware of any serious PRs on
> TMPFS either.
>
>
> Index: tmpfs_vfsops.c
> ===
> --- tmpfs_vfsops.c (revision 221113)
> +++ tmpfs_vfsops.c (working copy)
> @@ -155,9 +155,6 @@ tmpfs_mount(struct mount *mp)
>return EOPNOTSUPP;
>}
>
> - printf("WARNING: TMPFS is considered to be a highly experimental "
> - "feature in FreeBSD.\n");
> -
>vn_lock(mp->mnt_vnodecovered, LK_SHARED | LK_RETRY);
>error = VOP_GETATTR(mp->mnt_vnodecovered, &va, mp->mnt_cred);
>VOP_UNLOCK(mp->mnt_vnodecovered, 0);
>
> --
> -- David (obr...@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"
>
--
Craig Rodrigues
rodr...@rodrigues.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: Thoughts on TMPFS no longer being considered "highly experimental"
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Matthew Jacob wrote:
>
> I gave up on using it after a brief try earlier this year. I can't
> remember the details, but it did lock up my amd64 system.
>
> On Thu, 23 Jun 2011, David O'Brien wrote:
>
>> Does anyone object to this patch?
>>
>> David Wolfskill and I have run TMPFS on a number of machines for two
>> years with no problems.
>>
>> I may have missed something, but I'm not aware of any serious PRs on
>> TMPFS either.
There was some issues with sendfile(2) and mmap(2) causing kernel hangs
in some cases. vim triggers such hangs for me. However, those problems
were fixed and MFCed (afair).
I'm using tmpfs on several machines in production without any problems.
Maybe being _highly_ experimental for nearly 4 years is enough? :)
>>
>>
>> Index: tmpfs_vfsops.c
>> ===
>> --- tmpfs_vfsops.c(revision 221113)
>> +++ tmpfs_vfsops.c(working copy)
>> @@ -155,9 +155,6 @@ tmpfs_mount(struct mount *mp)
>> return EOPNOTSUPP;
>> }
>>
>> -printf("WARNING: TMPFS is considered to be a highly experimental "
>> -"feature in FreeBSD.\n");
>> -
>> vn_lock(mp->mnt_vnodecovered, LK_SHARED | LK_RETRY);
>> error = VOP_GETATTR(mp->mnt_vnodecovered, &va, mp->mnt_cred);
>> VOP_UNLOCK(mp->mnt_vnodecovered, 0);
>>
>> --
>> -- David (obr...@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"
>>
> ___
> 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"
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk4Dg1cACgkQwcJ4iSZ1q2m3uACfcUoGrQeAZdAHDm8VnbKInzWI
gIoAn3SMoNAdABZ39GHS6HSyIHLXGNIt
=aXnk
-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: Thoughts on TMPFS no longer being considered "highly experimental"
On Thu Jun 23 11, Matthew Jacob wrote:
>
> I gave up on using it after a brief try earlier this year. I can't
> remember the details, but it did lock up my amd64 system.
>
> On Thu, 23 Jun 2011, David O'Brien wrote:
>
> >Does anyone object to this patch?
> >
> >David Wolfskill and I have run TMPFS on a number of machines for two
> >years with no problems.
+1 here. i haven't experienced any issues for > 1 year or so, but if people
think removing the warning entirely is too early, maybe the warning can be
rephrased in order to be less frightening.
maybe sth like:
"TMPFS still needs wider testing and thus should not be considered ready for
production use, yet."
cheers.
alex
> >
> >I may have missed something, but I'm not aware of any serious PRs on
> >TMPFS either.
> >
> >
> >Index: tmpfs_vfsops.c
> >===
> >--- tmpfs_vfsops.c (revision 221113)
> >+++ tmpfs_vfsops.c (working copy)
> >@@ -155,9 +155,6 @@ tmpfs_mount(struct mount *mp)
> > return EOPNOTSUPP;
> > }
> >
> >-printf("WARNING: TMPFS is considered to be a highly experimental "
> >-"feature in FreeBSD.\n");
> >-
> > vn_lock(mp->mnt_vnodecovered, LK_SHARED | LK_RETRY);
> > error = VOP_GETATTR(mp->mnt_vnodecovered, &va, mp->mnt_cred);
> > VOP_UNLOCK(mp->mnt_vnodecovered, 0);
> >
> >--
> >-- David (obr...@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"
> >
___
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: Thoughts on TMPFS no longer being considered "highly experimental"
I gave up on using it after a brief try earlier this year. I can't
remember the details, but it did lock up my amd64 system.
On Thu, 23 Jun 2011, David O'Brien wrote:
Does anyone object to this patch?
David Wolfskill and I have run TMPFS on a number of machines for two
years with no problems.
I may have missed something, but I'm not aware of any serious PRs on
TMPFS either.
Index: tmpfs_vfsops.c
===
--- tmpfs_vfsops.c (revision 221113)
+++ tmpfs_vfsops.c (working copy)
@@ -155,9 +155,6 @@ tmpfs_mount(struct mount *mp)
return EOPNOTSUPP;
}
- printf("WARNING: TMPFS is considered to be a highly experimental "
- "feature in FreeBSD.\n");
-
vn_lock(mp->mnt_vnodecovered, LK_SHARED | LK_RETRY);
error = VOP_GETATTR(mp->mnt_vnodecovered, &va, mp->mnt_cred);
VOP_UNLOCK(mp->mnt_vnodecovered, 0);
--
-- David (obr...@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"
___
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"
Thoughts on TMPFS no longer being considered "highly experimental"
Does anyone object to this patch?
David Wolfskill and I have run TMPFS on a number of machines for two
years with no problems.
I may have missed something, but I'm not aware of any serious PRs on
TMPFS either.
Index: tmpfs_vfsops.c
===
--- tmpfs_vfsops.c (revision 221113)
+++ tmpfs_vfsops.c (working copy)
@@ -155,9 +155,6 @@ tmpfs_mount(struct mount *mp)
return EOPNOTSUPP;
}
- printf("WARNING: TMPFS is considered to be a highly experimental "
- "feature in FreeBSD.\n");
-
vn_lock(mp->mnt_vnodecovered, LK_SHARED | LK_RETRY);
error = VOP_GETATTR(mp->mnt_vnodecovered, &va, mp->mnt_cred);
VOP_UNLOCK(mp->mnt_vnodecovered, 0);
--
-- David (obr...@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"
