El vie, 04-06-2004 a las 03:23, Alexander Larsson escribió: > > > I like the basic idea of nonotify. Its a lot easier to do resource > control like throttling in the polling daemon, and the kernel complexity > is a lot lower. Ideally, instead of simple throttling, it would be great if the polling daemon (receiving nonotify nudges) would wait for a "quiet" period (say 100ms between nudges) then release all change notifications in batch. That way, a ./configure would trigger one, perhaps only two or three change notifications to client apps, instead of a ton, which causes e.g. konqueror to flash like mad and CPU consumption to go up. > A daemon using dnotify will need to do full stat-walking > and keep stat struct around anyway, so there is no added complexity on > the userspace side. The only thing that would avoid that on the > userspace side would be full information on changes in events, and that > just isn't workable in kernel-space. > > Two problems from dnotify are still existing, namely notify on NFS and > hard links. The nonotify approach does make the hard links problem > slightly easier, you just have to find all the currently live dentries > that has the inode of the changed file as a child, however I think even > that is not possible. > > It *is* however possible to set the mtime of all the parent dentries of > the inode by walking the dentry->d_inode->i_dentry list, and by doing > that you will make the hard links case work in cases where another > dentry refering to the inode is in memory already. This will tend to > often work, since if fam was monitoring the other dentry, it typically > has stat:ed the file and chances are that its dentry is still in memory. > Its not a perfect solution though. > > Anyway, I like the approach and I think it has a higher chance of > getting past the kernel people. I think you should continue working on > it. I think the most important thing at this point is to try to get > feedback and buy-in from the important kernel people. I'll try to point > a couple of them your way if I can. > > > The problem is how to bring the dcontents_mtime timestamp to userspace. > > I guess it's hard to get an ok by the kernel-people for a new function > > "sys_nonotify_stat()" in the syscall-table (to report atime, mtime, > > ctime and dcontents_mtime). > > > > Another option would be to open up a device and use an ioctl call - but > > i don't know if the performance of that is good enough for nonotify's > > purpose. Or add a field to the stat64 structure - which would break C > > compatibility. :-( > > The kernel people seem to dislike this approach as "ugly", so I don't > think so. Maybe you could do an ioctl on the fd you get from opening the > actual directory? > > > Thanks, and sorry for beeing a bit unkind and provoking in my last mail. > > Yeah, being provocative rarely helps your cause, it just tends to make > people ignore you. Anyway, thanks for working on this (long standing) > problem and actually thinking out of the box. Only one question remains. Does nonotify require open fds? I mean, will it block cdrom ejection? =) > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Alexander Larsson Red Hat, Inc > alexl redhat com alla lysator liu se > He's an unconventional native American photographer with a mysterious suitcase > handcuffed to his arm. She's a green-fingered motormouth mermaid from out of > town. They fight crime! -- Manuel Amador (Rudd-O) GPG key ID: 0xC1033CAD at keyserver.net
Attachment:
signature.asc
Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente