On Wed, 26 Jul 2000, Stephen C. Tweedie wrote:
> Hi,
>
> On Wed, Jul 26, 2000 at 02:41:44PM -0400, Alexander Viro wrote:
>
> > > For tail writes, I'd imagine we would just end up using the page cache
> > > as a virtual cache as NFS uses it, and doing plain copy into the
> > > buffer cache pages.
> >
> > Ouch. I _really_ don't like it - we end up with special behaviour on one
> > page in the pagecache.
>
> Correct. But it's all inside the filesystem, so there is zero VFS
> impact. And we're talking about non-block-aligned data for tails, so
> we simply don't have a choice in this case.
<shrug> Sure, it's not a VFS problem (albeit it _will_ require accurate
playing with unmap_....() in buffer.c), but ext2 problems are pretty
interesting too...
> > And getting data migration from buffer cache to
> > page cache, which is Not Nice(tm).
>
> Not preferred for bulk data, perhaps, but the VFS should cope just
> fine.
>
> > Yuck... Besides, when do we decide that
> > tail is going to be, erm, merged? What will happen with the page then?
>
> To the page? Nothing. To the buffer? It gets updated with the new
> contents of disk. Page == virtual contents. Buffer == physical
> contents. Plain and simple.
Erm? Consider that: huge lseek() + write past the end of file. Woops - got
to unmerge the tail (it's an internal block now) and we've got no
knowledge of IO going on the page. Again, IO may be asynchronous - no
protection from i_sem for us. After that page becomes a regular one,
right? Looks like a change of state to me...
