lkml.org 
[lkml]   [1997]   [Nov]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Some thoughts on write back page cache cacheing
From
Date
ebiederm+eric@npwt.net (Eric W. Biederman) writes:

> I have been pondering the issues of caching in compressed filesystems,

Please send me a copy of any scribblings you put together (whether or
not they are of publication quality). Although I'm a little too
snowed under to be thinking much of caching issues in the next few
weeks (exams then see if I can put together something suitable for
inclusion in 2.2), caching is an issue for any compressed filesystem.
I'm looking at it from the point of view of ext2, btw.

> - Truncate inode pages needs a second look as well. What are the
> correct semantics when the following happens.;
> page_size = getpagesize
> ftruncate(fd, 4*page_size);
> maping = mmap(NULL, 4*page_size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
> ftruncate(fd, 1*page_size);
> write(fd, buf, 3*page_size); /* to the end of the file */
> Shold the last 3 pages of the mapping be equal or not (assume
> different data was written then was there in the first place).

From Single Unix Specification vers2
(<http://www.opengroup.org/public/pubs/catalog/x912.htm>):

: If the effect of truncation is to decrease the size of a file or
: shared memory object and whole pages beyond the new end were
: previously mapped, then the whole pages beyond the new end will be
: discarded. References to the discarded pages result in generation of a
: SIGBUS signal.

I'm not sure whether this means that the old mapping sees the
newly-written data or not, but it's clear to me that the old data is
lost.

I don't know what a "shared memory object" is, but this line may be
relevant:

: If fildes references a shared memory object, ftruncate() sets the
: size of the shared memory object to length.

HTH,

pjm.

\
 
 \ /
  Last update: 2005-03-22 13:40    [from the cache]
©2003-2011 Jasper Spaans