LWN: Comments on "Looking forward to 2.6.16"

Ugh...

jzbiciak — Sat, 14 Jan 2006 20:44:55 +0000

s/Common Object Mode/Component Object Model/

Either my coffee hasn't kicked in, or this is a secret plot by COMMAND.COM to make me look bad.

Ugh...

jzbiciak — Sat, 14 Jan 2006 20:41:41 +0000

Let's go rename all computer/communication/common/comparison/completion-related things to "com" while we're at it. Hrmph.

Oh, is that what the .COM bubble was about. And here I thought it was some strange plot between my serial ports (COM1: and COM2:) and the Common Object Mode taking over commercial interests. :-)

NFS client updates

pimlott — Fri, 13 Jan 2006 19:52:43 +0000

it's like watching your kid graduate from college. :-p

... after six years. :-)

Ugh...

roelofs — Thu, 12 Jan 2006 22:17:47 +0000

The block_device_operations structure has a new method getgeo(); its job is to fill in an hd_geometry structure with information about the drive.

...what a hideous name. "geo" == "Earth," was my first thought, followed immediately by "what the heck does that mean?" and then "maybe 'get geography'??". One extra letter buys you "getgeom()", which is as close to unambiguous as most abbreviations get...but "getgeo()"? Ugh.

Let's go rename all computer/communication/common/comparison/completion-related things to "com" while we're at it. Hrmph.

Curmudgeonly,
Greg

Correction on IFB

corbet — Thu, 12 Jan 2006 13:42:00 +0000

Typo fixed, thanks.

The rest is just from the commit message. There's a bit more in the patch itself, but it still doesn't just jump out at relatively slow people (like your editor...)

Correction on IFB

dion — Thu, 12 Jan 2006 11:22:47 +0000

It's not "Internet Functional Block", it's "Intermediate Functional Block", it has been described here:

http://www.kernel.org/git/?p=linux/kernel/git/torvalds/li...

It is by no means obscure for people who'd like to do ingress shaping.

Currently you can only do traffic shaping on egress, that means that if you have a router with 3 internal interfaces then each interface will be shaped separately, so each segment of the network can get a maximum of 1/3 of the available bandwidth, this sucks if there are two leechers on one net and none on the other.

With IFB (or IMQ previously) you can set up a virtual network device between your Internet line and the rest of the network so all the incoming traffic can be shaped together.

NFS client updates

zblaxell — Thu, 12 Jan 2006 00:53:24 +0000

That's one of the effects.

The addition of lazy umounts and "umount -l" was a major step forward in
this area (you still couldn't kill the processes, but you could drop the
mount point so that you didn't get any more stuck on the dead NFS mount).
Solving the real problem of course is much better. ;-)

I also did things like mess with firewalls and NAT configuration until I
could convince the localhost to talk to its own NFS server (the tricky
part is doing this remotely with a live net-connected machine without
disrupting all of the server's other clients at the same time). This led
to "Stale NFS file handles" all over the place, but at least the RPC
calls would complete and the machine could get on with killing processes.

NFS client updates

njhurst — Wed, 11 Jan 2006 23:50:48 +0000

What does this mean exactly, is it when a program is accessing an nfs file and the network goes down you can't kill the program?

Looking forward to 2.6.16

gregkh — Wed, 11 Jan 2006 04:42:07 +0000

I completly deny that plot. If you look at the mess that is the driver core that I helped create, you would know that I'm all about the big, monolithic kernel model :)

Looking forward to 2.6.16

iabervon — Wed, 11 Jan 2006 04:29:44 +0000

So you deny that it's part of a plot to turn Linux into a ukernel? :)

NFS client updates

zblaxell — Wed, 11 Jan 2006 02:15:08 +0000

"SUNRPC: Ensure that SIGKILL will always terminate a synchronous RPC call."

I've been waiting for that patch since 0.98 or so. It's been broken so long I started to believe it was part of the spec. ;-)

Looking forward to 2.6.16

gregkh — Wed, 11 Jan 2006 00:32:11 +0000

Yeah, it means "userspace event", sorry we could not not come up with a better name.

But it does describe what is happening, userspace is being notified that
something happened in the kernel.

And it's better than "hotplug" which is overloaded way too much these
days (hotplug memory, hotplug cpu, hotplug usb devices, etc.) and we export
more information through the uevent interface than just "hotplug" add
and remove events these days.

Looking forward to 2.6.16

nix — Tue, 10 Jan 2006 23:54:02 +0000

One thing I've been wondering for a while: what does `uevent' actually stand for, and why is it considered more euphonious than `hotplug'?

(I hope it's not `user event'; that'd be a rather bad choice of name. Typing on the keyboard is a user event. Coldplugging hda is unlikely to be.)

(Oh, and Greg, Kay, if you're reading this, thanks again for udev; I don't hotplug much, but I use udev regardless, as for sheer elegance udev, especially the new udevsynthesize/shell script/uevent/udevd scheme, is one of the nicest designs I've seen in a long time.)

NFS client updates

brugolsky — Tue, 10 Jan 2006 22:47:39 +0000

Lots of NFS goodness also merged, as detailed in NFS Client Updates Against 2.6.15 Available including:

NFS: Make stat() return updated mtimes after a write()
The SuS states that a call to write() will cause mtime to be updated on the file. In order to satisfy that requirement, we need to flush out any cached writes in nfs_getattr(). Speed things up slightly by not committing the writes.
NFS: support large reads and writes on the wire
Most NFS server implementations allow up to 64KB reads and writes on the wire. The Solaris NFS server allows up to a megabyte, for instance. Now the Linux NFS client supports transfer sizes up to 1MB, too. This will help reduce protocol and context switch overhead on read/write intensive NFS workloads, and support larger atomic read and write operations on servers that support them.
SUNRPC: Ensure that SIGKILL will always terminate a synchronous RPC call.
...and make sure that the "intr" flag also enables SIGHUP and SIGTERM to interrupt RPC calls too (as per the Solaris implementation).

The last item has been on my wishlist since 2.0.x; tears of joy are welling up in my eyes, it's like watching your kid graduate from college. :-p