LWN: Comments on "The 2.6.37 kernel is out"

The 2.6.37 kernel is out

TheExplorer — Sat, 08 Jan 2011 21:39:09 +0000

I'm seeing some errors across the screen while trying to disable some usual things for my hardware since I do not use them, for e.g. AGP Support (Device Drivers -> Graphical Settings). Can anyone confirm this?

The 2.6.37 kernel is out

jthill — Thu, 06 Jan 2011 17:22:02 +0000

mmm. yeah, it seemed odd anyone would question it.

The 2.6.37 kernel is out

foom — Thu, 06 Jan 2011 03:03:51 +0000

I do not have a 2.6.37 kernel installed to test, but my understanding is that renames cause no events to be emitted at all.

The 2.6.37 kernel is out

bronson — Thu, 06 Jan 2011 01:55:12 +0000

The H has had a good series of articles on what's new in 2.6.37 too:

http://www.h-online.com/open/features/What-s-new-in-Linux...

The 2.6.37 kernel is out

cowsandmilk — Thu, 06 Jan 2011 00:10:43 +0000

more than like he was trying to get someone at KernelNewbies to update their page, not express disbelief that it was released...

The 2.6.37 kernel is out

jthill — Wed, 05 Jan 2011 18:43:42 +0000

jthill@gadabout:~/src/linux-2.6$ git fetch remote: Counting objects: 126, done. remote: Compressing objects: 100% (87/87), done. remote: Total 87 (delta 69), reused 0 (delta 0) Unpacking objects: 100% (87/87), done. From git://github.com/mirrors/linux-2.6 989d873..3c0eee3 master -> origin/master * [new tag] v2.6.37 -> v2.6.37 jthill@gadabout:~/src/linux-2.6$

The 2.6.37 kernel is out

larryr — Wed, 05 Jan 2011 18:18:51 +0000

Can renames be detected via directory changes, similar in some sense to git rename "detection"?

The 2.6.37 kernel is out

ufa — Wed, 05 Jan 2011 16:15:10 +0000

First thing in kernel Newbies: Linux 2.6.37 not released yet.

bump

The 2.6.37 kernel is out

foom — Wed, 05 Jan 2011 15:36:09 +0000

I don't see how you can possibly use it for an indexer. Of course, recursive watches are a great idea -- and if they were added on top of the functionality inotify provided, that'd be wonderful. Users have been asking for that for a long time.

But, for an index generated by the indexer to be useful, it needs to be able to tell the user where the file with the searched-for-content is located -- so it needs to be notified about renames too, which fanotify doesn't provide. Am I wrong?

Boot-time readahead and antivirus is such a narrow solution-space that I don't see how this whole new infrastructure and API is justified if it can only really be used for those two things.

The 2.6.37 kernel is out

mezcalero — Wed, 05 Jan 2011 14:19:46 +0000

fanotify is useful for at least three use cases where inotify wasn't useful at all: for indexers/crawlers, for readahead implementations, and for antivirus solutions. All these three need recursive looks and in the last case synchronous events. fanotify delivers that, inotify doesn't.

Right now, inotify is a lot more useful when watching particular directories (i.e. a nautilus window which shall be a live view on some directory), for most other things fanotify is the better choice.

The 2.6.37 kernel is out

ncm — Wed, 05 Jan 2011 07:02:34 +0000

Directories are files. Deleting a file or link means changing the directory the file was linked from.

Black screen on intel graphics

ncm — Wed, 05 Jan 2011 06:49:07 +0000

"hopefully the last 'blank screen' regression on intel graphics".

Linus has such a droll sense of humor.

The 2.6.37 kernel is out

foom — Wed, 05 Jan 2011 05:36:07 +0000

> For deletion, how would that work?

I'm confused as to why you would ask this: it's not like that's an brand new feature -- these things **already work in inotify**. The new features of fanotify are nice (especially the recursive watch, but also the presence of a pid field, and it being able to hand you an open fd), but why did that come at the expense of the features inotify already had?

So I guess I still have no idea what fanotify is really useful for as it stands. I thought it could be a better interface for doing a real-time-rsync, or doing backups of your whole disk, or perhaps a file indexer (doing manual recursion with inotify for a whole disk is kind of a pain, and leads to lost events...). But it can't be used for any of that.

So, it's not at all a better inotify. It's something completely different with a bunch of features lots of people wish inotify had, but without the features people already use (and need) in inotify.

The 2.6.37 kernel is out

JohnLenz — Wed, 05 Jan 2011 04:48:32 +0000

You can see file addition by watching for OPEN events. For deletion, how would that work? fanotify is a file monitoring interface, not a path monitoring interface. How would you deal with hardlinks? What if a file is hardlinked into two paths in a directory and one of the hardlinks is removed, would you still create an event? What about if the file is unlinked but a program still has an open file descriptor? Also, fanotify passes you a file descriptor so the file couldnt't be deleted yet when you receive the delete event. Remember, the file is not deleted until all file descriptors are closed.

It sounds like we should perhaps have an API for path monitoring events or something which shows path events like creating hard links, creating soft links, unlinking, renaming, etc. But I see no reason why this should be done in fanotify, since fanotify is a file change interface

The 2.6.37 kernel is out

foom — Wed, 05 Jan 2011 04:04:42 +0000

So, does that mean fanotify can actually do something useful now, like monitor changes in a directory tree? Is a superset of inotify yet?

Last I looked, it couldn't notify on addition or removal of a file in a directory, which seems to me to make it just about completely useless for everything other than a "virus scanner". And I *really* don't understand how the heck a new API which is very similar to inotify, yet has a mostly-overlapping-but-slightly-different set of features got accepted. If you want both sets of features, what, you should just use both file watch APIs at the same time? Come on.

Anyone want to explain to me how this isn't a complete disaster?