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 device and
>    tell it to use swap as backing store, then newfs up a UFS filesystem
>    on it.  You have the option to have it dynamically allocate and 
>    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?

>    due to the update daemon syncing all filesystems every so often.
>    But if you pre-reserve the swap it *will* be just as efficient as a
>    normal filesystem.  In fact, if you have multiple swap partitions
>    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.

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.)



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Reply via email to