A bug about VMO's resize

[liqinggd]

This is a test case for truncate:

// Truncating a file down clears that portion of the file.
TEST_F(FixtureTruncateTest, FtruncateShrinkGrow) {
  std::vector<char> buf(10, 'a');
  EXPECT_THAT(WriteFd(test_file_fd_.get(), buf.data(), buf.size()),
              SyscallSucceedsWithValue(buf.size()));

  // Shrink then regrow the file. This should clear the second half of the file.
  EXPECT_THAT(ftruncate(test_file_fd_.get(), 5), SyscallSucceeds());
  EXPECT_THAT(ftruncate(test_file_fd_.get(), 10), SyscallSucceeds());

  EXPECT_THAT(lseek(test_file_fd_.get(), 0, SEEK_SET), SyscallSucceeds());

  std::vector<char> buf2(10);
  EXPECT_THAT(ReadFd(test_file_fd_.get(), buf2.data(), buf2.size()),
              SyscallSucceedsWithValue(buf2.size()));

  std::vector<char> expect = {'a',  'a',  'a',  'a',  'a',
                              '\0', '\0', '\0', '\0', '\0'};
  EXPECT_EQ(expect, buf2);
}

Our current implementation is unable to pass the test above. The reason is that files utilize Vmo for storage, but Vmo's resizing operates at PAGE_SIZE granularity. In practice, this means it's impossible to zero out content that is less than one page in size when shrinking. Consequently, this results in reading old data when the size is first reduced and then expanded.

[junyang-zh]

I took a view on the Vmo design. But I doubt if virtual memory management should provide guarentees on granularities smaller than the size of a base page. Could we implement that zeroing out behavior at the FileLike implementation level?

[liqinggd]

Maybe we can fix it in the PageCache's resize method.

[liqinggd]

This issue will be fixed in #958