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