flatfile rename issue

[chuckcranor]

for the flat file FS: if we have an open file and we rename it, the flatfile code may copy the backing file from one backing filesystem to another (e.g. see FlatFileSystem::rename() calls Util::CopyFile). if the file is open we have a cached IOSHandle *backend_fh in the Flat_fd ... and if Flat_fd::renamefd() is called (see FlatFileFD.h), it will update the path/backend metadata in the Flat_fd, but not the open backend_fh IOSHandle (which will point to the old backend filesystem, pre Util::CopyFile). Future I/O will go to that stale backend_fh, rather than a new fh open on the new backend location.

This only impacts FUSE (since it is the main user of renamefd()).

A possible solution is to have Flat_fd::renamefd() close the old backend_fh and reopen the backing file at the new location (making sure you open in the correct mode and get the error handling right).

[chuckcranor]

There is a check for this that can produce mlogs like:

MLOG ERR FlatFile: openfile rename across devs

that David S. saw from the regression test.

[johnbent]

On Dec 1, 2014, at 10:32 AM, chuckcranor [email protected] wrote:

for the flat file FS: if we have an open file and we rename it, the flatfile code may copy the backing file from one backing filesystem to another (e.g. see FlatFileSystem::rename() calls Util::CopyFile). if the file is open we have a cached IOSHandle *backend_fh in the Flat_fd ... and if Flat_fd::renamefd() is called (see FlatFileFD.h), it will update the path/backend metadata in the Flat_fd, but not the open backend_fh IOSHandle (which will point to the old backend filesystem, pre Util::CopyFile). Future I/O will go to that stale backend_fh, rather than a new fh open on the new backend location.

This only impacts FUSE (since it is the main user of renamefd()).

A possible solution is to have Flat_fd::renamefd() close the old backend_fh and reopen the backing file at the new location (making sure you open in the correct mode and get the error handling right).

Then what if a write happens in the midst of the copying? Who should win? Can we control who wins? Should we care enough to control who wins?

Thx

John

—
Reply to this email directly or view it on GitHub.

[chuckcranor]

Ah, there's that too. Looking at the current code, i think that if you write during the copy the write data will be copied only if the Util::CopyFile hasn't done that area. Could add more locking code to block the writes during copy, though currently it isn't a common use case for us.