It's worse. As far as I can see, the s_uuid_hash is never populated. So we have two problems. The second issue is urgent as we are using it in xattr.
Coly Li wrote: > Sunil Mushran Wrote: > >> Wondering whether this id needs to be endian consistent. >> For failover nfs setups maybe. >> > > IMHO, It is. Because osb->uuid_hash is fetched by: > osb->uuid_hash = le32_to_cpu(di->id2.i_super.s_uuid_hash); > CMIIW, It should work in nfs failover. > > >> Coly Li wrote: >> >>> Currently f_fsid of struct kstatfs returned from ocfs2_statfs() is >>> undefined (at least it should be >>> filled with 0). Since in some conditions, f_fsid value might be used >>> as (f_fsid, ino) pare to >>> uniquely identify a file, ocfs2 should return a defined unique f_fsid >>> value from ocfs2_statfs(). >>> >>> This patch uses uuid_hash as a unique ID to initiate f_fsid value, the >>> 32bits width is enough for >>> ocfs2 membership so far. >>> >>> Signed-off-by: Coly Li <[email protected]> >>> --- >>> fs/ocfs2/super.c | 2 ++ >>> 1 files changed, 2 insertions(+), 0 deletions(-) >>> >>> diff --git a/fs/ocfs2/super.c b/fs/ocfs2/super.c >>> index 43ed113..fdab98a 100644 >>> --- a/fs/ocfs2/super.c >>> +++ b/fs/ocfs2/super.c >>> @@ -1425,6 +1425,8 @@ static int ocfs2_statfs(struct dentry *dentry, >>> struct kstatfs *buf) >>> buf->f_bavail = buf->f_bfree; >>> buf->f_files = numbits; >>> buf->f_ffree = freebits; >>> + buf->f_fsid.val[0] = osb->uuid_hash & 0xFFFFFFFFUL; >>> + buf->f_fsid.val[1] = 0; >>> >>> brelse(bh); >>> >>> >>> > > _______________________________________________ Ocfs2-devel mailing list [email protected] http://oss.oracle.com/mailman/listinfo/ocfs2-devel
