It started with my curiosity. I know this is not the right way to use a local filesystem and someone would feel weird. I just wanted to organize the situation and experiment like that. I thought it would work if I flushed Node B's cached file system metadata with the drop cache, but I didn't. I've googled for something other than the mount and unmount process, and I saw a StackOverflow article telling file systems to sync via blockdev --flushbufs. So I do the blockdev --flushbufs after the drop cache. However, I still do not know why I can read the data stored in the shared storage via Node B. Thank you, 2019-09-17 4:23 GMT+09:00, Eric Sandeen <sandeen@xxxxxxxxxxx>: > > > On 9/16/19 9:33 AM, Daegyu Han wrote: >> Hi linux file system experts, >> >> I want to share ext4 on the storage server to multiple initiators(node >> A,B) using NVMeoF. >> Node A will write file to ext4 on the storage server, and I will mount >> read-only option on Node B. >> >> Actually, the reason I do this is for a prototype test. >> >> I can't see the file's dentry and inode written in Node A on Node B >> unless remount(umount and then mount) it. >> >> Why is that? > > Caching, metadata journaling, etc. > > What you are trying to do will not work. > >> I think if there is file system cache(dentry, inode) on Node B, then >> disk IO will occur to read the data written by Node A. > > why would it? there is no coordination between the nodes. ext4 is > not a clustered filesystem. > >> Curiously, drop cache on Node B and do blockdev --flushbufs, then I >> can access the file written by Node A. >> >> I checked the kernel code and found that flushbufs incurs >> sync_filesystem() which flushes the superblock and all dirty file >> system caches. >> >> Should the superblock data structure be flushed (updated) when >> accessing the disk inode? > > It has nothing to do w/ the superblock. > >> I wonder why this happens. > > ext4 cannot be used for what you're trying to do. > > -Eric >
