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". Now let's review some generic issues. - to identify a file, we need its device number and the inode number. - to identify a process, we need the process id. - FS knows about the files in use but doesn't know about pid. - lsof shows the device number but the inode number. - 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? 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? If so, it means we need to develop a new command and a new sub module of aufs, I think. J. R. Okajima ------------------------------------------------------------------------------ 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
