Linux 3.7 Released 151
The wait is over; diegocg writes "Linux kernel 3.7 has been released. This release adds support for the new ARM 64-bit architecture, ARM multiplatform — the ability to boot into different ARM systems using a single kernel; support for cryptographically signed kernel modules; Btrfs support for disabling copy-on-write on a per-file basis using chattr; faster Btrfs fsync(); a new experimental 'perf trace' tool modeled after strace; support for the TCP Fast Open feature in the server side; experimental SMBv2 protocol support; stable NFS 4.1 and parallel NFS; a vxlan tunneling protocol that allows to transfer Layer 2 ethernet packets over UDP; and support for the Intel SMAP security feature. Many small features and new drivers and fixes are also available. Here's the full list of changes."
Is Btrfs for real yet? (Score:2, Interesting)
Does it `Just Work' (tm)? I really want rolling snapshots ah la NetApp.
Sorry to be obtuse. Not much time for experiments.
Re:UDP ... (Score:5, Interesting)
Why does vxlan transfer L2 packets using UDP and not TCP? I have also seen this on other L2 protocols like L2TP and PPTP ... just curious ...
TCP has a feedback loop when packets are lost... So you'd have that at both layers, the actual session and the tunnel.
Its an engineering thing where if you embed a feedback loop inside a feedback loop, things will be OK if you're VERY careful but most are not and you'll make a lovely oscillator and just blow it all to bits.
Fundamentally, UDP doesn't guarantee delivery so its OK to shove it inside UDP, and TCP has its own repair mechanism so you don't need to guarantee its sub-layers, so its not like you're missing anything.
Finally it just kills performance because TCP loves big buffers for each connection so you need megatons of ram until you start dropping packets and letting TCP police itself. Which meanwhile results in horrific latency. But if you tunnel over UDP, you don't really need much of a buffer on the tunneler itself and you'll overall end up with better latency specs. So its cheaper and works better. Hard to beat that combo...
Btrfs finally ready? (Score:2, Interesting)
Is it finally ready for prime time? any one with experiences/horror stories?
Re:Is Btrfs for real yet? (Score:2, Interesting)
The SUSE implementation of Btrfs is quite good. It's quite a bit ahead of the Btrfs support I've seen on other distributions and setting it up is pretty much automated by the installer. I agree Btrfs isn't stable yet and so shouldn't be used in production yet, but it looks like it is getting closer.
Re:DRM (Score:5, Interesting)
Only when you control the kernel/boot loader. I have a feeling that this will be used a lot by vendors to lock you out of your own devices, e.g. Android phones etc.
I'm as paranoid as the next geek, and the idea of secure boot etc. appeals a lot to me if done correctly. As in, if it's MY device, then I get to decide what runs on it, and no one else. But it's a tool, and as such it can be used both for you and against you. There can't be a technical solution, technology is dumb. We need a legal solution, either in the form of regulation or widespread adoption (and enforcement) of the GPLv3.
Re:UDP ... (Score:5, Interesting)
I forgot to mention one real life situation where UDP over TCP does not work.. UDP conceptually works pretty well with real time live streaming. "Here's 5 seconds of audio of the ball game". 5 seconds later, if lost, that packet is meaningless, don't bother re-sending it, the RX will just output 5 secs of silence or whatever. TCP does not understand that at all, so you can get serious problems with live streaming if you try to stick that inside TCP and experience significant network congestion. Buffers get bigger until they pop, "live" becomes randomly "tape delayed" based on recipient... Also TCP doesn't understand variable bit rate, so its ideas about buffer allocation bear little resemblance to what the codec actually wants to do.
Re:Btrfs finally ready? (Score:4, Interesting)
a dist-upgrade took more than 4 hours instead of the expected 1.5 to 2 hours it takes with ext4.
That's not due to poor small file performance in Btrfs, it's due to poor fsync() performance (which package tools like rpm and dpkg use quite a lot). In this new kernel version the Btrfs fsync() implementation is a lot faster.