Add GetTemperature on existing files

[pdillinger]

Summary: For tiered storage

Test Plan: Just API placeholders for now

[siying]

It feels like a good function call for validation purpose regardless whether we build tiered storage migration using it.

[facebook-github-bot]

@pdillinger has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

[pdillinger]

I'm thinking about revising or extending this. We probably want to be able to find out the tier without opening the file, or at least have that option. We have some options:

• Add FileSystem::GetTemperature(const std::string& path, ...)
• Add temperature to FileAttributes, though many FileSystems rely on the default implementation so we would likely want FileSystem::GetTemperature as well. This API might allow some implementations to speed up fetching the info for many files in the same directory, or it might upset/confuse existing implementations populating FileAttributes.

And if we have these, do we need the versions that tell you about an open file?

• Especially on systems where a file descriptor can refer to an old file no longer associated with the name, the versions on an open file ensure the temperature reflects the tier info of the open file. This is not typically something we worry about but is a hypothetical concern that could arise.
• The versions on an open file are likely more efficient if opening the file anyway, because it can avoid a second seek to the file by name.

[mrambacher]

I'm thinking about revising or extending this. We probably want to be able to find out the tier without opening the file, or at least have that option. We have some options:

• Add FileSystem::GetTemperature(const std::string& path, ...)
• Add temperature to FileAttributes, though many FileSystems rely on the default implementation so we would likely want FileSystem::GetTemperature as well. This API might allow some implementations to speed up fetching the info for many files in the same directory, or it might upset/confuse existing implementations populating FileAttributes.

And if we have these, do we need the versions that tell you about an open file?

• Especially on systems where a file descriptor can refer to an old file no longer associated with the name, the versions on an open file ensure the temperature reflects the tier info of the open file. This is not typically something we worry about but is a hypothetical concern that could arise.
• The versions on an open file are likely more efficient if opening the file anyway, because it can avoid a second seek to the file by name.

I was going to suggest adding a FileSystem::GetFileAttributes() method that returns the attributes of a file (size, modification time, temperature). Currently, you can only get the attributes of all files in a directory. I think this makes more sense than being able to get the Temperature from the various FSxxFile classes.

[pdillinger]

I'm not ruling out adding more ways to access the info in the future, but I think these functions are useful because they should suffice for our near-term needs and likely be simplest to implement within the FileSystem. And longer term (as mentioned above) GetTemperature() on an open file is likely more efficient if opening the file anyway, because it can avoid a second seek to the file by name, or potentially a directory listing.