Hi, > Thanks for your attention. Actually, I tried different versions of draft > patch locally. > Either of them can satisfy myself so far.
Sorry, I meat "neither of them". Eric > Some rules I'd like to follow: > 1) check and avoid recursive cluster locking, rather than allow it which > Junxiao had tried > before; > 2) Just keep track of lock resource that meets the following requirements: > a. normal inodes (non systemfile); > b. inode metadata lockres (not open, rw lockres); > why? to avoid more special cluster locking usecases, like journal systemfile, > "LOST+FOUND" > open lockres, that lock/unlock > operations are performed by different processes, making tracking task more > tricky. > 3) There is another problem if we follow "check + avoid" pattern, which I > have mentioned in > this thread: > """ > This is wrong. We also depend ocfs2_inode_lock() pass out "bh" for later use. > > So, we may need another function something like ocfs2_inode_getbh(): > if (!oh) > ocfs2_inode_lock(); > else > ocfs2_inode_getbh(); > """ > > Hope we can work out a nice solution for this tricky issue ;-) > > Eric > > > _______________________________________________ > Ocfs2-devel mailing list > Ocfs2-devel@oss.oracle.com > https://oss.oracle.com/mailman/listinfo/ocfs2-devel > _______________________________________________ Ocfs2-devel mailing list Ocfs2-devel@oss.oracle.com https://oss.oracle.com/mailman/listinfo/ocfs2-devel
