ubifs_jnl_update and extended attribute inode removal
Hello,
Probably not many users of extended attributes on ubifs. I am trying to add this feature (patch v3) coming soon.
(xattr == extended attribute)
I have written updated the integck utility and discovered that sometimes files have wrong extended attributes. This happens only when some files are deleted from the filesystem.
Easy way to describe this is: I create 100 files, assign then extended attribute, and remember what the xattr was, it always stays the same. However now if I delete some of these files randomly some of the files end up having wrong xattr.
So I have been trying to see how UBIFS handles file removal. I see that ubifs_unlink() calls ubifs_jnl_update() as:
err = ubifs_jnl_update(c, dir, &dentry->d_name, inode, 1, 0);
However ubifs_jnl_update never removes the inode that is created to store the xattr associated , when reference drops to zero. I certainly know how to get access to inode that holds the xattr, what would be the right place where I can delete this inode also. Or does the UBIFS has some other logic that will cleanup the xattr orphan inode at later time?
Note, there are implementation of remove_xattr() and that works, but that function is only called when some user space program explicitly removes proceeds. I am just trying to get some advice from folks who understand tnc management far better than I do. Would appreciate the help/pointer.
-Subodh
-Subodh
Quoted 4 lines · Subodh Nijsure
Easy way to describe this is: I create 100 files, assign then extended attribute, and remember what the xattr was, it always stays the same. However now if I delete some of these files randomly some of the files end up having wrong xattr.
I guess this happens only when you do a power cut? I need to look closer, but quick feed-back is that there is probably a bug in the journal reply - when we see a deleted inode in the journal - we remove it from TNC, and we probably forget to look-up for all its xattrs? Really need to look closer.
Would you prepare a description how I could reproduce this?
Please, go ahead with submitting your older patches, do not cook them forever in your tree. Then you may start working on other issues.
Signature · 2 lines
Best Regards, Artem Bityutskiy
Quoted 5 lines · Artem Bityutskiy
Quoted 4 lines · Subodh Nijsure
Easy way to describe this is: I create 100 files, assign then extended attribute, and remember what the xattr was, it always stays the same. However now if I delete some of these files randomly some of the files end up having wrong xattr.
Quoted 7 lines
I guess this happens only when you do a power cut? I need to look closer, but quick feed-back is that there is probably a bug in the journal reply - when we see a deleted inode in the journal - we remove it from TNC, and we probably forget to look-up for all its xattrs? Really need to look closer.
Would you prepare a description how I could reproduce this?
I re-submitted patches for integck and as well as v3 of extended attribute patch set that I have been holding on to.
You can just run integck -p -n 2 <dir-name> and that should reproduce the issue i.e. integck will fail.
If email thread gets too long I could get on the OFTC #mtd irc chat at time that works best, to get some guidance.
/Subodh
Quoted 3 lines · Subodh Nijsure
Quoted 1 line
Would you prepare a description how I could reproduce this?
I re-submitted patches for integck and as well as v3 of extended attribute patch set that I have been holding on to.
Hi, did I miss some patches from you or you just disappeared?
Signature · 2 lines
Best Regards, Artem Bityutskiy