Re: svn commit: r227310 - head/sys/fs/tmpfs
TMPFS is not usable without swap, it should have better algorithms to adjust it's size, depending on amount of memory/swap available. # swapoff -a # swapinfo Device 1K-blocks UsedAvail Capacity # top Mem: 253M Active, 282M Inact, 933M Wired, 3972K Cache, 135M Buf, 491M Free Swap: # df -h /tmp FilesystemSizeUsed Avail Capacity Mounted on tmpfs 436k436k 0B 100%/tmp no free space on /tmp # uname -a FreeBSD gpr.drweb.com 9.0-BETA2 FreeBSD 9.0-BETA2 #0 r225446M: Thu Sep 8 17:30:46 MSK 2011 g...@gpr.drweb.com:/usr/obj/usr/src/freebsd-head/sys/DRW_A amd64 On Mon, Nov 07, 2011 at 04:21:50PM +, Marcel Moolenaar wrote: Author: marcel Date: Mon Nov 7 16:21:50 2011 New Revision: 227310 URL: http://svn.freebsd.org/changeset/base/227310 Log: Don astbestos garment and remove the warning about TMPFS being experimental -- highly experimental even. So far the closest to a bug in TMPFS that people have gotten to relates to how ZFS can take away from the memory that TMPFS needs. One can argue that such is not a bug in TMPFS. Irrespective, even if there is a bug here and there in TMPFS, it's not in our own advantage to scare people away from using TMPFS. I for one have been using it, even with ZFS, very successfully. Modified: head/sys/fs/tmpfs/tmpfs_vfsops.c Modified: head/sys/fs/tmpfs/tmpfs_vfsops.c == --- head/sys/fs/tmpfs/tmpfs_vfsops.c Mon Nov 7 15:43:11 2011 (r227309) +++ head/sys/fs/tmpfs/tmpfs_vfsops.c Mon Nov 7 16:21:50 2011 (r227310) @@ -156,9 +156,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); ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r227310 - head/sys/fs/tmpfs
On (07/11/2011 12:01), Xin LI wrote: On Mon, Nov 7, 2011 at 8:21 AM, Marcel Moolenaar mar...@freebsd.org wrote: Author: marcel Date: Mon Nov 7 16:21:50 2011 New Revision: 227310 URL: http://svn.freebsd.org/changeset/base/227310 Log: Don astbestos garment and remove the warning about TMPFS being experimental -- highly experimental even. So far the closest to a bug in TMPFS that people have gotten to relates to how ZFS can take away from the memory that TMPFS needs. One can argue that such is not a bug in TMPFS. Irrespective, even if there is a bug here and there in TMPFS, it's not in our own advantage to scare people away from using TMPFS. I for one have been using it, even with ZFS, very successfully. Was the data corruption issue when mixing mmap/sendfile/read/writes fixed already? I haven't used tmpfs in such complicated environment in my use (which works well) but I remember some complains about it... Sendfile was fixed quite a while ago. Regarding ZFS+TMPFS, there is a patch floating around changing TMPFS assumptions on free memory. I'm thinking about making it optional, preserving old behaviour if file system size wasn't specified during mount. I'll commit the following fix shortly: https://github.com/glk/freebsd-head/commit/15186db A bug on removing parent directory while holding reference to current one was mentioned at DevSummit. I wasn't able to reproduce it on CURRENT. I might have fixed it already while correcting similar locking issue. And it would be nice to have patch by kib@ removing double caching in head. Cheers, -- Xin LI delp...@delphij.net https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r227310 - head/sys/fs/tmpfs
On Nov 8, 2011, at 2:26 AM, Gennady Proskurin wrote: TMPFS is not usable without swap, it should have better algorithms to adjust it's size, depending on amount of memory/swap available. # swapoff -a # swapinfo Device 1K-blocks UsedAvail Capacity # top Mem: 253M Active, 282M Inact, 933M Wired, 3972K Cache, 135M Buf, 491M Free Swap: # df -h /tmp FilesystemSizeUsed Avail Capacity Mounted on tmpfs 436k436k 0B 100%/tmp no free space on /tmp # uname -a FreeBSD gpr.drweb.com 9.0-BETA2 FreeBSD 9.0-BETA2 #0 r225446M: Thu Sep 8 17:30:46 MSK 2011 g...@gpr.drweb.com:/usr/obj/usr/src/freebsd-head/sys/DRW_A amd64 Thanks, for the report. Can you file a PR so that we can track this. Thanks! -- Marcel Moolenaar mar...@xcllnt.net ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r227310 - head/sys/fs/tmpfs
On 7 November 2011 17:21, Marcel Moolenaar mar...@freebsd.org wrote: Author: marcel Date: Mon Nov 7 16:21:50 2011 New Revision: 227310 URL: http://svn.freebsd.org/changeset/base/227310 Log: Don astbestos garment and remove the warning about TMPFS being experimental -- highly experimental even. So far the closest to a bug in TMPFS that people have gotten to relates to how ZFS can take away from the memory that TMPFS needs. One can argue that such is not a bug in TMPFS. Irrespective, even if there is a bug here and there in TMPFS, it's not in our own advantage to scare people away from using TMPFS. I for one have been using it, even with ZFS, very successfully. Thanks! It should be ok by now. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r227310 - head/sys/fs/tmpfs
On Mon, Nov 7, 2011 at 8:21 AM, Marcel Moolenaar mar...@freebsd.org wrote: Author: marcel Date: Mon Nov 7 16:21:50 2011 New Revision: 227310 URL: http://svn.freebsd.org/changeset/base/227310 Log: Don astbestos garment and remove the warning about TMPFS being experimental -- highly experimental even. So far the closest to a bug in TMPFS that people have gotten to relates to how ZFS can take away from the memory that TMPFS needs. One can argue that such is not a bug in TMPFS. Irrespective, even if there is a bug here and there in TMPFS, it's not in our own advantage to scare people away from using TMPFS. I for one have been using it, even with ZFS, very successfully. Was the data corruption issue when mixing mmap/sendfile/read/writes fixed already? I haven't used tmpfs in such complicated environment in my use (which works well) but I remember some complains about it... Cheers, -- Xin LI delp...@delphij.net https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
