On 08/20/2010 05:30 PM, sf...@users.sourceforge.net wrote: > Lou Gosselin: > >> There are a few reasons I haven't seriously considered using the sysreq, >> even though it might work. >> 1. It requires compiling in debug mode. >> 2. The manual warns of performance degradation under debug mode. >> 3. The syntax of the debugging output is complex, parsing may not be >> very reliable and it could change. >> 4. Under debug mode, aufs operations generate several kbytes of logs. >> These can be filtered out, but it shouldn't be necessary. >> > I hope you don't confuse CONFIG_AUFS_DEBUG and a module parameter named > debug. For each items you wrote, > 1. Yes, Magic SysRq requires CONFIG_AUFS_DEBUG. But if I add the inode > number into the remount info, it won't be necessary. > 2. Yes, CONFIG_AUFS_DEBUG introduces more jobs. > 3. Yes, the output from Magic SysRq may change. But the remount info > will not change so frequently as Magic SysRq message. > 4. No, CONFIG_AUFS_DEBUG doesn't print much, but the module paramter > "debug" does. > > >> At this point I feel we've exhausted the topic. I've put my case >> forward; if you still don't see the need to expose the internal branch >> lock state, I'll respect your decision. >> > I could see such needs and I have written > ---------------------------------------------------------------------- > I am afraid you won't be happy even if I develop a new feature such like > - ioctl interface to get the opened file path > - /sys/fs/aufs/*/opened_files > - or something. > ---------------------------------------------------------------------- > But I didn't think it so uregently or important like a bug since you > wrote "I'm not requesting a change". > Yes, mostly I wanted to ask if the problem had already been solved, and if so, then how. That's when we got into testing all these heuristics. It is not urgent, just a limitation which became apparent during aufs remounts. I'm happy to report that in all other regards aufs is running very well.
> Now let's review some generic issues. > a- to identify a file, we need its device number and the inode number. > b- to identify a process, we need the process id. > c- FS knows about the files in use but doesn't know about pid. > d- lsof shows the device number but the inode number. > e- linux kernel doesn't provide the way to know the inode number of > running executable and opened file from outside of the process. > Do you agree? > a, b. Yes. c. If you're saying there's no inode->process map, then I can take your word on it. Presumably there must be a process->inode map to drive /proc/ and to tear down processes. d, e. Are you sure? I tried "lsof -FDi" and it seems to show the same inode and device number as through "stat" on a mounted ext2/3 > And, for my understanding, you need another lsof which prints the inode > number and aufs needs to provide the inode number. Then you can compare > them and find the process. Ideally you want something like this. > > $ ANewCommand aufs_mntpnt branch > "pid N is using the file PATH" > ... > or more simply > "pid1, pid2,,," > > Right? > Yes, If aufs is able to list the inodes of all files blocking on a specific branch, then hypothetically we should be able to look up the process via lsof. > If so, it means we need to develop a new command and a new sub module of > aufs, I think. > I don't know, it could make sense to have them available through /sys/fs/aufs/si_xxxxx/br0_inodes as a file or enumerable directory. ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev
