Lou Gosselin: > Your email was quite unexpected. Do you mean that this utility is too poor, or you thought that I would never consider and wrote about this problem again? Why did it take so long time? Our discussion was held several months ago. It is just because - I've left from my aufs work since last summer. - you wrote the priority is not high.
> > In this case the utility will print like this. > > > > $ auxino 10 > > b0: 30 > > b1: 20 > > > > Does the file need to be opened in order for there to be a mapping? > What happens when I do "auxino X" where X isn't valid? Currently I think auxino will be unrelated to file mmap, eg. the inode in use. After aufs remembers (stores the XINO file internally) these two things - i20(a/sh) is i10(u/sh) - i30(b/sh) is also i10(u/sh) then auxino will print like above even if u/sh is not in use. If aufs have never met i20(a/sh) nor i30(b/sh) and have never assigned i10, then auxino will print nothing. > > $ auxino --bindex 1 10 > > 20 > > I noticed the output format change between executions. I think a command > line parameter which filters the output, should not otherwise change the > output format. Ok. > > Or you may prefer another one. > > > > $ auxino --busy 1 > > 10 > > ... (more inode numbers) > > > > These inodes are in use and making the branch (index 1) busy. > > But "--busy" will be complicated a little. > > So I'd ask you first two examples will be enough for you. > > I'm afraid I'm not sure what you mean by "busy" here. I don't understand > when aufs keeps inode maps. If a file is not in use, does aufs still > track its inode? I'm not sure why we'd need the output of inodes not in > use? "--busy" will work like this. - traverse all aufs inodes in use. - if the aufs inode refers to the real inode on branch 1, then the aufs inode makes branch 1 busy. (and you cannot "remount,del:1") - auxino --busy prints those aufs inode number. When aufs keeps inode number mapping? The answer is described in the aufs manual but I try summarize it here. - when you access u/sh, aufs finds a/sh and i20. - aufs assigns i10 to it. - aufs writes the i10-i20 pair to the internal XINO file. - when you finish using a/sh and the inode is gone from the system cache, the pair is still kept in XINO. - when you access a/sh again, aufs finds a/sh and i20. - aufs searches XINO and it have been assigned i10. - aufs assgnes i10 again. - so we can keep the inode number. (but some users doesn't like XINO because it consumes some resources, and they specify noxino option) > As I recall, here's a small summary of the trouble case I had with aufs > (for my own benefit): Aufs would mmap to the old branch, but other file > access would use the new branch, the result was that it was impossible > to identify which process was locking the old branch. Yes, u/sh refers a/sh and you cannot remove the branch "a". After you find i10 is in use by lsof, you can identify whether i10 makes the branch busy or not by auxino. J. R. Okajima ------------------------------------------------------------------------------ Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d
