Date: Sat, 7 Jun 1997 14:57:03 +0200 From: lada@ws6303.gud.siemens.at (Hr.Ladavac) To: freebsd-hackers@FreeBSD.ORG, fritchie@MR.Net Subject: Re: One reason to mmap() block devices Message-ID: <199706071257.OAA21625@ws6423.gud.siemens.at>
next in thread | raw e-mail | index | archive | help
> From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 7 00:05:57 MET 1997
> To: freebsd-hackers@FreeBSD.ORG
> Subject: One reason to mmap() block devices
> Date: Fri, 06 Jun 1997 16:57:30 -0500
> From: Scott Lystig Fritchie <fritchie@MR.Net>
> X-Loop: FreeBSD.org
>
> To follow-up to my earlier question about why only regular and
> character files are mmap()able...
>
> ... I'm interested in mmap()ing a disk block device. I've been doing
> some alternative INN development, bypassing the traditional filesystem
> for article storage, using instead a few very large files as cyclic
> buffers.
>
> Currently under FreeBSD, these 2GB files are on top of a UFS
> filesystem. Under Solaris I use the disk partitions' block devices
> directly to bypass the filesystem overhead. I hadn't tried, until
> very recently, to use block devices under FreeBSD, and that's when I
> made my surprise discovery.
Because on SVR4 the character device has sync write semantics: it does
not get cached. The block device does, and uses write behind. At least,
that is the behavior on SINIX, and you don't get much more vanilla SVR4
than that[1]. This is the reason why char devices are used for databases:
they employ internal caching and want to be sure that the write operation
was really successful (i.e. that it reeely realy hit the media.)
I'm not sure about FreeBSD behavior in the same situation, but I would
assume similar semantics regarding char devices and write(2).
Now, mmap(2) is an entirely different beast as far as the semantics are
concerned, and the file image needs to be consistent only after a successful
msync(2) call, which means that the OS may delay the writes up to that point.
It would seem that you either msync() too much, or that the SunOS 5 does that
for you (naughty). Unless, of course, SunOS 5 delays writes even after
msync() if you have mmap()ped a block device (extremely naughty).
Alas, I cannot verify the FreeBSD behavior as my box have been snatched away
:( from me.
>
> I'm quite interested, actually, in having the OS interfere with its
> buffer cache. Under Solaris, INN article acceptance rates using disk
> character devices is only handful per second, and the drive sounds
> like automatic rifle fire. With disk block devices, throughput can
> reach over 200 articles/second, and the drive busy light blinks every
> now and then.
This is consistent with my previous observations. Knowing SVR4 behavior
regarding block devices, I would assume that it delays the writes even after
msync().
Since you are modifying INN anyway, you could try to avoid mixing read() and
mmap() accesses to the same file (which happen to work okay on SVR4 even
without msync() due to the VM/buffer-cache parallelism of theirs) and use
mmap() or read()/write() only. If you do that, msync() becomes redundant
unless you want to be sure that the image has been committed to the media,
in which case you would be well advised to use char devices[2]
/Marino
[1] Don't get me wrong: there is nothing bad in vanilla SVR4 per se, and
the RM Series hardware *can* take a serious beating without acting up.
[2] Please take this with a more than a grain of salt: I don't have the
kernel source in front of me, and my SINIX internals course was not
taken recently.
>
> I do have a non-critical machine I could test out a simple mod to
> allow VREG, VCHR, or VBLK type files ... but I figured I'd ask, just
> in case there might be something which I wouldn't notice if the
> machine weren't heavily stressed, for example while doing my testing.
> :-)
>
> -Scott
> ---
> Scott Lystig Fritchie, Network Engineer MRNet Internet Services, Inc.
> fritchie@mr.net, PGP key #152B8725 Minnesota Regional Network
> v: 612/362.5820, p: 612/637.9547 2829 University Ave SE
> http://www.mr.net/~fritchie/ Minneapolis, MN 55414
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199706071257.OAA21625>