Linux 3.8 Released 120
diegocg writes "Linux kernel 3.8 has been released. This release includes support in Ext4 for embedding very small files in the inode, which greatly improves the performance for these files and saves some disk space. There is also a new Btrfs feature that allows for quick disk replacement, a new filesystem F2FS optimized for SSDs; support for filesystem mount, UTS, IPC, PID, and network namespaces for unprivileged users; accounting of kernel memory in the memory resource controller; journal checksums in XFS; an improved NUMA policy redesign; and, of course, the removal of support for 386 processors. Many small features and new drivers and fixes are also available. Here's the full list of changes."
Re:still supports 32-bit Intel binaries (Score:5, Interesting)
Intel's latest generation of desktop i5/i7 CPUs appear to be buggy. People I know working in CFD are finding all sorts of quirks so have gone back to older and slower Xeons. Nothing for the desktop series is documented for bugs as far as I'm aware, I don't think Intel test them as much in design as workstation grade CPUs, and published bugs for Xeons you're not allowed to talk about them.
Just a worry (Score:5, Interesting)
Re:still supports 32-bit Intel binaries (Score:5, Interesting)
Intel's latest generation of desktop i5/i7 CPUs appear to be buggy. People I know working in CFD are finding all sorts of quirks so have gone back to older and slower Xeons.
One difference is that the intel desktop CPUs generally don't have ECC whereas the Xeon ones do.
Do the new i7s produce consistent results each time? If so, then lack ECC isn't the problem.
There could also be some subtle difference in IEEE modes.
You could try dumping everything from every stage of the algorithm out and seeing when two runs start to differ.
Use inode space for 1st part of large files? (Score:2, Interesting)
From TFA it seems that large files won't benefit from the change in ext4. This seems an odd strategy.
Wouldn't it have made more sense to put the first part of the file data into the inode regardless of the size of the file ? That way every file would get an initial access speed boost by omitting seek latency, and large inodes would get used very effectively..
underwhelmed (Score:0, Interesting)
this release broke my machine. looks like i'll be on 3.7 until my hardware dies. i have been really disappointed with the flaky quality of the past 4 or 5 kernel releases. i get the feeling that pulling in android introduced some weird instabilities with the power management. i have enjoyed using linux for almost a decade now but sadly it looks like i will be moving to a different OS the next time i purchase a new system. if anyone here is involved with kernel development can you explain why things have been going downhill so fast lately?
Re:Use inode space for 1st part of large files? (Score:5, Interesting)
They probably store the file data in the same part of the inode that is otherwise used for the block list or extent list. So larger files must use that same space to tell the file system where the rest of the data is on the disk, which makes it difficult to also store data in the same location.
Also, putting a small amount of data into the inode would then mean that the rest of the file would no longer be neatly aligned on block boundaries, which makes doing a memmap of the file painful.