Subject: Re: cp(1) vs. UVM/UBC
To: Ignatios Souvatzis <email@example.com>
From: Chuck Silvers <firstname.lastname@example.org>
Date: 07/22/2001 16:59:05
On Thu, Jul 19, 2001 at 10:52:29AM +0200, Ignatios Souvatzis wrote:
> On Thu, Jul 19, 2001 at 10:44:03AM +0200, Matthias Scheler wrote:
> > On Thu, Jul 19, 2001 at 10:40:53AM +0200, Ignatios Souvatzis wrote:
> > > There are other file systems with potential problems, if I recall right...
> > > e.g., the DOS\0 and DOS\1 variants of adosfs, which always have some
> > > metadata in their datablocks,
> > It's DOS\0, DOS\2 and DOS\4 which have metadata in the data blocks.
> > > ... so for this case, data copying always happens. (Chuck?)
> > Does mmap() do that transperantly?
> I don't remember ... that's why I wronte ``(Chuck?)'' above ('twas his code
> that fixed DOS\0, only my alpha-testing). I might be able to just try one of
> the next evenings. (Did I mention that I hate moving?)
I didn't do anything for mmap() of the inline-metadata versions.
two choices are to implement bounce-buffering in adosfs_getpages/putpages,
or disable mmap() for these files. I started putting in support
for doing the latter via VOP_MMAP(), but I got distracted by usenix
and vacation and some other stuff. I'll try to get that done soon.
mmap() just doesn't make sense for some files (such as most procfs and
kernfs files), so those filesystems will just fail VOP_MMAP() always.
other filesystems like adosfs can do it selectively. or if someone
really feels like writing some bounce-buffering code, that would be
> > > Maybe we need to disable mmap()ing for such filesystems inside the kernel,
> > > and make cp do the right thing if mmap fails? Is this possible?
> > Sounds reasonable for "cp". But what about other applications?
> Well, mmap() can always fail due to resource shortage, right? So an
> application has to deal with it or fail in this case...
this area isn't very well defined really, but having mmap() fail is
probably the most reasonable thing we can do. I already fixed /usr/bin/install
to do the fall-back-to-read() thing, there may be other programs in
our tree that will need the same change. third-party apps are another
story, but eventually we should support mmap() for all real filesystems
so hopefully this won't be much of a problem in the long run.