From owner-freebsd-hackers Sat Dec 4 20:47:19 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 5B4A514C4C for ; Sat, 4 Dec 1999 20:47:14 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id UAA58828; Sat, 4 Dec 1999 20:47:11 -0800 (PST) (envelope-from dillon) Date: Sat, 4 Dec 1999 20:47:11 -0800 (PST) From: Matthew Dillon Message-Id: <199912050447.UAA58828@apollo.backplane.com> To: "Ronald F. Guilmette" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: tmpfs .. ? References: <18062.944351089@monkeys.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> 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 real tmpfs : :Please excuse my ignorance, but what is it, exactly, that you are defining :as a ``real tmpfs'' here? I would define a real tmpfs as: * one that keeps all the inodes and directory structure in memory (not swap backed) * 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, but eventually using UFS on top of a swap filesystem will lead to swap being allocated for virtually the entire bitmap and inode space, and partially allocated for file fragments. This would be true even with swap pre-reserved, because the system will still attempt to read a partially used disk block prior to writing it. If no swap is assigned to that block then the read is essentially a nop (well, zero-fill). * one that does not unnecessarily sync files to backing store. MFS actually doesn't, but MFS has the double-caching problem which makes it unsuitable to hold large amounts of data without stressing the system. Currently :> your tmpfs will wind up being interleaved and will have even better :> performance. pre-reservation also gives you the ability to recover :> the filesystem after a crash though for obvious reasons it can be :> problematic to depend on this ability. : :Again, please excuse my ignorance, but what ``obvious reasons'' are those? : :P.S. I have a definite interest in this sort of thing, especially if the :data stored was made to be persistant across reboots and/or crashes. If you pre-reserve swap then the physical disk locations of the swap you have reserved depends on the order in which you reserve it. So, for example, if your system needs to use some swap before the boot process gets to the point where you create the swap-backed filesystems then it will not reliably reserve the same area of swap when you create those filesystems and they will not survive the reboot. :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 filesystem (e.g. an :mfs or else this VN thing you are talking about) that would tend to give :petter performance than just using an ordinary disk-based filesystem. But :of course, in this sort of an application, it would be Really Nice if the :filesystem in question would persist across most rebbots and crashes. : :(I asked about MFS persistance awhile back on -questions, but I don't :think that anybody groked _why_ I might want that. Now perhaps I have :made my intentions more clear.) You can also use a file as backing store for VN. You can use a file to back an MFS filesystem but you will *NOT* get persistance unless you manage to unmount the filesystem prior to rebooting. 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 only use VN with persistant store, but the performance is going to be similar to using a normal filesystem so it may not be worth doing. Normal filesystems with softupdates turned on make pretty good mail spools though, of course, we still have the problem of large queue directories with sendmail. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message