Date: Sat, 4 Dec 1999 20:47:11 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: "Ronald F. Guilmette" <rfg@monkeys.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: tmpfs .. ? Message-ID: <199912050447.UAA58828@apollo.backplane.com> References: <18062.944351089@monkeys.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:> 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
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199912050447.UAA58828>