----- Original Message ----- | > If this can be called from anywhere without fs locks, then i_size is not | > known. That has been a problem in the past since i_size may have changed | > on another node. We avoid that in this case due to only changing i_size | > under an exclusive lock, and also only having dirty pages when we have | > an exclusive lock. There is another case though, if the inode is a block | > device, i_size will be zero. That is the case for the address space that | > looks after rgrps for GFS2. We do (luckily!) call | > filemap_fdatawait_range() directly in that case. For "normal" inodes | > though, the address space for metadata is backed by the block device | > inode, so that looks like it might be an issue, since | > fs/gfs2/glops.c:inode_go_sync() calls filemap_fdatawait() on the | > metamapping. It might potentially be an issue in other cases too, | > | > Steve. | > | | Some of those do sound problematic. | | Again though, we're only waiting on writeback here, and I assume with | gfs2 that would only be pages that were written on the local node. | | Is it possible to have pages under writeback and in still in the tree, | but that are beyond the current i_size? It seems like that's the main | worrisome case. | | -- | Jeff Layton <jlayton@xxxxxxxxxx> Hi Jeff, I believe the answer is yes. I was recently "bitten" by a case where (whether due to a bug or not) I had blocks allocated in a GFS2 file beyond i_size. I had implemented a delete algorithm that used i_size, but I found cases where files couldn't be deleted because of blocks hanging out past EOF. I'm not sure if they can be in writeback, but possibly. It's already on my "to investigate" list, but I haven't gotten to it yet. Yes, it seems like a bug. Yes, we need to fix it. But now there may be lots of legacy file systems out in the field that have this problem. Not sure if they can get to writeback until I study the situation more closely. I believe Ben Marzinski also may have come across a case in which we can have blocks in writeback that are beyond i_size. See the commit message on Ben's patch here: https://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2.git/commit/fs/gfs2?h=for-next&id=fd4c5748b8d3f7420e8932ed0bde3d53cc8acc9d Regards, Bob Peterson Red Hat File Systems -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
