Messages in this thread |  | | | Subject | Re: Some thoughts on write back page cache cacheing | | From | Peter Moulder <> | | Date | 04 Nov 1997 15:18:08 +1100 |
| |
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.
|  |