On Fri, 3 Jul 2009 16:07:56 +0200 (CEST) Wojciech Puchar wrote:
WP> repeatable
WP> put something on tmpfs filesystem, then download it to other machine
WP> using ftp (server is ftpd on first machine). no errors, download is
WP> fine, but you get rubbish - simply data from wro
works even over localhost
[woj...@wojtek /tmp]$ cp /bin/sh .
[woj...@wojtek /tmp]$ ftp localhost
Trying ::1...
Connected to localhost.
220 wojtek.tensor.gdynia.pl FTP server (Version 6.00LS) ready.
Name (localhost:wojtek):
331 Password required for wojtek.
Password:
230 User wojtek logged in.
Rem
repeatable
put something on tmpfs filesystem, then download it to other machine using
ftp (server is ftpd on first machine). no errors, download is fine, but
you get rubbish - simply data from wrong places in memory.
using rcp works. most probably ftpd uses sendfile, while rcp does not
can be identified by fsx which I didn't got a chance to
WP> > investigate further. I think tmpfs is Ok for some usual work but maybe
WP> > not ready for production at that moment. alc@ and kib@ has made a lot
WP> > of changes on it recently so perhaps we need to re-visit the
Ivan Voras wrote:
> Ben Kelly wrote:
>> I get some slightly unexpected behavior when mount is run
>> multiple times:
>>
>> ianto# mount | grep ' /tmp'
>> tmpfs on /tmp (tmpfs, local)
>> ianto# mount /tmp
>> ianto# mount | grep '
multiple times:
ianto# mount | grep ' /tmp'
tmpfs on /tmp (tmpfs, local)
ianto# mount /tmp
ianto# mount | grep ' /tmp'
tmpfs on /tmp (tmpfs, local)
tmpfs on /tmp (tmpfs, local)
ianto# umount /tmp
ianto# mount | grep ' /tmp'
tmpfs on /tmp (tmpfs, local)
ian
In other words, is there still reason for the "highly experimental
feature" warning?
Last time when I added the warning, it was because some data corruption
issue that can be identified by fsx which I didn't got a chance to
investigate further. I think tmpfs is Ok for some usual
Ivan Voras wrote:
> Hi,
>
> Are there still known problems with tmpfs?
>
> I've been using it for a while in 7-STABLE and 8-CURRENT without
> noticeable problems - not that there was ever serious load involved
> (normal /tmp activity). I've just tried it and it s
On 2009-06-15, Ivan Voras wrote:
> Are there still known problems with tmpfs?
I think sendfile(2) is still broken on tmpfs. See:
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/127213
--
Jaakko
___
freebsd-hackers@freebsd.org mailing list
h
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ivan Voras wrote:
> Hi,
>
> Are there still known problems with tmpfs?
>
> I've been using it for a while in 7-STABLE and 8-CURRENT without
> noticeable problems - not that there was ever serious load involved
> (normal
On Thursday 09 April 2009 08:34:22 Travis Daygale wrote:
> David, thank you for the great information! Yes, I would appreciate seeing
> the scripts and hearing about the other method you outline. Yes, you
> understand what I want to achieve exactly.
Please see attached for the scripts. There i
: compiling root filesystem into kernel (preferably tmpfs root
filesystem)
To: anti_spam...@yahoo.com
Cc: freebsd-hackers@freebsd.org
Date: Thursday, April 9, 2009, 12:55 PM
Travis Daygale wrote:
> I have built a root image that I put in the kernel as described in
> the Nov 2006 post. ?My UFS root
Travis Daygale wrote:
> I have built a root image that I put in the kernel as described in
> the Nov 2006 post. ?My UFS root image consists of /sbin/init,
> where init is a statically compiled C program that just spits out
> "Hello world" and sleeps, this binary runs fine under FBSD. ?At
> this po
r
--- On Sun, 4/5/09, David Naylor wrote:
From: David Naylor
Subject: Re: compiling root filesystem into kernel (preferably tmpfs root
filesystem)
To: "Travis Daygale"
Cc: freebsd-hackers@freebsd.org
Date: Sunday, April 5, 2009, 1:14 PM
On Saturday 04 April 2009 21:52:14 Travis D
e statically compiled-in root file system.
Yes, you can compile a fs image into the kernel. This however will be static
and if you want editing then will need to use unionfs with mdmfs. tmpfs
cannot be used for this as it does not yet (to my knowledge) support unionfs.
> My question i
h consists of a single giant
kernel image and when boot, runs entirely in memory, the kernel in fact can't
read filesystems other than tmpfs because no filesystems are compiled in. It
appears all of this won't be possible in FreeBSD (looks like ufs is required)
but it appears I can get c
[EMAIL PROTECTED] wrote:
hi , freebsd-hackers.
I found this reference
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=372365+0+/usr/local/www/db/text/2006/freebsd-hackers/20060226.freebsd-hackers
how is it correct to conduct this procedure ?
beforehand thank you !!
tmpfs is included in
hi , freebsd-hackers.
I found this reference
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=372365+0+/usr/local/www/db/text/2006/freebsd-hackers/20060226.freebsd-hackers
how is it correct to conduct this procedure ?
beforehand thank you !!
--
With kind regards ,
dn
Hi,
I have ported TMPFS from NetBSD. The first beta can be found at
http://download.purpe.com/files/tmpfs-BETA_01.tgz
Kindly refer to the README file for usage details and the
NOTES file for issues, bugs and todo-s.
The NetBSD man pages can located at
http://netbsd.gw.com/cgi
Peter Jeremy <[EMAIL PROTECTED]> writes:
> On Sat, 2006-Jan-21 14:30:57 -0600, Matthew D. Fuller wrote:
> > Yes, but portupgrade and friends already do most of that, so they can
> > upgrade stuff "in order".
> Actually, they rely on there being an up-to-date INDEX file and build
> their own depende
On Sun, Jan 22, 2006 at 08:09:56AM +1100 I heard the voice of
Peter Jeremy, and lo! it spake thus:
>
> Given that a port's dependency tree can depend on the options it is
> invoked with, it would be nicer if the dependency tree was generated
> dynamically, rather than pulled out of the latest INDE
On Sat, 2006-Jan-21 14:30:57 -0600, Matthew D. Fuller wrote:
>On Sat, Jan 21, 2006 at 03:23:21PM -0500 I heard the voice of
>Kris Kennaway, and lo! it spake thus:
>> On Sat, Jan 21, 2006 at 10:07:39AM -0600, Matthew D. Fuller wrote:
>> >
>> > This is something that may be easier to:
>> >
>> > 3)
On Sat, Jan 21, 2006 at 03:23:21PM -0500 I heard the voice of
Kris Kennaway, and lo! it spake thus:
> On Sat, Jan 21, 2006 at 10:07:39AM -0600, Matthew D. Fuller wrote:
> >
> > This is something that may be easier to:
> >
> > 3) Implement in portupgrade or portmanager or some such higher-level
>
On Sat, Jan 21, 2006 at 10:07:39AM -0600, Matthew D. Fuller wrote:
> [ Cc trim a bit ]
>
> On Fri, Jan 20, 2006 at 08:53:11PM -0500 I heard the voice of
> Kris Kennaway, and lo! it spake thus:
> >
> > In order to do better you either have to:
>
> This is something that may be easier to:
>
> 3)
[ Cc trim a bit ]
On Fri, Jan 20, 2006 at 08:53:11PM -0500 I heard the voice of
Kris Kennaway, and lo! it spake thus:
>
> In order to do better you either have to:
This is something that may be easier to:
3) Implement in portupgrade or portmanager or some such higher-level
tool in a language
On Fri, Jan 20, 2006 at 08:36:17PM -0500, Sergey Babkin wrote:
> > If (as I said) you impose the correct dependency information.
> > Currently there is no such information provided.
>
> Ah, so we don't have any reliable information about dependencies
> between the ports either (not just between
Kris Kennaway wrote:
>
> On Fri, Jan 20, 2006 at 04:54:33PM -0500, Sergey Babkin wrote:
> > Kris Kennaway wrote:
> > >
> > > On Fri, Jan 20, 2006 at 11:25:33AM -0600, Sergey Babkin wrote:
> > > > >From: =?ISO646-US?Q?Dag-Erling_Sm=3Frgrav?= <[EMAIL PROTECTED]>
> > > >
> > > > >Gary Thorpe <[EMAIL
On Fri, 2006-Jan-20 16:54:33 -0500, Sergey Babkin wrote:
>Kris Kennaway wrote:
>> It's harder than that, because you need to impose dependency
>> information and mutual exclusion between different makes. e.g. they
>> can't both be compiling the same port at the same time, which will
>> happen if y
y; Mike Meyer; freebsd-hackers@freebsd.org; Dag-Erling Sm?rgrav
> > Subject: Re: speed up port compiling using RAM (tmpfs) ???
> >
> >
> > On Fri, Jan 20, 2006 at 11:49:29AM -0500, Gary Thorpe wrote:
> >
> > > >-j is not safe to use with port build
ompiling using RAM (tmpfs) ???
>
>
> On Fri, Jan 20, 2006 at 11:49:29AM -0500, Gary Thorpe wrote:
>
> > >-j is not safe to use with port builds since many ported software
> > >contain race conditions in the build.
> > >
> > >Kris
> >
>
On Fri, Jan 20, 2006 at 04:54:33PM -0500, Sergey Babkin wrote:
> Kris Kennaway wrote:
> >
> > On Fri, Jan 20, 2006 at 11:25:33AM -0600, Sergey Babkin wrote:
> > > >From: =?ISO646-US?Q?Dag-Erling_Sm=3Frgrav?= <[EMAIL PROTECTED]>
> > >
> > > >Gary Thorpe <[EMAIL PROTECTED]> writes:
> > > >> This eff
Kris Kennaway wrote:
>
> On Fri, Jan 20, 2006 at 11:25:33AM -0600, Sergey Babkin wrote:
> > >From: =?ISO646-US?Q?Dag-Erling_Sm=3Frgrav?= <[EMAIL PROTECTED]>
> >
> > >Gary Thorpe <[EMAIL PROTECTED]> writes:
> > >> This effectively means that you cannot take advantage of SMP to
> > >> compile FreeBS
On Sat, Jan 21, 2006 at 07:52:20AM +1100, Peter Jeremy wrote:5C
> IMHO, the biggest problem (as des pointed out) is that there's nothing
> to prevent two makes attempting to build the same port (this can
> easily happen when both ports A and B depend on port C). One possible
> solution would be t
On Fri, 2006-Jan-20 14:47:00 -0500, Kris Kennaway wrote:
>On Fri, Jan 20, 2006 at 11:49:29AM -0500, Gary Thorpe wrote:
>
>> >-j is not safe to use with port builds since many ported software
>> >contain race conditions in the build.
>> >
>> >Kris
>>
>> This effectively means that you cannot take a
On Fri, Jan 20, 2006 at 11:49:29AM -0500, Gary Thorpe wrote:
> >-j is not safe to use with port builds since many ported software
> >contain race conditions in the build.
> >
> >Kris
>
> This effectively means that you cannot take advantage of SMP to compile
> FreeBSD's ports collection. That so
On Fri, Jan 20, 2006 at 11:25:33AM -0600, Sergey Babkin wrote:
> >From: =?ISO646-US?Q?Dag-Erling_Sm=3Frgrav?= <[EMAIL PROTECTED]>
>
> >Gary Thorpe <[EMAIL PROTECTED]> writes:
> >> This effectively means that you cannot take advantage of SMP to
> >> compile FreeBSD's ports collection. That sounds l
>From: =?ISO646-US?Q?Dag-Erling_Sm=3Frgrav?= <[EMAIL PROTECTED]>
>Gary Thorpe <[EMAIL PROTECTED]> writes:
>> This effectively means that you cannot take advantage of SMP to
>> compile FreeBSD's ports collection. That sounds like a big
>> limitation...especially for people trying to speed up bulk b
Gary Thorpe <[EMAIL PROTECTED]> writes:
> This effectively means that you cannot take advantage of SMP to
> compile FreeBSD's ports collection. That sounds like a big
> limitation...especially for people trying to speed up bulk builds.
We cannot be held responsible for race conditions in the Makef
Kris Kennaway wrote:
On Thu, Jan 19, 2006 at 05:32:58PM -0500, Gary Thorpe wrote:
Ashok Shrestha wrote:
I mounted part of RAM as such:
mdmfs -s 500m md /mnt
Then put WRKDIRPREFIX=/path/to/md in /etc/make.conf.
It substantially reduces compile time by about 5-10 times.
Thanx to all ur re
Wesley Shields <[EMAIL PROTECTED]> writes:
> I think he is trying to get at a scenario where WRKDIR is on a seperate
> disk from the one /usr/ports is on.
There is no performance advantage in doing that. I can only see two
possible reasons for pointing WRKDIRPREFIX to another disk:
- insufficie
On Thu, Jan 19, 2006 at 05:32:58PM -0500, Gary Thorpe wrote:
> Ashok Shrestha wrote:
> >I mounted part of RAM as such:
> >
> >mdmfs -s 500m md /mnt
> >
> >Then put WRKDIRPREFIX=/path/to/md in /etc/make.conf.
> >
> >It substantially reduces compile time by about 5-10 times.
> >
> >
> >Thanx to all u
Ashok Shrestha wrote:
I mounted part of RAM as such:
mdmfs -s 500m md /mnt
Then put WRKDIRPREFIX=/path/to/md in /etc/make.conf.
It substantially reduces compile time by about 5-10 times.
Thanx to all ur replies.
-Ashok Shrestha
An alternative is to try using the "-pipe" flag with GCC: thi
I mounted part of RAM as such:
mdmfs -s 500m md /mnt
Then put WRKDIRPREFIX=/path/to/md in /etc/make.conf.
It substantially reduces compile time by about 5-10 times.
Thanx to all ur replies.
-Ashok Shrestha
On 1/19/06, Wesley Shields <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 19, 2006 at 05:54:
On Thu, Jan 19, 2006 at 05:54:02PM +0100, Dag-Erling Sm?rgrav wrote:
> Mike Meyer <[EMAIL PROTECTED]> writes:
> > Will using a swap-backed disk change anything?
>
> Not really.
>
> > How about the best way to configure things to use two disks for the
> > compile?
>
> I'm not sure what you are tr
Mike Meyer <[EMAIL PROTECTED]> writes:
> Will using a swap-backed disk change anything?
Not really.
> How about the best way to configure things to use two disks for the
> compile?
I'm not sure what you are trying to achieve. Unlike the base system,
the ports tree does not use separate source a
Ashok Shrestha <[EMAIL PROTECTED]> writes:
> I am curious to know if there is a way to compile a port such as X11
> or KDE faster.
>
> I know in Gentoo, you can mount a part of RAM and compile in that.
> This substantially decreases the compile time. Reference:
> http://gentoo-wiki.com/TIP_Speedin
On Sunday 15 January 2006 18:15, Ashok Shrestha wrote:
> I am curious to know if there is a way to compile a port such as X11
> or KDE faster.
>
> I know in Gentoo, you can mount a part of RAM and compile in that.
> This substantially decreases the compile time. Reference:
> http://gentoo-wiki.com
you can mount a small memory filesystem think it's called mbfs or
something and change the work dir to that then you should be able to
compile KDE using ram instead of the HD
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Ashok Shrestha wrote:
>> Hi,
>>
>> I am curious to know if there is a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ashok Shrestha wrote:
> Hi,
>
> I am curious to know if there is a way to compile a port such as X11
> or KDE faster.
>
> I know in Gentoo, you can mount a part of RAM and compile in that.
> This substantially decreases the compile time. Reference:
日曜日 15 1月 2006 16:45、Ashok Shrestha さんは書きました:
> Hi,
>
> I am curious to know if there is a way to compile a port such as X11
> or KDE faster.
>
> I know in Gentoo, you can mount a part of RAM and compile in that.
> This substantially decreases the compile time. Reference:
> http://gentoo-wiki.com/
On Sun, Jan 15, 2006 at 02:45:30AM -0500, Ashok Shrestha wrote:
> Hi,
>
> I am curious to know if there is a way to compile a port such as X11
> or KDE faster.
>
> I know in Gentoo, you can mount a part of RAM and compile in that.
> This substantially decreases the compile time. Reference:
> htt
Hi,
I am curious to know if there is a way to compile a port such as X11
or KDE faster.
I know in Gentoo, you can mount a part of RAM and compile in that.
This substantially decreases the compile time. Reference:
http://gentoo-wiki.com/TIP_Speeding_up_portage_with_tmpfs
Does anyone know how to
On 1999-Dec-07 07:23:49 +1100, David Wolfskill wrote:
>>Date: Mon, 6 Dec 1999 10:13:50 -0800 (PST)
>>From: Matthew Dillon <[EMAIL PROTECTED]>
>
>>The actual problem is sendmail's constant *rescanning* of the directory.
Which I forgot about :-(.
>To the extent that the directory is populated,
:>Date: Mon, 6 Dec 1999 10:13:50 -0800 (PST)
:>From: Matthew Dillon <[EMAIL PROTECTED]>
:
:>The actual problem is sendmail's constant *rescanning* of the directory.
:
:To the extent that the directory is populated, yes. (Scanning an empty
:directory isn't an overwhelmingly resource-intensive
> :The main problem is that sendmail
> places all queue files (and there :are several for each
> undelivered message) in one directory
Sendmail 8.10 addresses this by allowing for multiple queue directories.
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe
>Date: Mon, 6 Dec 1999 10:13:50 -0800 (PST)
>From: Matthew Dillon <[EMAIL PROTECTED]>
>The actual problem is sendmail's constant *rescanning* of the directory.
To the extent that the directory is populated, yes. (Scanning an empty
directory isn't an overwhelmingly resource-intensive operati
:On Sat, 04 Dec 1999 15:44:49 -0800, "Ronald F. Guilmette" <[EMAIL PROTECTED]> wrote:
:>Specifically, I'm planning a large mail server... which will use Sendmail...
:>and I'd really like to allocate the Sendmail queue files... which typically
:>have a rather short lifespan... on/in some sort of fi
:In message <[EMAIL PROTECTED]>,
:Matthew Dillon <[EMAIL PROTECTED]> wrote:
:
:>Mail queue files are persistant enough (upwards of 5 days if a destination
:>is down) that you run a real risk of losing something important if
:>you crash and wipe. I would not use MFS at all and I wo
Sorry I missed this question. Check www.acl.lanl.gov/~rminnich for v9fs
and see if you can use it.
ron
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
On Sat, 04 Dec 1999 15:44:49 -0800, "Ronald F. Guilmette" <[EMAIL PROTECTED]> wrote:
>Specifically, I'm planning a large mail server... which will use Sendmail...
>and I'd really like to allocate the Sendmail queue files... which typically
>have a rather short lifespan... on/in some sort of filesy
On Sun, 5 Dec 1999, Ronald F. Guilmette wrote:
>
> In message <[EMAIL PROTECTED]>, you
> P.S. The other reference you gave:
>
> >http://www.ece.cmu.edu/~ganger/CSE-TR-254-95/
>
> seem to no longer be useful/functional.
That is because it should be ~ganger/CSE-TR-254-95/
>
>
To Unsubsc
In message <[EMAIL PROTECTED]>, you
wrote:
>See src/sys/ufs/ffs/README.softupdates, which tells you what you need to get
>them to work
Thank you. I'll definitely be looking at that.
P.S. The other reference you gave:
>http://www.ece.cmu.edu/~ganger/CSE-TR-254-95/
seem to no longer be usef
In the last episode (Dec 05), Ronald F. Guilmette said:
> Matthew Dillon <[EMAIL PROTECTED]> wrote:
> > Mail queue files are persistant enough (upwards of 5 days if a
> > destination is down) that you run a real risk of losing something
> > important if you crash and wipe. I would not use MFS at
On Sun, 5 Dec 1999, Ronald F. Guilmette wrote:
> > Normal
> > filesystems with softupdates turned on make pretty good mail spools though
>
> OK, I've seen several mentions now of `softupdates', and I think that I
> have a general (vague?) notion of what `softupdates' is all about, but
> allow
In message <[EMAIL PROTECTED]>,
Matthew Dillon <[EMAIL PROTECTED]> wrote:
>Mail queue files are persistant enough (upwards of 5 days if a destination
>is down) that you run a real risk of losing something important if
>you crash and wipe. I would not use MFS at all and I would on
:* one that is able to recover all swap space used to back processes
: and such, rather then just some of it. We can get close now,
processes? I meant files. Just SMP and filesystem code mixing in my
brain!
-Matt
To Unsubscribe: sen
:>deallocate swap, or you can force it to pre-reserve swap. See the
:>'vnconfig' man page and the -S option and the '-s reserve' option.
:>
:>This is for -CURRENT only.
:>
:>Generally speaking this isn't going to be as efficient as a re
In message <[EMAIL PROTECTED]>,
Matthew Dillon <[EMAIL PROTECTED]> wrote:
>
>:Has anyone toyed with the idea of implementing a swap-based filesystem
>:similar to Sun's tmpfs?
>:
>:Chuck Youse
>
>I did it a couple of months ago. You simply use the VN
:Has anyone toyed with the idea of implementing a swap-based filesystem
:similar to Sun's tmpfs?
:
:Chuck Youse
I did it a couple of months ago. You simply use the VN device and
tell it to use swap as backing store, then newfs up a UFS filesystem
on it. You have the option to
tmpfs may or may not be a UFS image stored in swap. I have a strong
suspicion that it's not.
MFS *is* a UFS image in memory (backed by swap, of course). As such, it
is not nearly as efficient as it could be for /tmp purposes.
Chuck
On Thu, 2 Dec 1999, Mike Smith wrote:
> >
>
>
> Has anyone toyed with the idea of implementing a swap-based filesystem
> similar to Sun's tmpfs?
Like, oh, MFS maybe?
Try 'man -k mfs'.
--
\\ Give a man a fish, and you feed him for a day. \\ Mike Smith
\\ Tell him he should learn how to fish himself, \\ [EMAIL
Has anyone toyed with the idea of implementing a swap-based filesystem
similar to Sun's tmpfs?
Chuck Youse
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
72 matches
Mail list logo
